ppubs_get_patent_by_number

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

No annotations are provided, so the description must disclose behavioral traits. It states the return content ('Complete patent document with full text of all sections') but does not elaborate on error handling, size, rate limits, or the fact that it's a read-only operation. While the 'get' prefix hints at safety, the description adds limited behavioral context beyond the basic output.

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 concise and well-structured: a one-line purpose, a clear 'USE THIS TOOL WHEN' block, an args section, and a returns section. Every sentence serves a purpose, and the formatting makes it easy to scan. No redundancy or fluff.

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?

Given the single parameter, an output schema (even if not shown), and the description's clear statement of returned content, the tool is sufficiently documented. It could have differentiated more from siblings like ppubs_get_full_document, but the focus on 'by patent number' and 'granted patent' provides adequate context. No missing critical information for a typical use case.

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 schema provides no description for patent_number, and the tool description compensates by specifying the format (no commas) and giving concrete examples ('7123456' or '10000000'). This adds meaningful clarity beyond the bare schema, though it does not cover all edge cases like leading zeros or format variations.

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 states 'Get a granted patent's full text by patent number,' which is a specific verb+resource+mode. It distinguishes from siblings like ppubs_search_patents (search) and ppubs_get_full_document (likely by other criteria) by emphasizing retrieval by patent number and including all sections.

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 'USE THIS TOOL WHEN' section explicitly specifies the condition: knowing the patent number and needing the complete document. This provides clear usage guidance. It does not mention alternatives or exclusions, but the condition is unambiguous and sufficient for most cases.

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