Contato. Agente sem captcha → 402 $0.10 x402. Após o 1º envio: 429 + Retry-After (backoff).
| Name | Required | Description | Default |
|---|---|---|---|
| nome | Yes | Como chamar quem escreveu. | |
| Yes | Para onde responder. | ||
| mensagem | Yes | O que você quer dizer. | |
| aberto_em | Yes | Momento em que o formulário abriu; é anti-robô do caminho humano. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / properties / aberto_em / descriptionAdded value: +"Momento em que o formulário abriu; é anti-robô do caminho humano."Input schema / properties / email / descriptionAdded value: +"Para onde responder."Input schema / properties / mensagem / descriptionAdded value: +"O que você quer dizer."Input schema / properties / nome / descriptionAdded value: +"Como chamar quem escreveu."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full burden of behavioral disclosure. It does mention a 402 payment requirement and a 429 rate limit with Retry-After, which are useful operational details. However, these are cryptic and not clearly explained (e.g., what does 'x402' mean?). It adds some behavioral context but falls short of being transparent about the tool's core behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse, but it sacrifices clarity for brevity. It is a single cryptic sentence with ambiguous symbols and lacks a clear structure. The purpose is not front-loaded, and the error information is presented without context. This is not effective conciseness; it's under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four required parameters and no output schema, the description should explain what the tool accomplishes and what to expect in return. It only provides error hints and no context about the contact action itself. The agent would struggle to know when to call this tool and what a successful call returns. The description is severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all four parameters (nome, email, mensagem, aberto_em) with 100% coverage. The tool description does not add any additional semantic meaning beyond what the schema already states. Baseline of 3 is appropriate since the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Contato' is a repetition of the tool name in Portuguese, providing no verb or resource. It does not state what action the tool performs, leaving the agent to infer from the parameter names. This is a tautology and fails to differentiate from sibling tools like 'suggest' or 'avaliar'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It only mentions error codes and rate limits, which is unrelated to usage context. There is no mention of scenarios, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a clearly distinct purpose: exact CNPJ lookup, company search, autocomplete, AI filter generation, idea evaluation, reference data, session/watches management, and API utility endpoints. There is no meaningful overlap that would cause an agent to select the wrong tool.
The naming is inconsistent: some tools use verb_noun snake_case (get_cnpj, add_watch, list_watches), some are bare English verbs (search, suggest, contact), and some are bare nouns or abbreviations (health, local, ref, api_index). It also mixes languages, with Portuguese avaliar alongside English names.
13 tools is within a reasonable range for a server covering CNPJ lookup, search, evaluation, monitoring, and API metadata. The count feels slightly broad because several utility endpoints (health, api_index, contact, local) are auxiliary, but no tool is redundant.
The core lookup, search, evaluation, and reference workflows are covered well. However, the monitoring lifecycle is incomplete: add_watch and list_watches exist but there is no remove_watch, and monitor_session has no session status or termination counterpart, creating a dead end for the watch flow.