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

With no annotations, the description carries the full burden, and it does disclose one genuinely important behavior: an empty answer means no cited rule exists and nothing follows from that absence. This prevents the common misreading of null as 'not required'. It stops short of stating read-only status or result shape explicitly, but the dataset-query framing makes the read nature evident.

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?

Two tight sentences with no filler, and the critical null-semantics caveat is stated up front rather than buried. The opening noun phrase ('Rows on whether...') is slightly awkward as a tool summary but costs little.

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?

An output schema exists, so return structure need not be described, and the tool is simple with one required parameter. However, the missing office-value format is a real gap for actually invoking it, and the description says nothing about coverage across offices or row granularity.

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 single parameter 'office' has 0% schema description coverage and no enum, so the description must compensate. It only obliquely indicates that 'office' means a patent office; it gives no format, naming convention, or accepted values, leaving the agent to guess whether to pass a code, an acronym, or a full name.

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 names a specific resource: rows recording whether a given patent office requires an AI-use statement. That is concrete enough to separate it from siblings like rep_required or fee_schedule, but it is phrased as a noun fragment rather than a verb+resource, and it never explicitly contrasts itself with those other rules tools.

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 agent can infer it should call this when it needs an office's AI-disclosure rule. The second sentence gives a valuable interpretation rule for empty results, but there is no explicit when-to-use/when-not-to-use guidance and no named alternative among the many sibling rules tools.

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?

No annotations are supplied, so the description carries the full behavioral burden. It lists data fields, which hints at read-only retrieval, but it never states that the tool has no side effects, whether it reflects the current deployment, or any other behavioral trait.

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 short, but it is a fragment with a colon-delimited list and no main verb. It is compact yet poorly structured for an agent trying to understand the operation.

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 zero parameters and an output schema present, the description need not document return values in detail. However, it still leaves the core operation implicit and does not clarify what the tool actually does beyond exposing a set of fields.

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?

There are zero parameters, so there is no parameter semantics to add or clarify. The baseline for a no-parameter tool 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?

The description names the resource ('the build in service') and enumerates metadata fields, but it is a sentence fragment with no verb, so the operation must be inferred. It is distinguishable from the unrelated siblings, but the core action is not stated.

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 guidance on when to call this tool, when not to, or what alternatives exist. For a zero-parameter introspection tool usage is somewhat implied, but nothing explicitly routes the agent.

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?

No annotations are supplied, so the description carries the full burden. It does disclose a meaningful behavioral trait with 'Record facts only' (no legal interpretation or recommendation) and reveals the fields available for uncertainty handling via the 'unknown' status, but it says nothing about access requirements, rate limits, data freshness beyond 'as_of', or failure behavior for invalid IDs.

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?

A single front-loaded sentence with no filler, leading with the core purpose before listing returned fields. The enumeration of return fields is somewhat redundant given an output schema exists, which keeps it from a 5.

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?

Return values are covered by the output schema and need not be restated, so the remaining burden is input format and routing guidance. It is adequate for a one-parameter read tool, but leaves the agent without patent_id format rules or comparison to sibling tools.

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 0% for the single required parameter, so the description must compensate. 'One US patent' narrows patent_id to a US patent identifier, but it does not specify whether that is a patent number, application number, with or without kind code or commas — format detail an agent must guess.

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 ('one-call verdict for one US patent') and enumerates the exact status vocabulary (active, expired_term, expired_fee_nonpayment, withdrawn, unknown), which pins down what the tool actually returns. An agent can distinguish this consolidated status lookup from siblings like get_patent_brief or search_patents without opening any schema.

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 one-call verdict for one US patent' implies this is the single-patent status path rather than a search or brief tool, but no explicit when-to-use or when-not-to-use rule is given. Nothing tells the agent when to prefer get_patent_brief over this, or what to do if the patent ID is non-US.

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?

With no annotations, the description carries the full burden. It usefully discloses that results are in-force as of a date, include currency, and carry a per-row official source and quote, which signals authoritative sourcing. It says nothing about authentication, rate limits, error behavior for unknown offices, or whether historical dates are supported — gaps for a zero-annotation tool.

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?

