An MCP server that provides tools for consulting CEP addresses, weather data, currency exchange rates, and Wikipedia information
This server defines 4 tools with complete input schemas and descriptions, but suffers from significant naming and composition issues that hinder LLM understanding. Tool names lack action verbs (consulta_* prefix is Portuguese for 'query' but not a standard verb pattern), descriptions are present but minimal (averaging ~80 chars, below the 194-char baseline for A+ tools), and parameter descriptions are bare-minimum. No output schemas are documented, error handling lacks recovery guidance, and all tools return raw JSON strings rather than structured responses. The codebase shows competent implementation (proper validation, external API calls) but falls short of production-grade tool design for agentic use.
Consulta de endereço a partir do CEP usando a API ViaCEP
Consulta de clima por cidade ou coordenadas usando Open-Meteo API
Consulta a cotação de moedas em relação ao Real (BRL) usando AwesomeAPI
Busca informações resumidas na Wikipedia (Português). Pode receber palavras-chave, títulos de artigos ou perguntas (ex: 'qual a história de São Paulo?').
Tool names do not follow verb_noun pattern. 'consulta_cep', 'consulta_clima', etc. use a Portuguese translation of 'query' but lack canonical action verbs (get_, search_, lookup_). LLMs trained on English patterns struggle to infer intent from 'consulta_*' prefix.
No output schemas documented. All tools return { content: [{ type: 'text', text: JSON.stringify(...) }] } but the structure of the stringified JSON is never specified. LLMs cannot plan downstream calls or extract required IDs because they don't know what fields to expect.
Error messages lack recovery guidance. When an input is invalid (e.g., 'CEP deve conter exatos 8 dígitos'), the error tells what went wrong but not what the LLM should do next. Should suggest: 'Validate CEP format: 8 digits, optionally formatted as XXXXX-XXX. Retry with corrected input.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Tool descriptions are too brief (averaging 80 chars; baseline 194 chars). E.g., 'Consulta de endereço a partir do CEP usando a API ViaCEP' does not explain WHEN to use this tool vs. other address lookups, what the response contains, or what prerequisites exist.
Parameter descriptions lack format and constraint detail. E.g., 'CEP para consultar (somente números ou 00000-000)' mentions the format in prose but does not explicitly state the regex pattern or length. A constraint like 'Format: 8 digits (no hyphens or spaces required, optional format XXXXX-XXX)' would be clearer.
All tools return raw JSON as a text string (JSON.stringify). This forces LLMs to parse text, error-prone and wastes tokens. Should return structured content with typed fields. E.g., instead of { content: [{ type: 'text', text: '{"address": ...}' }] }, return { content: [{ type: 'text', text: 'Found address: ...' }, { type: 'object', data: { address, city, ... } }] } or similar structured format.