Skip to main content
Glama
enesjakozh
egyleader

Dart MCP Server

by egyleader
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Dart MCP 서버

npm 버전 라이센스: MIT 대장간 배지

AI 기반 개발을 위한 Dart SDK 명령을 제공하는 배포 가능한 모델 컨텍스트 프로토콜(MCP) 서버입니다. 이 서버는 모델 컨텍스트 프로토콜(MCP)을 구현하여 AI 코딩 어시스턴트와 Dart/Flutter 개발 워크플로 간의 격차를 해소합니다.

특징

이 MCP 서버는 다음 Dart SDK 명령에 대한 원활한 액세스를 제공합니다.

명령

설명

dart-analyze

오류, 경고 및 린트에 대한 Dart 코드 분석

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

패키지 작업(get, add, upgrade, outdated 등)

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 서버를 자동으로 설치하려면:

지엑스피1

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 구성

Windsurf 또는 Codeium IDE와 함께 이 MCP 서버를 사용하려면 다음을 mcp_config.json 파일(일반적으로 ~/.codeium/windsurf/mcp_config.json 에 위치)에 추가하세요.

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

환경 변수

  • DART_MCP_VERBOSE : 디버깅을 위한 자세한 로깅을 활성화하려면 원하는 값으로 설정합니다.

MCP 도구 사용 예

다음은 서버에서 제공하는 MCP 도구를 사용하는 방법의 예입니다. 이 예에서는 각 도구에 전달될 수 있는 매개변수를 보여줍니다.

다트 분석

Dart 코드에서 오류, 경고 및 린트를 분석합니다.

{
  "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 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.

기여하다

기여를 환영합니다! 풀 리퀘스트를 제출해 주세요.

도구 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

특허

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.

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