Loading ToolBench
MCP Server for Portal da Transparência API - Multi-step Call Planner. Provides intelligent query planning, data aggregation, and comprehensive API interaction capabilities for the Brazilian Government Transparency Portal, enabling efficient access to public expenditure data, government contracts, and transparency information via MCP protocol.
This server has significant quality gaps across naming, descriptions, and schema completeness. While 6 tools are defined with basic schemas, most fall short of production standards. Tool names use Portuguese prefixes ('portal_') but lack clear action verbs, 'portal_servidores_consultar' vs 'list_servers' would be clearer to LLMs. Descriptions are present but minimal (12-30 chars for most params), leaving LLMs without actionable guidance on parameter purpose, format, and constraints. Input schemas exist but lack required fields, minimum/maximum constraints, and comprehensive parameter validation. No output schemas are documented, forcing LLMs to guess response structure. Error handling is absent, no recovery guidance, no actionable error messages visible in code. Overall, this reads like a proof-of-concept that bypassed production quality gates.
Verificar se a API key está configurada
Consultar contratos públicos
Consultar despesas públicas
Consultar licitações
Consultar servidores do Poder Executivo Federal
Consultar viagens a serviço
No output schemas documented for any of 6 tools. LLMs cannot plan downstream tool calls or know what fields to extract from responses. This violates pattern:tool and pattern:tool-description guidance.
Parameter descriptions are too brief (<30 chars avg). LLMs lack actionable guidance on format, constraints, and dependencies. Example: 'Código do órgão' does not explain what 'código' means (system ID? code string?) or how to obtain it.
No min/max constraints for pagination ('pagina') or date ranges. LLMs can pass invalid values (page 0, negative days, year 1970). Unbounded parameters cause API failures or timeouts.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 46 | 2024-11-05+ | v1 |
Date format constraints ('DD/MM/YYYY', 'YYYYMM') are stated in parameter descriptions as free text, not as regex patterns in the schema. LLMs cannot parse this and may pass invalid formats (2024-01-01 instead of 01/01/2024).
No error handling visible. No recovery guidance, no categorization of retryable vs fatal errors, no actionable error messages. A network failure or API rejection leaves the LLM unable to recover.
Inconsistent naming convention. Tool names mix Portuguese verbs ('consultar') with English context, and parameter names are Portuguese ('codigoOrgao', 'dataIdaDe'). LLMs trained primarily on English tooling will have difficulty inferring intent.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) declared. All tools appear to be read-only queries, but this is not formally signaled. Agents cannot optimize or classify tool safety without explicit hints.
No pagination result limits documented. Queries like 'list all servers' or 'list all expenses for a year' could return thousands of items, exhausting context. No guidance on max results per call or when to cap results.
No guidance on how to resolve 'órgão' (government agency) codes. A user might say 'Ministry of Finance' but parameter requires a numeric code like '26000'. No discovery tool or mapping provided.