Skip to main content
Glama
stephangopaul

MTDevKit

by stephangopaul
OverviewSchemaRelated ServersScoreDiscussions
JavaScript

MTDevKit

An MCP (Model Context Protocol) server that scaffolds Flutter projects from a custom clean-architecture Bitbucket template. Any MCP-compatible AI agent (Claude Desktop, Claude Code, Cursor, etc.) can call it as a tool.

What it does

Tools

Tool

Description

create_flutter_project

Full 11-step project setup (clone template → git init → deps → l10n → flavorizr → config → Android)

list_flutter_projects

Scan a directory for Flutter projects

get_project_info

Read pubspec, config, git status of an existing project

Slash commands (prompts)

These show up when you type / in Cursor or other MCP clients:

Command

Description

/create-flutter-project

Scaffold a new Flutter project from the MT template

/list-flutter-projects

List all Flutter projects in a directory

/project-info

Get details about an existing Flutter project

create_flutter_project steps

  1. Install/update app_starter_plus

  2. Clone template & rename project

  3. Initialise Git (+ hooks if present)

  4. Install Flutter dependencies

  5. Generate localisations

  6. Update flavorizr.yaml with project name & org

  7. Commit all files before flavorizr

  8. Generate flavors (flavorizr)

  9. Revert main.dart & app.dart (overwritten by flavorizr)

  10. Create config files (dev / uat / prod)

  11. Configure Android build (desugaring, HMS, ProGuard)

create_flutter_project parameters

Parameter

Required

Description

name

Yes

Dart package name (e.g. my_super_app)

org

Yes

Reverse-domain org (e.g. mu.mt)

template

Template repo URL (defaults to Bitbucket template)

dir

Parent directory (defaults to cwd)

dry_run

Preview without executing

Related MCP server: Fables MCP Server

Prerequisites

  • Node.js >= 18

  • git

  • Flutter (via fvm or direct — fvm is auto-detected)

  • SSH key or credentials configured for your Bitbucket template repo

Install

Option 1: via npm (GitHub Packages)

npx -y @stephangopaul/mtdevkit --registry=https://npm.pkg.github.com

Option 2: from source

git clone https://github.com/stephangopaul/MTDevKit.git
cd MTDevKit
npm install
npm run build

Usage with Cursor

Add to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "MTDevKit": {
      "command": "npx",
      "args": [
        "-y",
        "@stephangopaul/mtdevkit",
        "--registry=https://npm.pkg.github.com"
      ]
    }
  }
}

Or if running from source:

{
  "mcpServers": {
    "MTDevKit": {
      "command": "node",
      "args": ["/path/to/MTDevKit/dist/index.js"]
    }
  }
}

Usage with Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "MTDevKit": {
      "command": "npx",
      "args": [
        "-y",
        "@stephangopaul/mtdevkit",
        "--registry=https://npm.pkg.github.com"
      ],
      "env": {
        "PATH": "/usr/local/bin:/usr/bin:/bin:/your/flutter/path"
      }
    }
  }
}

Tip: Make sure PATH in env includes the directories where fvm, git, and dart live.

Usage with Claude Code

claude mcp add MTDevKit -- npx -y @stephangopaul/mtdevkit --registry=https://npm.pkg.github.com

Example interaction

You: Create a new Flutter project called logistics_app for org mu.mt

Agent calls create_flutter_project with { name: "logistics_app", org: "mu.mt" } and returns the full setup log + project path.

Dry run

Pass dry_run: true to preview every command without executing anything — useful for confirming the plan before committing.

Customisation

  • Template URL — change DEFAULT_TEMPLATE in src/index.ts or pass it per-call

  • Config file shape — edit the configJson() helper to match your team's schema

  • Extra steps — add more steps by following the existing pattern in the tool handler

Available Tools

3 tools
create_flutter_projectA

Scaffold a new Flutter project from the custom clean-architecture template.

Runs the full 11-step setup:

  1. Install/update app_starter_plus

  2. Clone template & rename project

  3. Initialise Git (+ hooks if present)

  4. Install Flutter dependencies

  5. Generate localisations

  6. Update flavorizr.yaml with project name & org

  7. Commit all files before flavorizr

  8. Generate flavors (flavorizr)

  9. Revert main.dart & app.dart (overwritten by flavorizr)

  10. Create config files (dev / uat / prod)

  11. Configure Android build (desugaring, HMS, ProGuard)

Automatically detects fvm; falls back to plain flutter/dart if fvm is not installed. Returns the absolute path to the ready-to-develop project.

