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

The annotations already declare read-only and idempotent behavior, and the description adds significant context: no platform credentials are required, each query costs prepaid credit, the data is not confidential, and the client bears LGPD responsibility. This goes well beyond the annotation hints and helps the agent understand the tool's operational implications, though it stops short of detailing rate limits or exact return 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 compact at just three sentences, front-loading the core purpose before addressing cost, hosting, and legal aspects. Each sentence contributes distinct information without redundancy, though the LGPD sentence adds length and might be streamlined.

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 two-parameter read-only tool with no output schema, the description covers purpose, data source, hosting, cost, and data protection obligations. The lack of return-value documentation is a minor gap, but the provided context is otherwise sufficient to understand the tool's behavior.

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 zero schema description coverage, the description needed to compensate by explaining the cpf and cnpj parameters, but it does not. While the variable names are self-explanatory, the description neither details their formats nor clarifies how they relate (e.g., required fields, mutual exclusivity). Since both are optional in the schema, an agent has insufficient guidance to construct valid requests.

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 the tool as a query ('consulta') against the official CNDT source at Tribunal TST, providing a specific verb and resource. It distinguishes itself from generic platform siblings like authenticate or show_version by naming the exact domain and purpose. The scope is unambiguous: retrieving citizen-accessible data from official Brazilian sources.

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 implies usage through context—this is for querying CNDT data from official sources, with a pay-per-query model and no platform credentials. However, it does not explicitly state when to use or not use this tool, nor does it name alternatives among the sibling tools. The guidance is only implicit.

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