en es ja ko zh

Dart MCP Server

Name: Dart MCP Server
Author: egyleader

by egyleader

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Dart MCP サーバー

npmバージョンライセンス: MIT 鍛冶屋のバッジ

AIを活用した開発向けにDart SDKコマンドを公開する、分散型モデルコンテキストプロトコル（MCP）サーバーです。このサーバーは、モデルコンテキストプロトコル（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 統合: Windsurf、Cline、その他のモデルコンテキストプロトコル実装を含む、あらゆる MCP クライアントと互換性があります。

Related MCP server: Flutter Inspector MCP Server

前提条件

Node.js : 18.x 以上
Dart SDK : 3.0 以上がインストールされ、PATH で利用可能

インストール

Smithery経由でインストール

Smithery経由で Claude Desktop 用の Dart MCP Server を自動的にインストールするには:

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 コードのエラー、警告、および lint を分析します。

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

ダートコンパイル

Dart コードをさまざまな形式にコンパイルします。

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

サポートされている形式: exe 、 aot-snapshot 、 jit-snapshot 、 kernel 、 js

ダーツ作成

テンプレートから新しい Dart プロジェクトを作成します。

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

projectName と出力に関する注意:

projectNameのみが指定されている場合は、プロジェクトが作成されるディレクトリ名として使用されます。
outputが指定されている場合は、プロジェクトが作成されるディレクトリとして使用されます。
Dart の実際のパッケージ/プロジェクト名は、Dart CLI によって最終的なディレクトリ名から派生されます。

サポートされているテンプレート: console 、 package 、 server-shelf 、 web

ダーツドキュメント

Dart プロジェクトの API ドキュメントを生成します。

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

ダーツフィックス

Dart ソースコードに自動修正を適用します。

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

ダーツ形式

Dart ソースコードをスタイルガイドラインに従ってフォーマットします。

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

ダーツ情報

インストールされている Dart ツールに関する診断情報を表示します。

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

ダーツパッケージ

パッケージを操作する (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ファイルを参照してください。

貢献

貢献を歓迎します！お気軽にプルリクエストを送信してください。

ツールAPIリファレンス

ダーツ分析

ディレクトリまたはファイル内の 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 をさまざまな形式にコンパイルします。

{
  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 プロジェクトを作成します。

{
  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 プロジェクトの 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 ソースコードに自動修正を適用します。

{
  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 ソースコードを慣用的にフォーマットします。

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

ダーツ情報

インストールされているツールに関する診断情報を表示します。

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

例：

{
  options: ["--verbose"]
}

ダーツパッケージ

パッケージを操作します (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

Name	Required	Description	Default
`path`	No	Directory or file to analyze
`options`	No	Additional 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

Name	Required	Description
`format`	Yes	Output format for the compilation
`path`	Yes	Path to the Dart file to compile
`output`	No	Output file path
`options`	No	Additional 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

Name	Required	Description	Default
`template`	No	Template to use for project generation	package
`projectName`	Yes	Name of the project to create
`output`	No	Directory where to create the project
`options`	No	Additional 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

Name	Required	Description
`path`	No	Directory containing the Dart package to document
`output`	No	Output directory for the generated documentation
`options`	No	Additional 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

Name	Required	Description
`path`	No	Directory or file to apply fixes to
`apply`	No	Whether to apply the suggested fixes
`options`	No	Additional 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

Name	Required	Description
`paths`	Yes	Files or directories to format
`setExitIfChanged`	No	Return exit code 1 if there are any formatting changes
`options`	No	Additional 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

Name	Required	Description	Default
`options`	No	Additional 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

Name	Required	Description
`command`	Yes	Pub subcommand to execute
`args`	No	Arguments for the pub subcommand
`workingDir`	No	Working 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

Name	Required	Description
`script`	Yes	Path to the Dart script to run
`args`	No	Arguments to pass to the script
`workingDir`	No	Working 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

Name	Required	Description
`path`	No	Path to the test file or directory
`options`	No	Additional test options
`workingDir`	No	Working 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.

10 tool updatesv1.0.0Jan 2, 2026
- 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 2026-04-18 11:35 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

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
238
l0-py-blocks-mcp A
io.github.SELISEdigitalplatforms
A Model Context Protocol (MCP) server for Selise Blocks Cloud integration
Cloud Platforms Developer Tools App Automation
362
Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216

Related MCP Servers

Dart MCP Server
Project Management Developer Tools Autonomous Agents
jmanhype
A
license
B
quality
D
maintenance
A Dart-based MCP server implementation that enables AI-assisted task management, document handling, and workspace organization through standardized tools and seamless Dart integration.
Updated 6 months ago (2026-03-25 16:56 UTC)
10
112 npm
5
MIT
Flutter Inspector MCP Server
Developer Tools Testing & QA Tools
Arenukvern
A
license
C
quality
A
maintenance
A Model Context Protocol server that connects Flutter apps with AI coding assistants like Cursor, Claude, and Cline, enabling AI-powered analysis of widget trees, navigation, and layout issues.
Updated 10 days ago (2026-09-14 12:21 UTC)
62
377
MIT
Dart MCP Server
Developer Tools Project Management
its-dart
A
license
A
quality
B
maintenance
Deprecated, please use Dart connector instead. https://glama.ai/mcp/connectors/com.dartai/dart
Updated 15 days ago (2026-09-09 01:39 UTC)
16
112 npm
128
MIT
VSCode Context MCP
Developer Tools File Systems Command Line
vilasone455
F
license
Not graded
quality
D
maintenance
A Model Context Protocol (MCP) server that provides VSCode context and filesystem operations for AI assistants.
Updated a year ago (2025-08-07 08:45 UTC)
9
-

Dart MCP サーバー

特徴

主なメリット

前提条件

インストール

Smithery経由でインストール

npx の使用（推奨）

グローバルインストール

ソースから

MCPクライアントとの統合

Windsurf / Codeium IDE の設定

環境変数

MCPツールの使用例

ダーツ分析

ダートコンパイル

ダーツ作成

ダーツドキュメント

ダーツフィックス

ダーツ形式

ダーツ情報

ダーツパッケージ

ダートラン

ダーツテスト

ライセンス

貢献

ツールAPIリファレンス

ダーツ分析

ダートコンパイル

ダーツ作成

ダーツドキュメント

ダーツフィックス

ダーツ形式

ダーツ情報

ダーツパッケージ

ダートラン

ダーツテスト

発達

エラー処理

貢献

ライセンス

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches