Skip to main content
Glama
enesjakozh
egyleader

Dart MCP Server

by egyleader
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

Dart MCP Server

npm version License: MIT

A distributable Model Context Protocol (MCP) server that exposes Dart SDK commands for AI-powered development. This server bridges the gap between AI coding assistants and Dart/Flutter development workflows by implementing the Model Context Protocol (MCP).

Features

This MCP server provides seamless access to the following Dart SDK commands:

Command

Description

dart-analyze

Analyze Dart code for errors, warnings, and lints

dart-compile

Compile Dart to various formats (exe, AOT/JIT snapshots, JavaScript)

dart-create

Create new Dart projects from templates

dart-doc

Generate API documentation for Dart projects

dart-fix

Apply automated fixes to Dart source code

dart-format

Format Dart source code according to style guidelines

dart-info

Show diagnostic information about the installed Dart tooling

dart-package

Work with packages (get, add, upgrade, outdated, etc.)

dart-run

Run Dart programs with support for passing arguments

dart-test

Run tests with support for filtering and reporting options

Key Benefits

  • Intelligent Path Handling: Automatically resolves relative paths to absolute paths, ensuring commands work correctly regardless of working directory

  • Project Auto-Detection: Identifies Dart/Flutter projects in common locations like home directories and workspaces

  • Cross-Platform Support: Works on macOS, Linux, and Windows

  • Zero Configuration: Works out of the box with sensible defaults

  • MCP Integration: Compatible with any MCP client, including Windsurf, Cline, and other Model Context Protocol implementations

Related MCP server: Flutter Inspector MCP Server

Prerequisites

  • Node.js: 18.x or higher

  • Dart SDK: 3.0 or higher installed and available in your PATH

Installation

Installing via Smithery

To install Dart MCP Server for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @egyleader/dart-mcp --client claude

Using npx (recommended)

The server can be run directly without installation using npx:

npx @egyleader/dart-mcp-server

Global Installation

For easier access, you can install the server globally:

npm install -g @egyleader/dart-mcp-server

Then run it using:

dart-mcp-server

From Source

# Clone the repository
git clone https://github.com/egyleader/dart-mcp-server.git
cd dart-mcp-server

# Install dependencies
npm install

# Build the project
npm run build

# Run the server
node dist/index.js

Integration with MCP Clients

Windsurf / Codeium IDE Configuration

To use this MCP server with Windsurf or Codeium IDE, add the following to your mcp_config.json file (typically located at ~/.codeium/windsurf/mcp_config.json):

{
  "mcpServers": {
    "dart": {
      "command": "npx",
      "args": [
        "-y",
        "@egyleader/dart-mcp-server"
      ]
    }
  }
}

Environment Variables

  • DART_MCP_VERBOSE: Set to any value to enable verbose logging for debugging

MCP Tool Usage Examples

Here are examples of how to use the MCP tools provided by the server. These examples show the parameters that can be passed to each tool.

dart-analyze

Analyze Dart code for errors, warnings, and lints:

{
  "path": "lib/main.dart",
  "options": ["--fatal-infos", "--fatal-warnings"]
}

dart-compile

Compile Dart code to various formats:

{
  "path": "lib/main.dart",
  "format": "exe",
  "output": "build/app",
  "options": ["--verbose"]
}

Supported formats: exe, aot-snapshot, jit-snapshot, kernel, js

dart-create

Create a new Dart project from a template:

{
  "projectName": "my_awesome_app",
  "template": "console",
  "output": "projects/my_awesome_app",
  "options": ["--force"]
}

Note on projectName and output:

  • If only projectName is provided, it's used as the directory name where the project is created.

  • If output is provided, it's used as the directory where the project is created.

  • The actual package/project name in Dart is derived from the final directory name by the Dart CLI.

Supported templates: console, package, server-shelf, web

dart-doc

Generate API documentation for a Dart project:

{
  "path": ".",
  "output": "doc",
  "options": ["--exclude", "lib/generated"]
}

dart-fix

Apply automated fixes to Dart source code:

