Patent

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real context beyond them: the specific upstream sources queried, the fact that the PatentsView citation graph is paused (a coverage limitation), and a 'not legal advice' disclaimer. It still omits return format and any rate/coverage caveats per source.

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?

Three short sentences, front-loaded with the core action and followed by the scope limitation and disclaimer. No filler or repetition.

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 two-parameter lookup tool with annotations covering safety, the description is nearly complete; the source-coverage and paused-graph notes are valuable. The one gap is that with no output schema, the shape of returned citation records (counts, fields, ordering) is left unstated.

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 description coverage is 100% and the enum values for 'direction' are fully documented in the schema, so the description adds nothing beyond what structured data already provides. Baseline 3 is appropriate.

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 (list) and resource (documents cited by / citing a patent), plus the three data sources used. It clearly carves out scope versus the paused PatentsView citation graph, though it never names the actual siblings (get_patent, search_patents, search_prior_art) to differentiate against.

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?

Usage is implied by the scope statement and the caveat that the full PatentsView graph is paused, which tells the agent when this tool is the available option. However there is no explicit when-to-use versus get_patent or search_prior_art, and no guidance on when 'direction' should be narrowed.

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

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

Annotations only declare readOnlyHint and openWorldHint, so the description usefully adds that data comes from USPTO and conditionally EPO ('when configured'), and that 'Missing text is omitted rather than filled in' — important partial-result behavior for an agent. It omits error/not-found handling and any rate-limit or latency 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?

Three short sentences, front-loaded with the retrieval scope and sources, followed by the omission caveat and disclaimer. No filler; every sentence carries distinct information.

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 correctly states what is returned and notes that missing fields are dropped, which is the key detail for parsing. It could still say what happens on an unknown/invalid number, but for a one-parameter lookup it is largely complete.

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 description coverage is 100% and the single parameter documents accepted formats (US12000000, 12000000, EP0351918) plus length bounds. The description adds no further format or normalization guidance, so the baseline of 3 is appropriate.

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 gives a specific verb ('Fetch') and resource ('one patent') and enumerates the returned fields (title, abstract, claims, status, family, citations). The singular scope implicitly separates it from search_patents and search_prior_art, but no sibling is named explicitly, and the inclusion of citations slightly overlaps find_patent_citations without clarification.

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?

Usage is only implied: the tool takes a single patent number and returns one record's details, so an agent can infer it is for retrieving a known patent rather than discovering patents. There is no explicit when-to-use, when-not-to-use, or named alternative (e.g., search_patents for discovery, find_patent_citations for citation graphs).

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuine provenance context ('Every number in the result was returned by USPTO or EPO') and a legal disclaimer, but says nothing about result limits (schema caps at 25) or how multiple filters combine.

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?

Three short sentences, zero waste, with the scope of the search front-loaded before the provenance and disclaimer clauses. Each 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?

With 8 optional parameters, no required params, no output schema, and no sibling differentiation, the description leaves real gaps: whether filters are ANDed, how many results come back by default, and how this differs from search_prior_art. The provenance note partially compensates but the tool's behavior on multi-filter queries is unstated.

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 description coverage is 100% and the schema already documents formats (CPC symbol, YYYY-MM-DD, EPO vs USPTO claim matching). The description only restates the facet names, adding no syntax or semantics beyond the schema. 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 ('Search') plus resource ('public patent records') and enumerates the facets that can be searched, matching the schema's parameters. It does not, however, distinguish itself from the sibling search_prior_art, which covers very similar ground.

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?

There is no statement of when to use this tool versus find_patent_citations, get_patent, or especially search_prior_art, nor any prerequisite or exclusion guidance. The agent must infer usage purely from the facet list.

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

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

Annotations cover read-only and open-world status, and the description adds real behavioral content beyond them: results are the records the offices actually returned (no synthesis), each carries a Google Patents link, and ranking is lexical word-overlap rather than semantic. The 'not legal advice' disclaimer sets usage expectations. Minor gap: no note on result ordering confidence or rate limits.

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 with the core action, then the ranking caveat, then the disclaimers. Short and free of filler, though the two trailing disclaimer sentences could be merged into one without losing content.

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 adequately: closest returned records with Google Patents links, plus an explicit note on how they are ranked. It omits pagination/refinement behavior and guidance for when the search returns nothing, which is a modest gap for a search 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 description coverage is 100%, with min/max bounds for both 'idea' (20-4000 chars, plain language) and 'limit' (1-25) already documented in the schema. The description adds no meaning beyond 'idea description', 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?

Concrete verb+resource: it converts an idea description into a public-patent search and returns the closest matching records plus Google Patents links. The 'idea description' input differentiates it from keyword-style siblings like search_patents, but no sibling is named explicitly, so differentiation is left to inference.

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 clarifies what the tool is NOT (not a patentability opinion, not legal advice) but gives no positive when-to-use guidance and never contrasts it with find_patent_citations, get_patent, or search_patents. An agent gets no routing rule for choosing this over the keyword-search sibling.

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