Skip to main content
Glama

validar_nota_soap

Validate SOAP clinical notes by checking required fields, ICD codes, and plan numbering, then use a local LLM to verify coherence between complaint, exam, and conduct. All data stays on-device.

Instructions

Valida uma nota clínica no formato #TELEMEDICINA# (F/S/O/A/P).

Checa campos obrigatórios, CID, numeração do plano e rodapé por regras determinísticas, e usa o LLM local para conferir coerência entre queixa, exame e conduta, além de sinais de alarme não investigados. A parte do LLM é probabilística e vem marcada como tal; se ele estiver fora do ar, as regras respondem sozinhas e motivo_semantica_pulada diz por que a semântica não rodou.

O texto processado não sai da máquina nem é gravado em lugar nenhum.

Args: texto_nota: a nota completa, como seria colada no prontuário.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
texto_notaYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
avisoNo
problemasYes
total_errosYes
total_avisosYes
motivo_semantica_puladaNo
checagem_semantica_feitaYesFalse quando a semântica não rodou (motivo em motivo_semantica_pulada); as regras valeram assim mesmo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / checagem_semantica_feita / description
      Previous value: -"False quando o LLM local não respondeu; as regras valeram assim mesmo"New value: +"False quando a semântica não rodou (motivo em motivo_semantica_pulada); as regras valeram assim mesmo"
  2. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description fully carries the behavioral burden. It discloses that LLM-based checks are probabilistic and flagged as such, that offline LLM triggers a rule-only fallback with motivo_semantica_pulada, and that processed text never leaves the machine or is persisted. These are essential behavioral traits beyond the bare input schema.

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

Conciseness4/5

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

Every sentence carries substantive information: purpose, rule/LLM split, privacy, and parameter meaning. It is slightly long but not verbose — the detail about fallback and privacy is valuable, not filler. Front-loading the core purpose is a good structural choice.

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 single-parameter validation tool with an output schema, the description covers input semantics, processing modes (deterministic vs. LLM), failure behavior, and privacy. Since an output schema exists, return details are not required, and the mention of motivo_semantica_pulada aligns with what the schema likely exposes.

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

Parameters4/5

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

Schema coverage is 0%, so the description must compensate. It explains that texto_nota is the complete note 'como seria colada no prontuário', which conveys content expectations and the format (#TELEMEDICINA# F/S/O/A/P). A concrete example or length hint would be an extra improvement, but the given context is sufficient.

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 specific verb ('Valida') and resource (nota clínica no formato #TELEMEDICINA#), and details exactly what is checked (obrigatórios, CID, numeração do plano, rodapé, coerência). This clearly differentiates it from the sibling 'sugerir_correcoes' — validating is not suggesting corrections.

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 provides a clear use context: when a SOAP note needs validation against deterministic rules and semantic consistency. It does not explicitly exclude scenarios or point to the sibling as an alternative, but the scope of validation is concrete enough that an agent can infer when to call it.

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

Deploy Server

Other Tools