Skip to main content
Glama
enesjakozh
egyleader

Dart MCP Server

by egyleader
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Servidor Dart MCP

versión npm Licencia: MIT insignia de herrería

Un servidor distribuible de Protocolo de Contexto de Modelo (MCP) que expone los comandos del SDK de Dart para el desarrollo basado en IA. Este servidor conecta los asistentes de programación de IA con los flujos de trabajo de desarrollo de Dart/Flutter mediante la implementación del Protocolo de Contexto de Modelo (MCP).

Características

Este servidor MCP proporciona acceso sin inconvenientes a los siguientes comandos del SDK de Dart:

Dominio

Descripción

dart-analyze

Analizar el código Dart en busca de errores, advertencias y pelusas

dart-compile

Compilar Dart en varios formatos (exe, instantáneas AOT/JIT, JavaScript)

dart-create

Crear nuevos proyectos de Dart a partir de plantillas

dart-doc

Generar documentación de API para proyectos de Dart

dart-fix

Aplicar correcciones automáticas al código fuente de Dart

dart-format

Formatear el código fuente de Dart según las pautas de estilo

dart-info

Mostrar información de diagnóstico sobre las herramientas Dart instaladas

dart-package

Trabajar con paquetes (obtener, agregar, actualizar, obsoletos, etc.)

dart-run

Ejecute programas Dart con soporte para pasar argumentos

dart-test

Ejecutar pruebas con soporte para opciones de filtrado y generación de informes

Beneficios clave

  • Manejo inteligente de rutas : resuelve automáticamente rutas relativas a rutas absolutas, lo que garantiza que los comandos funcionen correctamente independientemente del directorio de trabajo

  • Detección automática de proyectos : identifica proyectos de Dart/Flutter en ubicaciones comunes, como directorios de inicio y espacios de trabajo.

  • Compatibilidad multiplataforma : funciona en macOS, Linux y Windows

  • Configuración cero : funciona de inmediato con valores predeterminados razonables

  • Integración con MCP : compatible con cualquier cliente MCP, incluidos Windsurf, Cline y otras implementaciones del Protocolo de contexto de modelo

Related MCP server: Flutter Inspector MCP Server

Prerrequisitos

  • Node.js : 18.x o superior

  • Dart SDK : 3.0 o superior instalado y disponible en su PATH

Instalación

Instalación mediante herrería

Para instalar Dart MCP Server para Claude Desktop automáticamente a través de Smithery :

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

Usando npx (recomendado)

El servidor se puede ejecutar directamente sin instalación usando npx:

npx @egyleader/dart-mcp-server

Instalación global

Para un acceso más fácil, puede instalar el servidor globalmente:

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

Luego ejecútalo usando:

dart-mcp-server

De la fuente

# 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

Integración con clientes MCP

Configuración de IDE de Windsurf/Codeium

Para utilizar este servidor MCP con Windsurf o Codeium IDE, agregue lo siguiente a su archivo mcp_config.json (normalmente ubicado en ~/.codeium/windsurf/mcp_config.json ):

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

Variables de entorno

  • DART_MCP_VERBOSE : Establezca cualquier valor para habilitar el registro detallado para la depuración

Ejemplos de uso de la herramienta MCP

A continuación, se muestran ejemplos de cómo usar las herramientas MCP proporcionadas por el servidor. Estos ejemplos muestran los parámetros que se pueden pasar a cada herramienta.

dardo-analizar

Analizar el código Dart en busca de errores, advertencias y pelusas:

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

compilación de dardos

Compilar código Dart en varios formatos:

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

Formatos compatibles: exe , aot-snapshot , jit-snapshot , kernel , js

dart-create

Crear un nuevo proyecto de Dart a partir de una plantilla:

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

Nota sobre el nombre del proyecto y la salida:

  • Si solo se proporciona projectName , se utiliza como el nombre del directorio donde se crea el proyecto.

  • Si se proporciona output , se utiliza como el directorio donde se crea el proyecto.

  • El nombre real del paquete/proyecto en Dart se deriva del nombre del directorio final mediante la CLI de Dart.

Plantillas compatibles: console , package , server-shelf , web

dart-doc

Generar documentación de API para un proyecto de Dart:

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

arreglo de dardos

Aplicar correcciones automáticas al código fuente de Dart:

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

formato dardo

Formatear el código fuente de Dart según las pautas de estilo:

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

información de dardos

Mostrar información de diagnóstico sobre las herramientas Dart instaladas:

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

paquete dart

Trabajar con paquetes (comandos pub):

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

Comandos admitidos: get , upgrade , outdated , add , remove , publish , deps , downgrade , cache , run , global

carrera de dardos

Ejecute programas Dart con soporte para pasar argumentos:

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

prueba de dardos

Ejecute pruebas con soporte para opciones de filtrado y generación de informes:

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

Licencia

Este proyecto está licenciado bajo la licencia MIT: consulte el archivo de LICENCIA para obtener más detalles.

Contribuyendo

¡Agradecemos sus contribuciones! No dude en enviar una solicitud de incorporación de cambios.

Referencia de la API de herramientas

dardo-analizar

Analizar el código de Dart en un directorio o archivo.

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

Ejemplo:

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

compilación de dardos

Compilar Dart en varios formatos.

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

Ejemplo:

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

dart-create

Crea un nuevo proyecto de 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
}

Nota:

  • Si se proporciona output , el proyecto se creará en ese directorio.

  • Si solo se proporciona projectName , se utilizará como nombre del directorio.

  • El nombre real del paquete Dart se deriva del nombre del directorio final.

Ejemplo:

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

dart-doc

Generar documentación de API para proyectos de Dart.

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

Ejemplo:

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

arreglo de dardos

Aplicar correcciones automatizadas al código fuente de 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
}

Ejemplo:

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

formato dardo

Formatear idiomáticamente el código fuente de 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
}

Ejemplo:

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

información de dardos

Mostrar información de diagnóstico sobre las herramientas instaladas.

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

Ejemplo:

{
  options: ["--verbose"]
}

paquete dart

Trabajar con paquetes (comandos 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
}

Ejemplos:

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

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

carrera de dardos

Ejecutar un programa 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
}

Ejemplo:

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

prueba de dardos

Ejecutar pruebas para un proyecto.

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

Ejemplo:

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

Desarrollo

# Watch mode for development
pnpm run dev

# Build for production
pnpm run build

Manejo de errores

El servidor implementa un manejo integral de errores:

  • Los errores de ejecución de comandos se capturan y se formatean adecuadamente

  • Los problemas de resolución de ruta se informan con diagnósticos detallados

  • Manejo de tiempos de espera para operaciones de larga duración

  • Propagación adecuada del código de salida de los comandos Dart

Contribuyendo

Consulte CONTRIBUTING.md para obtener pautas de contribución detalladas.

Nuestro formato de confirmación es el siguiente:

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

Ejemplo:

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

Licencia

Instituto Tecnológico de Massachusetts (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