anvisa-mcp

Overview Schema Source Related Servers Discussions Admin

consultar_status_medicamento

Check drug registration status at Anvisa by searching trade name, active ingredient, or registration number. Get expiry date, holder company, and category.

Instructions

Consulta o status do registro de um medicamento na Anvisa.

Busca por nome comercial, princípio ativo ou número de registro e devolve os registros que casam, com situação ('Ativo' ou 'Inativo', como o arquivo aberto da Anvisa publica), número de registro, data de vencimento do registro, empresa detentora e categoria.

Um princípio ativo comum tem centenas de registros, um por detentor e apresentação: "dipirona" casa com 557. A resposta traz total (quantos casam na base inteira) e retornados (quantos vieram aqui). Quando truncado é True, não conte os resultados para dizer quantos existem, use total.

coletado_em diz quando a base foi atualizada pela última vez a partir do arquivo da Anvisa; acima de 48 horas a resposta traz aviso.

Termo sem correspondência devolve lista vazia. Só quando a base local não existe, está vazia ou não pôde ser aberta a resposta vem com dados de exemplo e fonte='mock': nesse caso, não trate como informação regulatória.

Args: termo: nome comercial ou princípio ativo (trecho, sem precisar de acento), ex.: "dipirona", ou número de registro, com ou sem pontos, ex.: "1.0582.0010". O número de 13 dígitos da apresentação também serve. limite: quantos registros trazer, de 1 a 200. Aumente para ver além dos primeiros.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`termo`	Yes
`limite`	No

Output Schema

TableJSON Schema

Name	Required	Description
`aviso`	No
`fonte`	Yes	'mock' = dado de exemplo, ainda não é registro real da Anvisa
`total`	Yes	Quantos registros casam com o termo na base inteira, não quantos vieram nesta resposta. Um princípio ativo comum tem centenas, um por detentor e apresentação.
`truncado`	No	True quando total > retornados. Os que vieram são os ativos e de nome mais curto; os demais existem e não estão aqui. Não conte os resultados para responder 'quantos registros existem': use 'total'.
`resultados`	Yes
`retornados`	No	Quantos registros vieram em 'resultados', no máximo 'limite'
`coletado_em`	No	Quando a base local foi atualizada pela última vez a partir do arquivo da Anvisa (horário local do servidor). None quando a resposta é dado de exemplo.
`termo_consultado`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedSep 24, 2026

addedInput schema / properties / limite

Added value: +{
+  "default": 20,
+  "maximum": 200,
+  "minimum": 1,
+  "title": "Limite",
+  "type": "integer"
+}

removedInput schema / properties / nome_ou_principio_ativo

Removed value: -{
-  "title": "Nome Ou Principio Ativo",
-  "type": "string"
-}

addedInput schema / properties / termo

Added value: +{
+  "title": "Termo",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "nome_ou_principio_ativo"
-]New value: +[
+  "termo"
+]

addedOutput schema / $defs / RegistroMedicamento / properties / data_situacao / description

Added value: +"Data de vencimento do registro, do campo DATA_VENCIMENTO_REGISTRO do dataset da Anvisa. Não é a data em que a situação atual foi decidida."

changedOutput schema / $defs / RegistroMedicamento / properties / situacao / description

Previous value: -"deferido, indeferido, caducado, em análise"New value: +"Como o dataset aberto da Anvisa entrega: 'Ativo' ou 'Inativo'. O arquivo não distingue cancelado, caducado ou vencido dentro de 'Inativo'."

changedOutput schema / $defs / RegistroMedicamento / properties / visto_na_ultima_coleta / description

Previous value: -"False quando o registro não apareceu no arquivo da última coleta — a situação mostrada pode estar desatualizada"New value: +"False quando o registro não apareceu no arquivo da última coleta, a situação mostrada pode estar desatualizada"

addedOutput schema / properties / coletado_em

Added value: +{
+  "anyOf": [
+    {
+      "format": "date-time",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Quando a base local foi atualizada pela última vez a partir do arquivo da Anvisa (horário local do servidor). None quando a resposta é dado de exemplo.",
+  "title": "Coletado Em"
+}

addedOutput schema / properties / retornados

Added value: +{
+  "default": 0,
+  "description": "Quantos registros vieram em 'resultados', no máximo 'limite'",
+  "title": "Retornados",
+  "type": "integer"
+}

addedOutput schema / properties / total / description

Added value: +"Quantos registros casam com o termo na base inteira, não quantos vieram nesta resposta. Um princípio ativo comum tem centenas, um por detentor e apresentação."

addedOutput schema / properties / truncado

Added value: +{
+  "default": false,
+  "description": "True quando total > retornados. Os que vieram são os ativos e de nome mais curto; os demais existem e não estão aqui. Não conte os resultados para responder 'quantos registros existem': use 'total'.",
+  "title": "Truncado",
+  "type": "boolean"
+}

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, the description carries full burden and does so thoroughly: it discloses truncation via total/retornados/truncado, data freshness via coletado_em, the 48-hour warning, empty-list behavior, and the mock-data fallback with fonte='mock' that must not be treated as regulatory information.

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?

The definition is front-loaded with the core purpose and then adds only high-value operational details in a clear structure with a bold warning and Args section. Every paragraph carries necessary information for correct invocation.

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?

Despite no annotations, the description covers input semantics, output semantics (total/retornados/truncado), freshness, warnings, and fallback behavior, so an agent has everything needed to call the tool and interpret results correctly.

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%, but the Args section fully compensates: termo is explained with examples (dipirona, 1.0582.0010) and the 13-digit presentation number, while limite is specified with the 1-200 range and the guidance to raise it for more records.

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?

Description opens with 'Consulta o status do registro de um medicamento na Anvisa', naming a specific verb, resource, and regulatory scope. It enumerates search keys (nome comercial, princípio ativo, número de registro) and the returned fields, making it easy to distinguish from the sibling buscar_samd_recentes.

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?

It gives rich practical context: partial/accent-insensitive searches, how to increase limite, and what to expect on no match. It does not explicitly contrast with the sibling buscar_samd_recentes, but the usage context is clear and no exclusions are needed.

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

Deploy Server