{
  "path": "lib",
  "apply": true,
  "options": ["--pedantic"]
}

dart-format

Format Dart source code according to style guidelines:

{
  "paths": ["lib/main.dart", "lib/models"],
  "setExitIfChanged": true,
  "options": ["--line-length=100"]
}

dart-info

Show diagnostic information about the installed Dart tooling:

{
  "options": ["--verbose"]
}

dart-package

Work with packages (pub commands):

{
  "command": "get",
  "workingDir": ".",
  "args": ["--offline"]
}

Supported commands: get, upgrade, outdated, add, remove, publish, deps, downgrade, cache, run, global

dart-run

Run Dart programs with support for passing arguments:

{
  "script": "bin/server.dart",
  "workingDir": ".",
  "args": ["--port=8080", "--mode=production"]
}

dart-test

Run tests with support for filtering and reporting options:

{
  "path": "test",
  "workingDir": ".",
  "options": ["--name=login", "--platform=chrome"]
}

License

This project is licensed under the MIT License - see the LICENSE file for details.

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

Tool API Reference

dart-analyze

Analyze Dart code in a directory or file.

{
  path?: string;       // Directory or file to analyze
  options?: string[];  // Additional options for the dart analyze command
}

Example:

{
  path: "lib",
  options: ["--fatal-infos", "--fatal-warnings"]
}

dart-compile

Compile Dart to various formats.

{
  format: 'exe' | 'aot-snapshot' | 'jit-snapshot' | 'kernel' | 'js'; // Output format
  path: string;        // Path to the Dart file to compile
  output?: string;     // Output file path
  options?: string[];  // Additional compilation options
}

Example:

{
  format: "exe",
  path: "bin/main.dart",
  output: "bin/app"
}

dart-create

Create a new Dart project.

{
  template: 'console' | 'package' | 'server-shelf' | 'web'; // Project template
  projectName: string; // Name of the project to create
  output?: string;     // Directory where to create the project
  options?: string[];  // Additional project creation options
}

Note:

  • If output is provided, the project will be created in that directory.

  • If only projectName is provided, it will be used as the directory name.

  • The actual Dart package name is derived from the final directory name.

Example:

{
  template: "package",
  projectName: "my_dart_library",
  output: "projects/my_dart_library"
}

dart-doc

Generate API documentation for Dart projects.

{
  path?: string;       // Directory containing the Dart package to document
  output?: string;     // Output directory for the generated documentation
  options?: string[];  // Additional documentation options
}

Example:

{
  path: ".",
  output: "doc/api"
}

dart-fix

Apply automated fixes to Dart source code.

{
  path?: string;       // Directory or file to apply fixes to
  apply?: boolean;     // Whether to apply the suggested fixes (default: true)
  options?: string[];  // Additional fix options
}

Example:

{
  path: "lib",
  apply: true,
  options: ["--pedantic"]
}

dart-format

Idiomatically format Dart source code.

{
  paths: string[];     // Files or directories to format
  setExitIfChanged?: boolean; // Return exit code 1 if there are formatting changes (default: false)
  options?: string[];  // Additional format options
}

Example:

{
  paths: ["lib", "test"],
  setExitIfChanged: true,
  options: ["--line-length=80"]
}

dart-info

Show diagnostic information about the installed tooling.

{
  options?: string[];  // Additional info options
}

Example:

{
  options: ["--verbose"]
}

dart-package

Work with packages (pub commands).

{
  command: 'get' | 'upgrade' | 'outdated' | 'add' | 'remove' | 'publish' | 'deps' | 'downgrade' | 'cache' | 'run' | 'global'; // Pub subcommand
  args?: string[];     // Arguments for the pub subcommand
  workingDir?: string; // Working directory for the command
}

Examples:

// Add a package
{
  command: "add",
  args: ["rxdart"],
  workingDir: "my_project"
}

// Get dependencies
{
  command: "get",
  workingDir: "my_project"
}

dart-run

Run a Dart program.

{
  script: string;      // Path to the Dart script to run
  args?: string[];     // Arguments to pass to the script
  workingDir?: string; // Working directory for the command
}