One front-loaded sentence with the scoping parameter and default stated early, and the enumerated fee categories plus row provenance all earning their place. No filler or restatement of the name.

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 read-only lookup with an output schema present, this covers the essential semantics (what is returned, date framing, provenance). The missing piece is office identifier conventions and behavior on unsupported offices/dates.

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 0%, so the description must compensate, and it does for as_of: explicit YYYY-MM-DD format and a default of today UTC. For the required office parameter it only says 'of a patent office', leaving the accepted identifier form (e.g., EPO vs. EP) unspecified — the single biggest remaining ambiguity.

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 names a specific resource (official patent-office fees) and enumerates the categories returned (filing, search, examination, grant, renewal), so an agent knows exactly what this tool produces. No explicit verb ('returns'/'fetches') and no sibling comparison, but no sibling in the list covers fees, so ambiguity is low.

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 by the resource itself — an agent can infer this is the tool for cost lookups. There is no statement of when to prefer it over alternatives, no prerequisite (e.g., office code must be known beforehand), and no exclusions or caveats about jurisdictions not covered.

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?

With no annotations, the description carries the full load, and it does disclose meaningful behavior: the endpoint path signals a read-only GET, offsets are defined as text[start:end], the scope of 'flags' is bounded ('describe the text and the data only'), and version/as_of fields are called out. It omits error behavior and any rate/auth limits, which keeps it short of a 5.

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 core purpose is front-loaded, but it is a single dense sentence packed with comma-separated enumerations, including an awkward clause about 'the earlier mention each "the"/"said" phrase was matched to.' Each element is informative, yet the block is harder to scan than it needs to be.

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?

An output schema exists, so the long enumeration of return fields is arguably redundant, but the added semantics (offset convention, flag scope, version fields) go beyond it. What is missing for a one-parameter tool is only the patent_id format, which is a modest gap given the rest of the coverage.

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 0% for the single parameter, so the description must compensate. 'One US patent' conveys that patent_id identifies a US patent, but the expected identifier format or example is never given, leaving a real gap for a caller formatting the argument.

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 names a specific verb and resource: 'The claims of one US patent as a tree,' and then enumerates the exact per-claim fields returned (number, category, dependency, preamble, transition, elements, term mentions, references, flags). That makes it clearly distinct from siblings like get_patent_brief or search_patents, though it never explicitly contrasts itself with them.

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 when-to-use guidance, no statement of when a caller should pick this over get_patent_brief or search_patents, and no prerequisites. Only an implicit scoping constraint ('one US patent') tells the agent anything about appropriateness.

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?

No annotations are supplied, so the description carries the full behavioral burden. It specifies truncation semantics ('the first item that does not fit ends the brief'), that 'truncated and omitted say what was left out', the token-counting proxy and guarantee 'never over max_tokens', plus anchor/quote conventions and the GET endpoint. That is unusually complete for a read tool; only auth and error cases are absent, which are secondary here.

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 front-loaded with purpose, but it is a dense single paragraph with semicolon-delimited clauses that is hard to scan. Some response-format detail is redundant because an output schema exists, though most sentences still carry useful behavioral 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?

The tool has an output schema, so return shape need not be explained, yet the description adds important truncation and token-budget behavior. Missing patent_id format guidance and error behavior keep it from being fully complete for a two-parameter retrieval 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 0%, so the description must compensate. It gives max_tokens range, default, and tokenizer proxy, and shows patent_id in the endpoint path, but it does not state accepted patent_id formats. That is meaningful compensation with one clear gap.

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 states a specific resource and scope: a token-limited brief of one US patent, including status, claims, and term keys. It is clear what the tool does, but it never names or differentiates itself from siblings such as get_claim_tree or check_patent_status.

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 emphasis on fitting max_tokens and the brief format, but there is no explicit when-to-use guidance, no exclusions, and no named alternatives. An agent can infer it is for compact patent summaries under a token budget, but must decide against siblings on its own.

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?

No annotations are provided, so the description carries the full disclosure burden. It does usefully disclose a key behavioral limit — output is citations only and does not evaluate whether a disclosure falls within the period — but says nothing about what happens with an unrecognized office, error behavior, or the shape/coverage of the returned law.

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?

