Skip to main content
Glama
Juris Licita MCP
by bitbusca

Detalhe do edital

ler_edital
Read-onlyIdempotent

Retrieve a tender's items, documents, key dates, and issuing agency by ID to inspect public-procurement details and support bid decisions.

Instructions

[Avançado: exige BITBUSCA_API_KEY] Mostra itens, documentos, datas e órgão de um edital.

Input Schema

NameRequiredDescriptionDefault
idYesId do edital (campo "id" de buscar_editais_bitbusca).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds the one thing annotations cannot: this call requires an advanced plan/API key (BITBUSCA_API_KEY), which is a real gating precondition an agent must check before invoking. It does not describe behavior for an unknown or expired id.

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?

Two short clauses with the prerequisite bracketed up front and the returned content immediately after – no filler. Density is high, though the extreme brevity leaves the gaps noted in the other dimensions.

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

Completeness3/5

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

For a one-parameter read tool this largely suffices, and because there is no output schema the enumeration of returned fields (itens, documentos, datas, órgão) is a useful stand-in. Still missing: whether the id comes only from buscar_editais_bitbusca, and what happens on a missing/blocked id, which matters because the tool is gated behind an API key.

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

Parameters3/5

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

Schema description coverage is 100% and the single 'id' parameter already documents its provenance ('campo id de buscar_editais_bitbusca') and length limits. The description adds nothing about the parameter, so the baseline 3 applies.

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

Purpose4/5

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

States a specific verb and resource (show detail of one edital) and enumerates what the payload contains: itens, documentos, datas and órgão. It is clearly a detail-fetch by id, distinct from the search tool named in the schema, though it never names its closest siblings (resumo_edital, analisar_edital) to sharpen the boundary.

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

Usage Guidelines3/5

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

Usage is only implied: the 'Avançado: exige BITBUSCA_API_KEY' tag plus the schema note pointing at buscar_editais_bitbusca suggests 'search first, then fetch detail with the returned id'. There is no explicit when-to-use or when-not-to-use versus resumo_edital or analisar_edital, which an agent would need to choose correctly in this crowded sibling set.

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