Skip to main content
Glama

Dados Abertos Senado BR MCP

Detalhar contratação

senado_contratacao_detalhe
Read-onlyIdempotent

Detalha uma seção específica de uma contratação já identificada pelo id. tipo indica a natureza do registro: contratos (contrato firmado; padrão), atas_registro_preco (compromisso de preços para compras futuras) ou notas_empenho (reserva orçamentária do gasto). secao escolhe o aspecto: itens, pagamentos, garantias (qualquer tipo), aditivos (só contratos) ou acionamentos (só atas_registro_preco). Retorna { id, tipo, secao, count, total, itens } com os registros brutos da seção (campos conforme a API administrativa), limitados a limite (padrão 100, máx 500) — count < total indica truncagem; seção sem registros retorna count 0 e itens vazio; combinações secao×tipo inválidas (ex.: aditivos fora de contratos) retornam erro. Atenção: a fonte NÃO publica o valor do contrato em nenhuma seção; apenas aditivos traz valor, referente ao termo aditivo (às vezes nulo) — não procure valor monetário em itens/pagamentos/garantias. Obtenha o id via senado_contratos ou senado_contratacoes_lista — para localizar a contratação (não detalhá-la) use aquelas ferramentas.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesID da contratação (campo 'id' das listas de contratos/atas/empenhos)
tipoNocontratos = contrato firmado (padrão); atas_registro_preco = compromisso de preços p/ compras futuras; notas_empenho = reserva orçamentária do gastocontratos
secaoYesAspecto a detalhar: itens/pagamentos/garantias (qualquer tipo); aditivos (só contratos); acionamentos (só atas_registro_preco)
limiteNoMáximo de itens (padrão 100, máx 500); count < total sinaliza corte

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  2. Changed2 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. Changed3 schema fields changed
    • changedInput schema / properties / limite / description
      Previous value: -"Máximo de itens (padrão: 100)"New value: +"Máximo de itens (padrão 100, máx 500); count < total sinaliza corte"
    • changedInput schema / properties / secao / description
      Previous value: -"aditivos: apenas contratos; acionamentos: apenas atas"New value: +"Aspecto a detalhar: itens/pagamentos/garantias (qualquer tipo); aditivos (só contratos); acionamentos (só atas_registro_preco)"
    • changedInput schema / properties / tipo / description
      Previous value: -"Tipo da contratação"New value: +"contratos = contrato firmado (padrão); atas_registro_preco = compromisso de preços p/ compras futuras; notas_empenho = reserva orçamentária do gasto"
  4. Changed3 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / id / maximum
      Added value: +9007199254740991
    • changedOutput schema / additionalProperties
      Previous value: -trueNew value: +{}
  5. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": true,
      +  "properties": {},
      +  "type": "object"
      +}
  6. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly/openWorld/idempotent/non-destructive), yet the description adds substantial behavioral context beyond them: truncation signaled by `count < total`, empty-section behavior, error on invalid combinations, and the critical caveat that the source publishes no contract value in any section (only `aditivos.valor`, sometimes null).

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?

Purpose is front-loaded, followed by parameter semantics, return-shape/truncation behavior, data caveats, and routing. Despite its length, every sentence carries actionable information — no filler.

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?

Given four parameters, two enums, an output schema, and read-only annotations, the description covers everything an agent needs: valid combos, defaults, truncation, error cases, a non-obvious data limitation, and how to obtain the `id`.

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 100%, so the baseline is 3, but the description adds integrative meaning by spelling out which `secao` values are valid for which `tipo` and the default `limite`/truncation semantics. It mostly reinforces rather than extends the per-parameter schema text, so it exceeds baseline only modestly.

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?

States a specific verb (detalha) and resource (uma seção de uma contratação identificada por `id`), and explicitly distinguishes itself from the sibling locating tools `senado_contratos`/`senado_contratacoes_lista`. An agent can tell it apart without opening any schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use (detalhar a seção de uma contratação já identificada) and when-not (para localizar a contratação, use as ferramentas de lista). Also states the valid `secao`×`tipo` combinations and that invalid combos error out.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.