Two short sentences with the core purpose front-loaded and the scope caveat immediately after. No filler, though the opening clause 'What the cited law of an office says' is slightly indirect compared to a direct verb-led phrasing.

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?

An output schema exists, so return values need not be explained, and the citation-only limitation covers the main misuse risk. What is missing is the semantics of the sole required input, which is the one thing an agent must get right to call the tool successfully.

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 0% for the single required 'office' parameter, and the description only refers to it obliquely as 'an office'. It never states the expected identifier form (e.g., office code, name, or jurisdiction) or which offices are valid, so the only parameter remains underspecified in both schema and prose.

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 names a specific resource (the grace period disclosures before filing as stated by the cited law of a given office) and scopes it as a citation lookup. It is clear enough to distinguish from generic search tools, though it never names a sibling such as search_disclosures or rules_index as the alternative.

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 an implicit when-not-to-use in 'Citations only: it does not say whether any disclosure falls inside the period', which tells the agent not to rely on it for applicability determinations. However, there is no explicit guidance on when to pick this over sibling rule tools, no prerequisites, and no statement about the required 'office' value.

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?

No annotations are supplied, so the description carries the full behavioral burden. It does disclose the core selection rule—rows for to_office whose cited source names from_office as a partner—but it omits whether the operation is read-only, how results are paginated, and what happens when no rows match.

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 definition is one sentence with no filler, and the key constraint is front-loaded. The phrasing 'rows of to_office' is slightly awkward, but the compactness suits this query tool.

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 query tool with an output schema, the description covers the main selection logic and need not explain return shape. It remains incomplete on parameter value formats and usage context, which matters because schema descriptions are absent.

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 input schema has 0% description coverage, so the description must compensate. It explains the roles of both parameters—to_office is the office whose PPH rows are listed and from_office is the partner named in the cited source—but it does not specify expected formats such as office codes.

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 identifies the resource (Patent Prosecution Highway rows) and the directional filter between to_office and from_office, making the purpose more than a restatement of the tool name. It does not distinguish this tool from sibling patent-data lookups such as route_windows, which keeps it below a 5.

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?

It gives no explicit when-to-use or when-not-to-use guidance and never names alternatives among the many sibling tools. At best, the filter wording implies it is for PPH route lookups between two offices, so usage must be inferred.

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?

No annotations are supplied, so the description must carry the behavioral burden. It discloses that each output row includes an official source and quote, which is useful context about result composition, but it never states that this is a read-only lookup, what happens with an unrecognized office code, or whether results can be empty.

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?

Two dense sentences with the core purpose front-loaded and no filler. The embedded parentheticals for office values and the act vocabulary are slightly clumsy but each carries real 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?

For a two-parameter read lookup with an output schema present, the description covers purpose, permissible office values, and act filtering semantics. Return-value detail is unnecessary since the output schema handles it, leaving no significant gap for an agent to call this 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?

With 0% schema description coverage, the description compensates well: it enumerates the accepted office values (US, EP, CN, JP, KR, AU, PCT) and explains that act restricts results to a single act from the vocabulary, pointing at rules_index to discover those values. The default-null behavior of act (return all acts) is only implied, not stated.

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 names a specific resource (representation rules of a patent office) and the exact question it answers: whether and when an applicant must act through a registered agent, with official source and quote per row. It does not explicitly distinguish itself from siblings like rules_index or route_windows, though it does reference rules_index as the vocabulary source.

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?

Guidance is implied through the mention that 'rules_index lists' the act vocabulary, which routes the agent to the sibling for discovering valid act values. However, there is no explicit statement of when to use this tool versus alternatives or what it does not cover, leaving the agent to infer the selection conditions.

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?

There are no annotations, so the description must carry the behavioral burden. It implies a stateless, read-only lookup by stating it takes no application number or date, and an output schema covers return values, but it says nothing about office coverage, behavior for unsupported offices, or data currency.

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?

