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

Annotations only cover readOnly/openWorld/destructive, but the description adds substantial operational behavior beyond them: live-first querying over a ~12.9M-application index, since/until applied at the source, fallback to a cached recent slice on outage with source:'cache' + coverage_warning and the warning not to infer totals, and browse behavior with no company_name. This is exactly the kind of context annotations cannot carry.

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?

Front-loaded and logically ordered (returns → usage → caveat → coverage), but over-long for the content; the list of eleven example applicant strings is excessive and the coverage paragraph is dense. Several sentences restate schema content, so not every sentence earns its place.

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?

No output schema exists, so the description must cover return semantics, and it does: record shape, source_url follow-up, live/cache coverage semantics, and the applicant-naming pitfall. For a 6-param, complex, open-world tool this is complete enough to call correctly.

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, but the description adds real meaning: the critical caveat that patents are filed under an IP-holding entity rather than the household brand (with 11 concrete legal-string examples), case-insensitive matching, and the live-vs-cache behavior tied to company_name. Some of this duplicates the schema descriptions, so it is above baseline but not fully additive.

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 precise verb+resource: returns US patent applications from the USPTO Open Data Portal, keyed on the corporate APPLICANT. It enumerates exactly what each record contains (title, applicants, inventor count, dates, status, entity size) and names the follow-up source (source_url at USPTO Patent Center), so an agent knows precisely what it gets. No sibling tool covers patents, so differentiation is inherent.

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 explicit, concrete usage contexts ('what is a company patenting', 'how many patents did a company file', cross-referencing R&D against insider/congressional activity, contracts, fundamentals). This maps user intent to the tool clearly, though it never states when NOT to use it or names an alternative sibling.

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