Example:

{
  script: "bin/main.dart",
  args: ["--verbose"],
  workingDir: "my_project"
}

dart-test

Run tests for a project.

{
  path?: string;       // Path to the test file or directory
  options?: string[];  // Additional test options
  workingDir?: string; // Working directory for the command
}

Example:

{
  path: "test",
  options: ["--coverage", "--name=auth"],
  workingDir: "my_project"
}

Development

# Watch mode for development
pnpm run dev

# Build for production
pnpm run build

Error Handling

The server implements comprehensive error handling:

  • Command execution errors are captured and formatted appropriately

  • Path resolution issues are reported with detailed diagnostics

  • Timeout handling for long-running operations

  • Proper exit code propagation from Dart commands

Contributing

Please see CONTRIBUTING.md for detailed contribution guidelines.

Our commit format follows:

<type>[optional scope]: [JIRA-123(optional)] <description>

Example:

feat(tools): [DART-456] add support for dart test tags

License

MIT

Available Tools

10 tools
dart-analyzeD
ParametersJSON Schema
NameRequiredDescriptionDefault
pathNoDirectory or file to analyze
optionsNoAdditional options for the dart analyze command

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

dart-compileD
ParametersJSON Schema
NameRequiredDescriptionDefault
formatYesOutput format for the compilation
pathYesPath to the Dart file to compile
outputNoOutput file path
optionsNoAdditional compilation options

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

dart-createD
ParametersJSON Schema
NameRequiredDescriptionDefault
templateNoTemplate to use for project generationpackage
projectNameYesName of the project to create
outputNoDirectory where to create the project
optionsNoAdditional project creation options

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

dart-docD
ParametersJSON Schema
NameRequiredDescriptionDefault
pathNoDirectory containing the Dart package to document
outputNoOutput directory for the generated documentation
optionsNoAdditional documentation options

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

dart-fixD
ParametersJSON Schema
NameRequiredDescriptionDefault
pathNoDirectory or file to apply fixes to
applyNoWhether to apply the suggested fixes
optionsNoAdditional fix options

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

dart-formatD
ParametersJSON Schema
NameRequiredDescriptionDefault
pathsYesFiles or directories to format
setExitIfChangedNoReturn exit code 1 if there are any formatting changes
optionsNoAdditional format options

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

dart-infoD
ParametersJSON Schema
NameRequiredDescriptionDefault
optionsNoAdditional info options

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

dart-packageD
ParametersJSON Schema
NameRequiredDescriptionDefault
commandYesPub subcommand to execute
argsNoArguments for the pub subcommand
workingDirNoWorking directory for the command

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

dart-runD
ParametersJSON Schema
NameRequiredDescriptionDefault
scriptYesPath to the Dart script to run
argsNoArguments to pass to the script
workingDirNoWorking directory for the command

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

dart-testD
ParametersJSON Schema
NameRequiredDescriptionDefault
pathNoPath to the test file or directory
optionsNoAdditional test options
workingDirNoWorking directory for the command

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.1/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose based on its name, with no overlap or ambiguity. For example, 'dart-analyze' is for static analysis, 'dart-compile' for compilation, 'dart-run' for execution, and 'dart-test' for testing, making it easy for an agent to select the right tool.

Naming Consistency5/5

All tool names follow a consistent 'dart-' prefix with a hyphenated verb or noun pattern, such as 'dart-analyze', 'dart-compile', and 'dart-run'. This uniformity makes the set predictable and easy to understand.

Tool Count5/5

With 10 tools, the count is well-scoped for a Dart development server, covering essential operations like analysis, compilation, running, testing, and documentation. Each tool appears to serve a specific, necessary function in the domain.

Completeness4/5

The tool set covers core Dart development tasks comprehensively, including analysis, compilation, running, testing, formatting, and documentation. A minor gap might be the absence of tools for package management beyond 'dart-package', such as dependency updates or publishing, but the surface is largely complete for typical workflows.

Maintenance

ActivityInactive
ResponsivenessNo issues

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

Appeared in Searches

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/egyleader/dart-mcp'

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