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

Description discloses key behavioral traits beyond annotations: returns immediately with a job_id, eta_seconds ~180s, supports max_results up to 200 vs 50, and include_citation_graph adds processing time. Annotations already indicate read-only, and the description does not contradict them; it adds substantial async-specific context.

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?

Description is well-structured and front-loaded with the variant identification, then capability details, async behavior, polling/webhook options, and use cases. Every sentence earns its place; the only minor vagueness is 'Faster + lighter', but overall it is compact for the information conveyed.

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 an async tool, the description covers the full workflow: submission, immediate job_id, ETA, polling via patent_landscape_result, and webhook registration. It also explains extended capabilities and use cases, while output schema handles return value details. This is complete given the tool's complexity.

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%, so baseline is 3. The description adds semantic value for max_results (explicitly contrasting with sync limit) and include_citation_graph (explains 2-level graph, parent/child definition, and processing overhead), going beyond the schema for these distinctive parameters.

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?

Clearly identifies itself as 'Async extended variant of patent_landscape' and explains its specific capabilities (max_results up to 200, include_citation_graph flag). It distinguishes itself from the sync sibling by describing async behavior and points to patent_landscape_result for polling.

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?

Explicitly lists use cases: deep R&D white-space analysis, freedom-to-operate audits, VC due diligence IP mapping, and large-scale competitor portfolio analysis. It also contrasts with sync mode limits and gives an alternative to polling via webhooks_manage, making the when-to-use vs alternatives clear.

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