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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't need to re-cover safety. It adds genuinely valuable context: the pay-per-query cost model with prepaid credit, the fact that no platform credentials are needed, data sensitivity (not confidential, same as available to citizens), and LGPD obligations for the client as data controller. This is exactly the kind of beyond-annotation context (auth needs, cost, legal) the rubric rewards.

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 a run-on stretch of colon and comma-separated clauses cramming in purpose, hosting model, payment terms, data sensitivity, and legal responsibility. Every sentence does carry information, but the most important information (what SINTEGRA MS is and what it returns) competes for attention with billing and legal disclosures. It's acceptable but not tight — it reads more like a terms-of-service blurb than an API description.

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?

For a simple tool (2 plain string params, no output schema, no nested objects, no enums), the description covers the essentials: purpose, what data it accesses, and the legal framing around that data. The annotations handle safety profiling. However, it omits practical details a caller would want, such as what kind of results come back, what happens on a missing/invalid IE/CNPJ, or whether the result varies from the citizen-facing version in any way. Serviceable, with room to grow.

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?

With 0% schema description coverage and 2 parameters (ie and cnpj), the description carries the full burden of explaining parameters but says nothing about them. A caller unfamiliar with 'ie' (Inscrição Estadual) or how it relates to 'cnpj' would get zero help. The description was the only place to clarify these parameters and entirely missed the opportunity — an especially damaging gap for a query tool where the parameters are the input.

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 clearly identifies a query operation against SINTEGRA MS ('consulta em fonte oficial') — a specific verb ('consulta') and resource (SINTEGRA MS, a known Brazilian state taxpayer database). It distinguishes itself from the sibling tools (authenticate, connect, marketplace, report_bug, show_version, toolkit_info) by being the only data-query tool. It loses a point because the core purpose is somewhat diluted under pricing and LGPD compliance language rather than crisply stating it queries Brazilian state tax registration data.

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?

There is no explicit guidance on when to use this tool versus alternatives, and no when-not-to-use instructions. The description provides context — hosted platform, no platform credentials, prepaid credit, queries official non-confidential sources — but never explains how a caller should decide to invoke this over another tool. The compliance framing ('o cliente é o controlador dos dados') implies conditions for use but doesn't deliver actionable selection guidance.

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