protocolos-pcdt-mcp

Overview Schema Source Related Servers Discussions Admin

consultar_protocolo

Find the current Brazilian Ministry of Health PCDT clinical protocol for a disease or condition, returning approved protocol details, PDF links, and extracted sections.

Instructions

Consulta o PCDT vigente do Ministério da Saúde para uma doença ou condição.

Procura primeiro no nome dos PCDTs, sem acento, com as palavras em qualquer ordem e aceitando algumas siglas ("HAS", "DPOC", "DM2") e a grafia "diabetes mellitus". Se o nome não casar, procura o termo no texto dos protocolos e devolve até 5, com origem="texto" e um aviso: esses só citam o termo e muitas vezes não são o PCDT da condição.

Cada resultado traz identificador (use em resumir_conduta), nome da condição, portaria, link do PDF completo e do PCDT resumido, seções extraídas e se o texto completo já foi coletado. O status vem do CSV de dados abertos e só existe para parte dos PCDTs; null não quer dizer que o protocolo não está aprovado. Se houver mais de um protocolo pelo nome, devolve todos (até 10), a escolha é de quem pergunta.

Args: doenca_ou_condicao: nome da doença ou condição, por exemplo "asma".

Input Schema

TableJSON Schema

Name	Required	Description	Default
`doenca_ou_condicao`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`aviso`	No
`termo`	Yes
`total`	Yes
`resultados`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 24, 2026

addedOutput schema / $defs / Protocolo / properties / nota_atualizacao

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Nota de revisão que o portal põe ao lado do nome, ex. 'Anexo alterado em ...'",
+  "title": "Nota Atualizacao"
+}

addedOutput schema / $defs / Protocolo / properties / origem

Added value: +{
+  "default": "nome",
+  "description": "'nome': o termo casou com o nome do PCDT. 'texto': o nome não casou e o protocolo só cita o termo em algum ponto do texto",
+  "enum": [
+    "nome",
+    "texto"
+  ],
+  "title": "Origem",
+  "type": "string"
+}

First observedv0.1.0Sep 21, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations at all, the description carries the full behavioral burden and does so thoroughly. It discloses the two-phase search strategy (name first then text), exact matching nuances (accents, word order, acronyms, 'diabetes mellitus'), the 5-result fallback with origin='texto', the status CSV null caveat, and the return of up to 10 protocols when multiple name matches exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Although the description is longer than typical, every sentence earns its place: it covers purpose, search behavior, result fields, an important null-status caveat, and parameter guidance. It is well-structured with the primary sentence firstched and the argument documented at the end.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter lookup tool with an output schema and no annotations, the description is complete. It tells the agent how the search works, what edge cases exist (text matches, multiple protocols, null status), and how to connect to the sibling tool, so there is no ambiguity about how to invoke it successfully.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and there is only one parameter, but the description fully compensates. The 'Args' section defines doenca_ou_condicao with an example, and the main body adds substantial matching semantics that tell the model exactly what kind of input is acceptable and how it will be interpreted.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise verb and resource: 'Consulta o PCDT vigente do Ministério da Saúde para uma doença ou condição.' It clearly identifies the tool as a PCDT lookup for a disease/condition and adds the useful relationship to the sibling tool via the identifier comment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the usage context clear: use it to look up a PCDT by disease/condition)Skip; it even notes that the returned identifier is intended for use in resumir_conduta. It does not explicitly state when not to use it or name alternatives, but with only one sibling and such a distinct lookup purpose, that is not a significant gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server