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

Annotations already cover readOnly, idempotent, non-destructive and closed-world, so the bar is lower. The description still adds real context beyond them: a single input may return multiple records, and the tool is gated behind MCP Pro or RegAI Pro, which is an entitlement constraint an agent cannot learn from annotations.

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?

Leads with the return payload, then the input source and the multi-record edge case, with no filler. The field enumeration in the first sentence is dense but each item tells the agent what to expect, so the length is earned.

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 no output schema, the description carries the return-value burden and does so by listing the payload sections. Entitlement requirement and multi-record behaviour are covered; only not-found or permission-failure behaviour is unaddressed, which is a minor gap for a single-parameter read tool.

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?

Schema coverage is 100% and the parameter's own description already spells out both id forms and the shared-字號 case. The description reinforces this but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource ('Return the full text of a Taiwan financial regulation record') and enumerates what comes back (content, 編註, 法規沿革, attachments, 法規類別, 字號, dates, status). It names search_domain_corpus as the id source, which separates it from the get_law_details / get_article_by_number siblings.

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?

Gives a clear retrieval path (take the id from search_domain_corpus, or supply a 字號) and explains that a shared 字號 returns a 令 plus its companion 函. It stops short of explicit when-not guidance against the other get_* siblings, so the exclusion side is left to inference.

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