NOTE: This tool does NOT ask for confirmation — it runs immediately. Use dry_run=true first if you want to preview the plan before executing.

ParametersJSON Schema
NameRequiredDescriptionDefault
dirNoParent directory to create the project in (default: current working directory)
orgYesOrganisation identifier in reverse-domain, e.g. mu.mt
nameYesDart/Flutter project name, e.g. telecom_app_enterprise
dry_runNoIf true, report what would happen without executing anything
templateNoTemplate repo URL (default: https://bitbucket.org/mtinnovation/flutter_clean_template_2025)

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses immediate execution (no confirmation), automatic fvm detection, absolute path return, and 11-step process. No annotations provided, so description bears full burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with numbered steps. Some repetition of process but overall efficient given complexity. Could be slightly shorter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers full 11-step process, return value, and conditional behavior (fvm). No output schema, but description is self-contained and complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% of parameters. Description adds minimal value beyond schema, e.g., mentions dry_run for preview but no new semantic detail. Baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it scaffolds a Flutter project from a custom clean-architecture template. Distinguishes from siblings list_flutter_projects and get_project_info.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Suggests using dry_run=true first to preview. Provides context on when to use but lacks explicit exclusions or alternatives beyond dry_run.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_project_infoB

Get details about an existing Flutter project (pubspec, flavors, config files, etc.).

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesAbsolute path to the Flutter project root

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden but only adds minimal behavioral context beyond the tool name. It implies a read operation but does not disclose prerequisites (e.g., project must exist), side effects, or limitations. More detail on behavior is expected.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no wasted words. It front-loads the primary action and includes specific examples. It is appropriately sized for the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a basic get-info tool with no output schema, the description covers the main purpose and gives examples of what details are retrieved. However, it omits return format, error scenarios, and any potential prerequisites, leaving some gaps in completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%—the parameter 'path' is fully described in the schema. The description adds context about the project type (Flutter) and what details are retrieved, which slightly enriches understanding of the parameter's purpose. However, it does not add specific parameter syntax or constraints beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to get details about an existing Flutter project, listing examples like pubspec, flavors, and config files. This distinguishes it from sibling tools (create_flutter_project and list_flutter_projects) by focusing on retrieving information on a single project.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance is provided on when to use this tool versus the siblings. The description does not include conditions, when-not-to-use, or alternatives. While sibling names offer some context, the description itself lacks usage instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_flutter_projectsB

List Flutter projects in a given directory (looks for pubspec.yaml).

ParametersJSON Schema
NameRequiredDescriptionDefault
dirNoDirectory to scan (default: current working directory)

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries full burden. It mentions the detection method (looking for pubspec.yaml) but does not clarify recursion depth, error handling, performance, or whether it is read-only.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence. It is efficient but could be more precise (e.g., 'Scans the given directory for pubspec.yaml files and returns matching project paths').

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple nature of the tool (one param, no output schema, no annotations), the description covers basic behavior. However, it omits important details like whether subdirectories are scanned recursively and what the output format looks like.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already fully describes the single 'dir' parameter, including default behavior (current working directory). The description adds no extra parameter-specific details beyond the operation context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists Flutter projects by detecting pubspec.yaml files in a directory. It distinguishes effectively from siblings like create_flutter_project and get_project_info by focusing on listing existing projects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus siblings or alternatives. It does not specify prerequisites, limitations, or exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 3 tool updatesv1.0.0
    • First observedcreate_flutter_project
    • First observedget_project_info
    • First observedlist_flutter_projects
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: create a new project, list existing projects, and get project details. No overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case: create_flutter_project, list_flutter_projects, get_project_info. Predictable and clear.

Tool Count5/5

Three tools is an appropriate scope for a server focused on Flutter project scaffolding and inspection. Each tool earns its place without unnecessary bloat.

Completeness4/5

The tools cover core creation and read operations (list, info). Missing update or delete tools, but this is reasonable for a scaffolding-focused server; the create tool handles extensive setup.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Fables MCP Server

    Atum246
    A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that provides AI agents with tools to build, deploy, and manage Flutter applications, including APK/AAB generation, keystore management, and CI/CD integration.
    7
    1
    MIT

  • Builder-Proj-MCP Server

    fhyxz1
    A
    license
    A
    quality
    D
    maintenance
    A unified MCP server for scaffolding project structures across multiple frameworks including Spring Boot, React, Vue, Next.js, FastAPI, Django, Flask, Express, and more.
    2
    24
    1
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/stephangopaul/MTDevKit'

If you have feedback or need assistance with the MCP directory API, please join our Discord server