Two short sentences, front-loaded with purpose followed by the scoping caveat. Little waste, though the second sentence reads as a defensive disclaimer rather than positive guidance.

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 simple one-parameter lookup with an output schema, the description covers purpose and scope boundaries adequately. It falls short on the practical detail an agent needs to call it successfully: what office identifier format is expected and which offices are supported.

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 single required 'office' parameter has 0% schema description coverage and no enum. The description only implies the parameter's concept ('windows of a patent office') and gives no guidance on accepted values or format (e.g., 'US' vs 'USPTO'), leaving the only parameter under-specified.

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 names the resource clearly: generic procedural time windows for a patent office, with a concrete example (PCT national phase limit in months from priority date). It also rules out a related but different capability ('never a last day for a specific application'), so an agent can distinguish it from deadline-calculation tools, though it doesn't name a specific sibling.

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?

It states the usage context (generic office-level windows) and an explicit exclusion (not application-specific last days, takes no application number or date). The gap is that it doesn't name an alternative tool to use for application-specific deadlines, leaving the agent to infer the routing.

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?

With no annotations supplied, the description carries the full behavioral burden, and it does disclose the key trait: results are ordered newest first and the listing starts after the given marker. It says nothing about result volume, pagination, or whether 'since' is inclusive or exclusive, and nothing confirms this is a read-only operation beyond the noun 'releases'.

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?

A single front-loaded sentence with no filler, and the ordering and filter are stated before any detail. It is slightly dense and parenthetical, but nothing in it is wasted.

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?

An output schema exists, so return values need not be explained, and the one optional parameter is well covered in the description. What is missing is anything about result set size or pagination for a changelog that could be long, which matters for an agent deciding whether one call suffices.

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 0%, so the description must compensate, and it does: it states that 'since' accepts either a version in x.y.z form or a date in YYYY-MM-DD and that releases are returned after that point. What it leaves unstated is the consequence of omitting the optional parameter, presumably the full history, but the dual-format meaning is the harder information and it is supplied.

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 identifies the resource concretely ("the rules dataset's releases") and its ordering ("newest first"), so an agent can tell it returns a changelog rather than rules content. It does not, however, distinguish itself from the sibling rules_index, which an agent may reasonably confuse with it.

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 explicit when-to-use guidance, no mention of when not to use it, and no reference to the sibling rules_index as an alternative way to reach rules data. The only usage hint is the implicit 'use since to start partway through the history', which the agent must infer.

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?

No annotations are supplied, so the description carries the full burden; it discloses the payload contents but not the operational profile. Nothing says whether this is a cheap static snapshot or an expensive aggregation, or whether results are cached, though the read-only nature of an 'index' is strongly implied by the noun. For a zero-argument index tool the risk is low, so this is adequate rather than rich.

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?

One compact sentence with no filler, and the most important element (the dataset version/date) is front-loaded. The telegraphic list style ('the tools and the act vocabulary') is slightly clipped but not ambiguous enough to cost more.

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?

An output schema exists, so return values need no prose explanation, and a zero-param tool has few failure modes to document. What is missing is the routing information an agent actually needs: when to call this versus rules_changelog or the domain-specific siblings like fee_schedule and rep_required.

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 tool takes no parameters, so the baseline of 4 would normally apply; however, the description adds no framing about the absence of filters (e.g. that offices/tools cannot be narrowed here). Schema coverage is 100% and empty, so the schema contributes nothing an agent could not already see.

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 enumerates exactly what the tool surfaces: dataset version and date, offices with row counts, tools, and act vocabulary. That is a specific content contract an agent can match to a need. It loses a point for having no verb ('Returns...') and for not distinguishing itself from the sibling rules_changelog, which sounds related.

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 explicit when-to-use guidance, no statement of prerequisites, and no mention of alternatives such as rules_changelog. An agent must infer from the content list that this is a discovery/orientation call to make before drilling into rules data.

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?

With no annotations, the description carries the full load and does well: it discloses ordering (newest first), the result cap (up to 20), the fields returned per record (permalink pattern, server_time, bundle_hash, proof_status), and that user_content is verbatim submitter text. It does not address pagination beyond 20 results or error/empty-result behavior.

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?

