Provides a searchable guide and ready-to-use snippets for configuring Delphi projects to work with DelphiCodeCoverage — covering .dproj/Map file setup, DUnitX test runner project structure, CodeCoverage.exe CLI usage, CI pipeline integration, and MVP Form/logic separation patterns to make Delphi Forms testable and coverable.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@delphi-codecoverage how do I integrate Delphi CodeCoverage into my CI pipeline?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Servidor MCP (Model Context Protocol) com um guia prático + snippets de código prontos para configurar projetos Delphi, testes DUnitX e scripts de CI de forma que funcionem corretamente com a DelphiCodeCoverage — indexado e pesquisável por ferramentas como Claude Code, Claude Desktop ou qualquer outro cliente MCP.
O guia foi escrito a partir da documentação e do código-fonte públicos do
projeto DelphiCodeCoverage/DelphiCodeCoverage (README oficial, scripts
.bat de exemplo) — cobre configuração de .dproj/Map file, estrutura de
projeto runner DUnitX, uso da CLI CodeCoverage.exe, integração em CI e o
padrão de separação Form/lógica (MVP) que torna Forms de fato cobríveis.
Sobre licenciamento: a DelphiCodeCoverage (a ferramenta em si) é licenciada em Mozilla Public License 2.0. O DUnitX é licenciado em Apache License 2.0. O conteúdo deste repositório (guia e snippets) é uma obra original, escrita pelo autor deste pacote a partir da documentação pública desses projetos — veja LICENSE para detalhes.
Ferramenta | Para que serve |
| Lista os tópicos do guia |
| Retorna o texto completo de um tópico |
| Busca um termo em todos os tópicos, com trechos de contexto |
| Retorna um snippet pronto de uma categoria |
| Lista todos os snippets disponíveis, por categoria |
| Busca snippets por palavra-chave (nome ou código) |
project-setup (Map file/.dproj), dunitx-runner (projeto console runner),
cli-usage (parâmetros da CodeCoverage.exe), ci-integration (pipeline
build → testes → cobertura), form-mvp-pattern (como manter Forms
cobríveis via separação MVP).
unit_skeleton, dunitx_test_fixture, dunitx_console_dpr,
dproj_coverage_settings, cli_invocation, ci_script_windows.
Related MCP server: Teams Guide MCP
npx (recomendado, sem instalar nada globalmente)claude mcp add delphi-codecoverage -- npx -y mcp-delphi-codecoveragenpm install -g mcp-delphi-codecoverage
claude mcp add delphi-codecoverage -- mcp-delphi-codecoveragegit clone https://github.com/avelsys/mcp-delphi-codecoverage.git
cd mcp-delphi-codecoverage
npm install
npm run build
claude mcp add delphi-codecoverage -- node "$(pwd)/build/index.js"Depois de registrado, o servidor fica disponível em qualquer projeto (escopo
user) ou só no projeto atual (--scope local, se preferir isolar).
claude_desktop_config.json ou .mcp.json){
"mcpServers": {
"delphi-codecoverage": {
"command": "npx",
"args": ["-y", "mcp-delphi-codecoverage"]
}
}
}npm install
npm run watch # tsc --watchConteúdo do guia e dos snippets vive direto em src/topics.ts e
src/snippets.ts (TypeScript puro, sem etapa de ingest/build de dados) —
para atualizar, edite esses arquivos e rode npm run build.
O servidor usa stdio (StdioServerTransport) — para testar localmente sem um
cliente MCP completo, use o MCP Inspector:
npx @modelcontextprotocol/inspector node build/index.jsIssues e PRs são bem-vindos — principalmente correções de conteúdo (algum parâmetro de CLI desatualizado em relação a uma versão nova da DelphiCodeCoverage) ou novos snippets. Abra uma issue descrevendo o que mudou antes de um PR grande.
MIT — veja LICENSE.
Retorna um snippet de codigo Delphi/DUnitX/CLI pronto para uso, de uma categoria especifica
| Name | Required | Description | Default |
|---|---|---|---|
| nome | Yes | Nome do snippet dentro da categoria | |
| categoria | Yes | Categoria do snippet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description is the only source of behavior. It clearly states the tool returns compilable code snippets, which is the core behavior for a get operation. It does not disclose edge cases like invalid categories/names or return format, but for a read-only retrieval tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. The key action and resource appear immediately, and the category qualifier adds necessary constraint without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter snippet getter, the description covers the essence. It lacks guidance on how to discover valid snippet names (via list_snippets) and does not describe the return payload, but given no output schema this is a minor gap rather than a critical one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters documented and categoria restricted by an enum. The description references the category dimension but adds no new semantics about either parameter. Baseline 3 is appropriate where the schema carries the information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states the tool returns a ready-to-use Delphi/DUnitX/CLI code snippet from a specified category, using a specific verb+resource. It clearly distinguishes from siblings like list_snippets and search_snippets by focusing on retrieval of a single snippet, but does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'pronto para uso' and 'de uma categoria especifica' imply the tool is used when a concrete snippet from a known category is needed. However, there is no explicit guidance on when to prefer this over list_snippets or search_snippets, and no mention of prerequisites such as knowing the snippet name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retorna o texto completo de um topico do guia
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Id do topico, ex.: project-setup, dunitx-runner, cli-usage, ci-integration, form-mvp-pattern |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns full topic text, but does not mention whether the output is plain text, markdown, or structured, nor any side effects (though likely read-only). It also doesn't state what happens if the id is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that is front-loaded with the action and resource. It is efficient and easy to parse, though it could add a bit more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter retrieval tool, the description is mostly adequate. However, with no output schema and no annotations, it would benefit from stating the return format (e.g., markdown text) and any error behavior. The sibling list suggests a family of guide tools, but the description doesn't clarify how this relates to get_snippet.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the single 'id' parameter with examples. The description adds no extra parameter meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Retorna') and resource ('texto completo de um topico do guia'), making it clear this tool retrieves the full text of a guide topic. It does not explicitly differentiate from siblings like get_snippet, but the resource type (topic vs snippet) is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need the full text of a topic. It does not explicitly state when to use this over list_topics or search_guide, nor does it mention alternatives. The context is clear but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista todos os snippets disponiveis, por categoria
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It discloses the listing behavior and category grouping, but does not mention return format, ordering, category semantics, or any read-only/authorization implications. This is acceptable for a simple list tool but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single, concise sentence that conveys both the action and the organizing principle. There is no filler or repetition, and the core purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (zero parameters, no output schema, straightforward listing behavior), the description is nearly complete. It tells the agent what the tool returns and how it is organized. It could mention expected output shape or category sources, but these are not essential for invoking a no-argument list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics for the description to clarify. The baseline of 4 applies because the description does not need to compensate for undocumented parameters; its 'por categoria' note provides useful contextual meaning not captured by the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Lista todos os snippets disponiveis' (lists all available snippets). It also adds scope and organization with 'por categoria' (by category). This clearly distinguishes it from siblings like search_snippets, which imply filtering or querying rather than listing everything.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when an agent needs an overview of all available snippets grouped by category. However, it does not explicitly contrast with alternatives such as search_snippets or get_snippet, nor does it state when not to use it, so some inference is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista os topicos do guia de configuracao de projetos Delphi/DUnitX para uso com a DelphiCodeCoverage
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It states that the tool lists topics, which implies a read-only operation, but it does not disclose output format, ordering, or any limitations beyond the guide scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. The main verb and resource appear first, and the scope is provided compactly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description is nearly complete: it identifies the guide, the topic objects, and the technical context (Delphi/DUnitX with DelphiCodeCoverage). It could mention the expected return shape, but that is not required by an output schema and is fairly inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties and 100% schema description coverage, so the baseline is 4. The description correctly focuses on the operation rather than parameters, adding no unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Lista' and identifies the exact resource: the topics of the Delphi/DUnitX project configuration guide for DelphiCodeCoverage. It clearly differentiates itself from siblings like list_snippets, which would list different content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: call this when you want an overview of the guide's topics. However, it gives no explicit guidance about when to prefer this over get_topic or search_guide, and it names no alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca um termo em todos os topicos do guia, retornando trechos de contexto
| Name | Required | Description | Default |
|---|---|---|---|
| termo | Yes | Termo de busca |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It usefully discloses the broad scope (all topics) and the return type (context excerpts), but does not explain matching semantics, case/accent sensitivity, or response limits. This is adequate but leaves behavioral details unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence contains the action, scope, and output, with no filler or redundant clauses. The most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter search the description is mostly usable, but without an output schema or explicit mention of search behavior, an agent cannot fully anticipate the result shape. The overlap with search_snippets is also unresolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents the single termo parameter and the description simply restates it ('um termo'). No additional format, encoding, or matching detail is added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Busca'), a resource ('todos os topicos do guia'), and states the output ('trechos de contexto'), so an agent can tell this is a full-guide search rather than a list/get operation. However, it does not explicitly differentiate from the sibling search_snippets, leaving possible overlap ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose search_guide over search_snippets or other siblings. The description implies a broad full-guide search, but it never names alternatives or says when not to use them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca snippets por palavra-chave (nome ou conteudo do codigo)
| Name | Required | Description | Default |
|---|---|---|---|
| termo | Yes | Termo de busca |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It simply states the action ('Busca snippets') but does not mention what is returned (e.g., list of matching snippets), whether the search is case-insensitive, if partial matches are allowed, or any error behaviors. The operational characteristics are left entirely implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant filler. It front-loads the action and resource. However, it is under-specified in content, which is a completeness issue rather than a conciseness one; the structure itself is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, no output schema, and no annotations, the description is minimal. It lacks information about the result format, potential limitations (e.g., pagination, maximum terms), or any side effects. An agent calling this tool would not know what to expect in response, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only describes 'termo' as 'Termo de busca'. The description adds meaningful context by clarifying that the term matches against both nome (name) and conteudo do codigo (code content). This goes beyond the bare schema and helps the agent understand the parameter's scope, compensating for the schema's brevity despite 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Busca' = search) and resource ('snippets'), and clarifies the scope by specifying the search matches 'nome ou conteudo do codigo' (name or code content). This distinguishes it from siblings like list_snippets (listing) and get_topic (topics). However, it does not explicitly contrast it with search_guide, leaving slight ambiguity about which search tool applies to which resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs. alternatives. It does not mention that it should be used for keyword-based snippet lookup instead of listing all snippets or searching guides. The context of siblings is present, but the description itself offers no selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_snippetget_topiclist_snippetslist_topicssearch_guidesearch_snippetsScored across 6 tools
Each tool targets either snippets or guide topics, and within each resource, list, search, and get are clearly distinct actions. There is no meaningful overlap or ambiguity between the six tools.
Tool names follow a consistent verb_noun pattern for snippets (list_snippets, search_snippets, get_snippet) and mostly for topics (list_topics, get_topic). The only minor deviation is search_guide, which would be more consistent as search_topics, but the pattern remains predictable.
Six tools is an appropriate size for a focused reference server covering snippets and guide topics. Each tool has a distinct purpose and the count feels neither thin nor bloated.
The server provides full list/search/get coverage for both snippets and guide topics, which matches its stated purpose as a code coverage reference and snippet library. No obvious missing operations or dead ends are apparent.
Provides access to Avalara developer documentation, integration guides, and code examples
Get up-to-date, version-specific documentation and code examples from official sources directly in…
Retrieve information from the Medusa documentation to assist you with your Medusa development.
Serves your design system and coding standards to coding agents, so they stop guessing.
