Loading ToolBench
MCP server that searches for Brazilian address information by CEP (postal code) using the ViaCEP API
The BuscaCEP server has only one tool (busca_cep) with significant quality gaps. The tool name lacks a clear action verb prefix (should be 'search_cep' or 'get_cep_info'), the description contains a typo ('Buca' instead of 'Busca'), parameter descriptions are minimal, and there is no documented output schema. Error handling is basic (returns dict with 'error' key) but provides no recovery guidance. The schema is visible in the function signature but lacks formal JSON Schema documentation. No pagination, no structured output validation, and no guidance on what fields the LLM should expect in responses.
Buca informações de endereço a partie do CEp fornecido usando a api do ViaCEP.
Tool name does not start with action verb. 'busca_cep' is a Portuguese gerund/command form; English-speaking LLMs expect 'get_', 'search_', or 'fetch_' prefixes. Use 'search_cep' or 'get_cep_info' to match Arcade pattern baselines (90% of A+ tools start with action verb).
Description contains typo ('Buca' instead of 'Busca') and lacks WHEN/WHY context. Current length ~89 chars is acceptable, but it does not state: What does it do? (too terse). When should the LLM use it? (not stated). What does it return? (not documented). Rubric baseline for descriptions: 10 - 1024 chars, with 194 chars average for A+ tools.
Input parameter 'cep' has a description ('The Brazilian postal code (CEP) to search for') that is present but lacks format constraints. No mention of: length (Brazilian CEP is 8 digits), format (XXXXX-XXX or XXXXXXXX), valid character set, or example. Rubric requires: 'Describe the expected format, range, and allowed values directly in the parameter description.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 34 | 2026-07-28+ | v2 |
No documented output schema. LLMs cannot predict what fields the tool returns. The code returns API response directly (address, city, state, etc. from ViaCEP) or error dict with 'error' key, but this is not documented. Rubric critical check: 'Document the output schema. LLMs need to know what fields to expect.' 100% of A+ tools have documented return types.
Error handling is minimal and not LLM-actionable. Tool returns {'error': <message>} but provides no recovery guidance. 'CEP não encontrado' (CEP not found) does not tell the LLM: Can I retry? Should I ask the user? Is this fatal? Rubric: 'Error responses must tell the LLM what to do next: "User not found. Try search_users() with a partial name." A raw error code or stack trace gives the agent nothing to act on.'
No input validation before calling external API. Tool accepts any string as 'cep', passes it directly to ViaCEP, and relies on the API to reject invalid formats. LLM could pass 'abc', 'null', '12345' (too short), or '123456789' (too long) without immediate feedback. Rubric: 'Do not assume LLMs will follow constraints. Validate inputs early and return clear error messages.' Invalid CEP format should fail fast with: 'Invalid CEP format: must be 8 digits (e.g., 12345-678 or 12345678). You provided: <value>.'