Purpose is front-loaded and the three sentences each add information (matching/ordering, return payload, scope disclaimer). The first sentence is dense with parentheticals, but no sentence is filler.

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 one-parameter search tool with an output schema, the description covers syntax, scope, ordering, limits, and payload contents adequately. The only real gap is what happens past the 20-result cap.

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 0% and the single parameter has no schema description, so the description must compensate and largely does: q is documented as matching title or abstract using web search syntax with concrete examples (words, "a phrase", -word, or). It stops short of noting case sensitivity or whether q is required.

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 names a specific verb and resource ('Public records of the PatentRef registry (dated technical disclosures)') and states the match field (title or abstract), ordering, and cap. It also distinguishes the resource from a related one by noting a record 'shows what was published and when, not a patent or an opinion,' separating it from search_patents.

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 context is made clear through the disambiguation from patents and opinions, which tells the agent when this resource is the right one. However, it never names search_patents or similar_patents as alternatives, nor does it state exclusions such as needing an id-based lookup instead.

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?

No annotations are supplied, so the description carries the full behavioral burden. It does disclose real mechanics beyond the schema: a size ceiling of 1000, keyset pagination via 'after' taken from the prior page's last sort values, and the 'lapse' opt-in for the expiry field group. It omits permission/auth requirements, whether the corpus is only granted patents (no pending applications), and any result-count 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?

Purpose is front-loaded and every clause adds information, with concrete inline examples rather than prose. The telegraphic style ('f the fields to return', 's the sort') compresses well but reads as fragmented, which slightly slows parsing of an already dense grammar.

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 complex JSON-DSL query tool with 0% schema coverage, the description supplies worked examples for the query and sort, the field-projection option, the page-size ceiling, and the cursor chaining rule. An output schema exists, so return values need not be described, and the remaining detail is delegated to a named, versioned grammar ('PatentSearch v1').

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 0% and the params are nested free-form objects, yet the description explains each of the five: q as single-key JSON with worked examples, f as a field projection with the 'lapse' group enumerated, s as sort with an example, size with its cap, and after as the cursor. The gaps are the default size of 25 and any enumeration of the permitted grammar operators beyond _and/_gte.

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 ('Search granted US patents') and pins the scope to granted US patents, which implicitly separates it from search_disclosures and similar_patents. It does not name any sibling explicitly, so an agent must infer the boundary from the scope wording alone.

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 description tells you how to query, not when this tool is the right choice over search_disclosures, similar_patents, or check_patent_status. There are no exclusions, prerequisites, or routing rules, so selection among the 14 siblings 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.

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

With no annotations, the description carries the full burden and does substantial work: it discloses the ranking algorithm (FTS5 bm25), the fields scored, the valid n range, and the returned metadata fields. The closing caveat that this is 'a record of what the corpus contained, not a search opinion' sets useful expectations about result nature and recall limits. What is missing is any note on latency, corpus scope beyond 'US', or how ties or short inputs are handled.

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?

Two sentences, front-loaded with the operation and count, then the method, then the caveat. Dense but every clause carries information. The unexplained jargon 'FTS5 bm25' costs a little clarity for an agent unfamiliar with the ranking backend.

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?

An output schema exists, so return values need not be spelled out, and the tool is simple at two parameters. Still, for a tool whose only input semantics hinge on how text is formatted, the definition leaves that ambiguous, and it never clarifies how this relates to search_patents in the same family.

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 0%, so the description must supply parameter meaning, and it only partly does. It usefully constrains n to 1-20 (the schema shows only a default of 20) and implies the text parameter should be a title plus abstract, but it never says whether that is a concatenated string, whether a delimiter is expected, or what happens if only a title is supplied.

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 names a concrete operation (return the n nearest US patents to a supplied title-plus-abstract), the retrieval method (FTS5 bm25 over title and abstract), and the return payload (data_version, as_of). It does not explicitly distinguish itself from the sibling search_patents, so an agent must infer that this one is similarity-ranked rather than a keyword search, but the core purpose is unambiguous.

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 phrase 'nearest to a title plus abstract' and by the caveat that results are a corpus record rather than a search opinion, which hints at when to prefer it. However, there is no explicit when-to-use guidance, no statement of when not to use it, and no named alternative such as search_patents despite that sibling being the obvious point of confusion.

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