Skip to main content
Glama
enesjakozh
egyleader

Dart MCP Server

by egyleader
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Dart MCP 服务器

npm 版本 许可证：MIT 铁匠徽章

一个可分布式的模型上下文协议 (MCP) 服务器，用于公开 Dart SDK 命令以支持 AI 开发。该服务器通过实现模型上下文协议 (MCP)，弥合了 AI 编程助手与 Dart/Flutter 开发工作流程之间的差距。

特征

此 MCP 服务器提供对以下 Dart SDK 命令的无缝访问：

命令

描述

dart-analyze

分析 Dart 代码中的错误、警告和 lint

dart-compile

将 Dart 编译为各种格式（exe、AOT/JIT 快照、JavaScript）

dart-create

从模板创建新的 Dart 项目

dart-doc

为 Dart 项目生成 API 文档

dart-fix

对 Dart 源代码应用自动修复

dart-format

根据样式指南格式化 Dart 源代码

dart-info

显示有关已安装 Dart 工具的诊断信息

dart-package

使用包（获取、添加、升级、过时等）

dart-run

运行 Dart 程序并支持传递参数

dart-test

运行支持过滤和报告选项的测试

主要优点

  • 智能路径处理：自动将相对路径解析为绝对路径，确保命令无论工作目录如何都能正常工作

  • 项目自动检测：识别主目录和工作区等常见位置中的 Dart/Flutter 项目

  • 跨平台支持：适用于 macOS、Linux 和 Windows

  • 零配置：开箱即用，具有合理的默认设置

  • MCP 集成：兼容任何 MCP 客户端，包括 Windsurf、Cline 和其他模型上下文协议实现

Related MCP server: Flutter Inspector MCP Server

先决条件

  • Node.js ：18.x 或更高版本

  • Dart SDK ：已安装 3.0 或更高版本，并且可在 PATH 中使用

安装

通过 Smithery 安装

要通过Smithery自动为 Claude Desktop 安装 Dart MCP 服务器：

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

使用 npx（推荐）

使用 npx 无需安装即可直接运行服务器：

npx @egyleader/dart-mcp-server

全局安装

为了更方便地访问，您可以全局安装服务器：

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

然后使用以下命令运行它：

dart-mcp-server

来自源

# 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

与 MCP 客户端集成

Windsurf / Codeium IDE 配置

要将此 MCP 服务器与 Windsurf 或 Codeium IDE 一起使用，请将以下内容添加到您的mcp_config.json文件（通常位于~/.codeium/windsurf/mcp_config.json ）：

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

环境变量

  • DART_MCP_VERBOSE ：设置为任意值以启用详细日志记录以进行调试

MCP 工具使用示例

以下是如何使用服务器提供的 MCP 工具的示例。这些示例展示了可以传递给每个工具的参数。

dart 分析

分析 Dart 代码中的错误、警告和 lint：

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

dart 编译

将 Dart 代码编译为各种格式：

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

支持的格式： exe 、 aot-snapshot 、 jit-snapshot 、 kernel 、 js

dart 创建

从模板创建一个新的 Dart 项目：

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

关于项目名称和输出的注释：

  • 如果仅提供projectName ，则它将用作创建项目的目录名称。

  • 如果提供了output ，它将被用作创建项目的目录。

  • Dart 中的实际包/项目名称来自 Dart CLI 的最终目录名称。

支持的模板： console 、 package 、 server-shelf 、 web

dart 文档

为 Dart 项目生成 API 文档：

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

dart-fix

对 Dart 源代码应用自动修复：

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

dart 格式

根据样式指南格式化 Dart 源代码：

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

dart 信息

显示有关已安装的 Dart 工具的诊断信息：

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

dart 包

使用包（pub 命令）：

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

支持的命令： get 、 upgrade 、 outdated 、 add 、 remove 、 publish 、 deps 、 downgrade 、 cache 、 run 、 global

飞镖跑

运行支持传递参数的 Dart 程序：

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

飞镖测试

运行支持过滤和报告选项的测试：

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

执照

该项目根据 MIT 许可证获得许可 - 有关详细信息，请参阅LICENSE文件。

贡献

欢迎贡献代码！欢迎提交 Pull 请求。

工具 API 参考

dart 分析

分析目录或文件中的 Dart 代码。

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

例子：

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

dart 编译

将 Dart 编译为各种格式。

{
  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
}

例子：

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

dart 创建

创建一个新的 Dart 项目。

{
  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
}

笔记：

  • 如果提供了output ，则项目将在该目录中创建。

  • 如果仅提供projectName ，它将被用作目录名称。

  • 实际的 Dart 包名称源自最终的目录名称。

例子：

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

dart 文档

为 Dart 项目生成 API 文档。

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

例子：

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

dart-fix

对 Dart 源代码应用自动修复。

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

例子：

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

dart 格式

惯用格式的 Dart 源代码。

{
  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
}

例子：

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

dart 信息

显示有关已安装工具的诊断信息。

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

例子：

{
  options: ["--verbose"]
}

dart 包

使用包（pub 命令）。

{
  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
}

例子：

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

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

飞镖跑

运行 Dart 程序。

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

例子：

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

飞镖测试

对项目运行测试。

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

例子：

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

发展

# Watch mode for development
pnpm run dev

# Build for production
pnpm run build

错误处理

服务器实现了全面的错误处理：

  • 捕获命令执行错误并进行适当格式化

  • 路径解析问题通过详细诊断进行报告

  • 长时间运行操作的超时处理

  • Dart 命令的正确退出代码传播

贡献

请参阅CONTRIBUTING.md了解详细的贡献指南。

我们的提交格式如下：

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

例子：

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

执照

麻省理工学院

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 10 tool updatesv1.0.0
    • Addeddart-analyze
    • Addeddart-compile
    • Addeddart-create
    • Addeddart-doc
    • Addeddart-fix
    • Addeddart-format
    • Addeddart-info
    • Addeddart-package
    • Addeddart-run
    • Addeddart-test
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.1/5.0

Scored across 10 tools

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

Related MCP Connectors

Related MCP Servers

Appeared in Searches