Skip to main content
Glama

Dados Abertos Senado BR MCP

Requerimentos de CPI

senado_requerimentos_cpi
Read-onlyIdempotent

Lista requerimentos de uma CPI (Comissão Parlamentar de Inquérito) em atividade, pela siglaCpi, com paginação por pagina (índice baseado em 0, definido pelo upstream). Retorna { siglaCpi, pagina, count, requerimentos }, onde requerimentos é a lista de registros brutos da página (campos conforme a API: tipicamente número, data, ementa, autor e situação do requerimento). count é o tamanho da página; uma página além do total retorna count 0 — use isso para saber que as páginas acabaram. Descubra as siglas via senado_listar_comissoes com tipo=cpi. Limitação conhecida: o endpoint upstream costuma responder vazio mesmo para CPIs em atividade, e não há fonte alternativa limpa na API; nesses casos o retorno traz count 0 e um campo aviso explicando — não interprete lista vazia como certeza de que a CPI não possui requerimentos.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paginaNoPágina da lista (padrão: 0)
siglaCpiYesSigla da CPI (ex: CPIVD, CPIPED)

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
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / pagina / maximum
      Added value: +9007199254740991
    • changedOutput schema / additionalProperties
      Previous value: -trueNew value: +{}
  4. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": true,
      +  "properties": {},
      +  "type": "object"
      +}
  5. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare read-only/idempotent/safe, and the description goes well beyond them: it discloses a known upstream limitation where the endpoint returns empty even for active CPIs, and that such responses carry count 0 plus an 'aviso' field. This is high-value behavioral context that cannot be inferred from annotations.

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?

Front-loaded with purpose, then pagination, then routing, then the caveat — a logical order. It is somewhat long and partially restates the return shape that the output schema already covers, which is the only reason it is not a 5.

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 two-parameter paginated list tool with an output schema, the description covers everything an agent needs: how to get the sigla, how pagination terminates, and how to interpret the misleading empty-result case. No material gap remains.

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 meaning the schema lacks: pagina is a 0-based index whose semantics are defined by the upstream, and siglaCpi values must be discovered via a sibling tool. It stops short of adding format/syntax details beyond the schema example.

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+resource ('Lista requerimentos de uma CPI') with scope ('em atividade') and keyed identifier ('pela siglaCpi'). It distinguishes itself from siblings by routing sigla discovery to senado_listar_comissoes, so an agent can place it 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?

Explicit when-to-use: call it with a sigla obtained from senado_listar_comissoes with tipo=cpi, paginate with pagina, and treat count 0 as end-of-pages. It also gives an explicit when-not-to-conclude rule (empty list ≠ CPI has no requerimentos), which is exactly the guidance an agent needs.

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.