USPTO Patent MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.1.1
Disambiguation4/5
Tools are mostly distinct, but there are overlapping search capabilities (e.g., patentsview_search_patents vs ppubs_search_patents) and multiple patent retrieval methods (ppubs_get_patent_by_number, ppubs_get_full_document). Deprecation notes help, but the redundancy could still confuse an agent.
Naming Consistency3/5
Naming mixes source prefixes (odp_, ptab_, ppubs_, tsdr_, tm_, patentsview_) with generic get_/search_ prefixes. While each group is internally consistent, the overall pattern is inconsistent (e.g., get_cpc_info vs ppubs_search_patents vs search_litigation).
Tool Count2/5
61 tools is excessive for a single server, especially since many are deprecated (~15 patentsview_* tools) or temporarily unavailable (several office action and litigation tools). This inflates the count and adds maintenance burden without proportional functionality.
Completeness4/5
The server covers a broad domain: patent search and retrieval, PTAB, trademarks, assignments, citations, and litigation. Most core workflows are supported, though some deprecated tools have replacements. Minor gaps exist (e.g., no direct trademark document download per type), but overall coverage is strong.
Average 4.3/5 across 60 of 61 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 7 of 7 community issues answered or closed in the last 6 months
- 16 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description simply says 'get details', implying a read-only operation but not explicitly stating it. No mention of side effects, error handling, rate limits, or other behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of one short sentence. It avoids unnecessary details and is well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about what details will be returned, whether it returns full data or summaries, or how it relates to other available tools. It is not complete enough for a user to fully understand the tool's output and place in the broader API ecosystem.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'product_id' is described as 'Dataset product identifier', which adds clarity beyond the schema's title 'Product Id' by specifying it refers to a dataset product. However, it doesn't elaborate on format or expected values, so it only partially compensates for sparse schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves details of a bulk dataset product, which is specific about the resource type. However, it could be more explicit about what 'details' entails, but overall it is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like searching for datasets or getting other product info. The description lacks any contextual direction for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It reveals that the API is unavailable on the portal, which is a notable limitation, but it fails to mention whether the operation is read-only (though implied by 'Get'), error handling, rate limits, or any prerequisites. The note is helpful but leaves significant gaps in behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear purpose statement and an important caveat. The Args section duplicates schema information but does not add clutter. Overall, it is short, front-loaded, and free of filler, though the duplicate param line is slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, return values are covered. The main gaps are the lack of specification for the expected case_id format and incomplete guidance on when to use this tool given the API unavailability. It points to search_litigation but does not explain the consequences of using get_litigation_case directly or whether it is deprecated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only repeats the schema's 'case_id: Case identifier' with no additional formatting, examples, or constraints. It adds no semantic value beyond the schema, failing to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get details of a specific litigation case.' It uses a specific verb and resource, but does not differentiate among sibling litigation tools like get_patent_litigation or get_party_litigation. The API unavailability note adds context but does not clarify the scope of 'case'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The IMPORTANT note provides partial usage guidance by stating the API is not available on the Open Data Portal and directing users to search_litigation for details and workarounds. However, it does not explicitly state when to use this tool versus alternatives, nor does it describe conditions under which it should not be called.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only adds 'Live via USPTO ODP v3.0', which is minor. It does not disclose return format, rate limits, or any side effects, and the read-only nature is only implicit in the verb 'Get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded, and every element serves a purpose. The 'Args' block is clear, and the 'Live via USPTO ODP v3.0' line adds useful context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one parameter and an output schema, the description is mostly sufficient. However, it does not explain what 'details' include or how it relates to similar sibling tools, leaving some ambiguity for an agent deciding between alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly documents the sole parameter with 'Decision identifier (trial number, e.g. IPR2022-00001)', which compensates for the schema's 0% description coverage. It provides both a semantic label and a concrete example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get details of a specific PTAB decision', which is a specific verb+resource phrase. It clearly distinguishes from search_decisions (plural search) and ptab_get_proceeding (a different entity), though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit when-to-use guidance or comparison to sibling tools. It implies usage through the decision_id argument, but does not state when to prefer this over ptab_search_decisions or ptab_get_proceeding.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It states the tool retrieves a list, implying a read operation, but does not explicitly mention that it is non-destructive, lacks side effects, or requires authentication. It also does not describe pagination, limitations, or error handling. This is minimal but not incorrect, so it scores low due to lack of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences—yet conveys the purpose and the critical parameter format. It is front-loaded with the main action and then explains the argument. Every word earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single required parameter, output schema present), the description is minimally adequate. However, it omits any mention of the return format, ordering, pagination, or potential edge cases (e.g., invalid app_num). While the output schema may cover return structure, the description lacks any usage context or caveats, making it only partially complete for a real-world agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides a specific formatting rule for app_num ('without slashes') and an example ('14412875'), which significantly clarifies the schema's bare string type. Since schema coverage is 0%, this additional detail is valuable and compensates well for the one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get list of documents') and identifies the resource ('application file wrapper'), which distinguishes it from sibling tools like odp_get_application or odp_get_dataset. However, it does not explicitly contrast with other document-related tools (e.g., ptab_get_documents) or state why this tool should be preferred, but the specificity of 'application file wrapper' gives reasonable differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, filters, or exclusions. The context signals show many sibling tools, but the description provides no decision-making information, leaving the agent to infer usage solely from the name and resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only mentions 'Live via USPTO ODP v3.0', implying a live data source, but does not describe output format, pagination behavior, rate limits, or any side effects. This is inadequate for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: one purpose sentence followed by a parameter list. There is no unnecessary prose, and the most important information (purpose) is front-loaded. This is an efficient use of space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 optional parameters and an output schema (which is not provided but noted). The description covers the purpose and parameters but lacks context on what constitutes an 'ex parte appeal decision' or how this search differs from sibling searches. Given the output schema exists, the description is minimally adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description's parameter list is essential. Each parameter has a short semantic comment (e.g., 'Full-text search query', 'Filter by application number'), which adds meaning beyond the schema's plain types and defaults, effectively compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search ex parte appeal decisions' which is a clear verb+resource combination. It clearly identifies the tool's purpose but does not explicitly differentiate from sibling tools like ptab_search_decisions, though the specificity of 'ex parte appeal' provides some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'Live via USPTO ODP v3.0' which gives a data source context but no exclusions or alternative tool suggestions, leaving the agent without clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are given, so the description carries the burden. 'Live via USPTO ODP v3.0' hints at a network call but does not confirm read-only behavior, side effects, authentication needs, or error handling. More could be said about rate limits or idempotency, so the transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with purpose, followed by a clear Args list. There is minor redundancy with the schema (defaults and types), but it remains efficient and scannable without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so not explaining return values is acceptable. The description covers key parameters and the live API nature, but omits pagination limits, maximum limit values, ordering guarantees, or whether document_type accepts exact phrases. For a 4-parameter tool, it is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema properties have no descriptions, so the Args block is essential. It adds a concrete example for proceeding_number, illustrative values for document_type, and restates defaults for offset and limit. However, it does not define valid formats, case sensitivity, or possible values beyond a few examples, preventing a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get documents filed in a PTAB proceeding' uses a specific verb ('get') and resource ('documents filed in a PTAB proceeding'), which clearly identifies the tool's function. It is distinguishable from siblings like ptab_get_proceeding and ptab_get_decision, though it does not explicitly contrast itself with them, keeping it just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, alternatives, or exclusions are provided. The phrase 'Live via USPTO ODP v3.0' implies a live API call but does not explain when to prefer this tool over ptab_get_decision or ptab_search_*. Usage is only implied by the tool's name and 'Get documents'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Live via USPTO ODP v3.0' which indicates a live data source, but it does not mention any rate limits, required authorizations, or the nature of the response. The behavior beyond a simple GET is opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with only two sentences and an args block. Every sentence adds necessary information without fluff, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (single parameter) and the presence of an output schema, the description does not need to explain return values. However, it lacks guidance on what an appeal number looks like or how to retrieve one, and it misses usage distinctions from sibling tools. It is minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. It includes 'appeal_number: Appeal number', which merely restates the schema's property title. No format, example, or additional context is provided, adding no real semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get details of a specific ex parte appeal decision.' The verb 'Get' and resource 'details of a specific ex parte appeal decision' are specific and distinguish it from sibling tools like ptab_get_decision or ptab_get_proceeding. The reference to 'appeal' makes the tool's scope clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The description mentions 'Live via USPTO ODP v3.0' which offers some context but does not tell the agent when to choose this tool over other ptab_ tools. Usage is implied by the tool name and description but not clearly articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It conveys a straightforward read-style lookup and adds one useful behavioral constraint ('without slashes'), but it does not mention auth, error behavior, coverage limitations, or response characteristics. For a simple getter, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing a clear action, parameter name, formatting rule, and example. Every element earns its place and there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity, one-parameter getter with an output schema, the description provides the essential invocation detail: the exact format of the application number. It could add usage caveats or data source scope, but it is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides the parameter name and string type, while the description adds meaningful semantics: the application number must be provided without slashes, with a concrete example ('14412875'). This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Get attorney/agent of record for an application.' It specifies the resource and the input type, making the tool's purpose unambiguous. However, it does not explicitly distinguish this from similar sibling tools such as patentsview_get_attorney or odp_get_application.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by indicating the tool retrieves attorney/agent of record for an application and provides an example application number. It does not give explicit guidance on when to choose this tool over siblings or state exclusions, so usage guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It prominently warns that the tool is 'Temporarily unavailable — legacy endpoints decommissioned, ODP migration pending,' which is crucial for an agent to know. It also describes the type of data returned. It does not discuss permissions or side effects, but for a simple query tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by a usage guideline and an important availability notice. The 'Args' section is redundant because it simply restates the schema, but it is brief and does not significantly bloat the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description covers purpose, usage, and the critical unavailability warning. The presence of an output schema reduces the need to explain return values. It could be more comprehensive about what 'citation age metrics' means, but the description is complete enough for an agent to select and attempt to invoke the tool correctly (or avoid it due to unavailability).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter `patent_number`. The description only repeats the parameter name and type ('patent_number: Patent number'), adding no additional meaning, format expectations, or examples. Since coverage is low, the description should compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Get citation metrics for a patent.' It further details the scope (forward/backward counts and citation age metrics), which distinguishes it from sibling tools that focus on citation lookup or enrichment rather than quantitative metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides a 'USE THIS TOOL WHEN' section explaining the intended use case: 'quantitative citation analysis including forward/backward counts and citation age metrics.' It does not mention exclusions or alternative tools, so it falls short of a 5, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose a key behavioral constraint: the underlying API is unavailable on the Open Data Portal. However, it omits information about error behavior, authentication, or what happens when the tool is called.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loads the important availability warning. The Args block is largely redundant with the schema, but it is not wordy and the overall structure is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with an output schema, the description gives essential context by flagging the unavailable API and pointing to search_litigation. It leaves some ambiguity about what actually happens when this tool is called, but the warning is enough to guide an agent to the preferred alternative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. Instead, 'patent_number: Patent number' merely restates the schema's title and adds no format, example, validation, or canonical identifier guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Get all litigation involving a specific patent' with a specific verb and resource, and clearly scopes the litigation to a patent. This distinguishes it from siblings like get_litigation_case and get_party_litigation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns that the USPTO Patent Litigation API is not available and directs users to search_litigation for details and workarounds. This provides a clear alternative/avoidance signal, though it stops short of fully explaining when this tool should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries some burden and does add context: it says the tool is 'Live via USPTO ODP v3.0' and lists return contents. However, it does not disclose read-only behavior explicitly, error handling for invalid or missing proceedings, rate limits, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with its purpose, followed by a brief Args/Returns structure. The Args section partially duplicates the schema, but it earns its place by adding the example. No filler or redundant explanation is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter getter with an output schema, the description is mostly adequate and gives the essential identifier and return scope. However, it omits error behavior, explicit read-only confirmation, and any relationship guidance to sibling PTAB tools, leaving moderate context gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, proceeding_number, has zero schema description coverage, but the description adds a concrete example ('IPR2023-00001') and explains it is a proceeding number. This meaningfully compensates for the schema's lack of detail, though it does not enumerate all possible proceeding formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get details of a specific PTAB proceeding', clearly identifying the verb and resource. It distinguishes this from sibling search and document/decision/appeal tools by targeting the proceeding itself and listing key returned content: parties, patent, status, and dates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'specific PTAB proceeding' implies use when a known proceeding number is available, contrasting with search tools. However, it does not explicitly state when to use this over related tools like ptab_get_decision or ptab_get_documents, and no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of explaining behavior. It adds useful source context (74,000+ district court records, OCE bulk dataset, the API not being available on ODP), but it does not describe return behavior, pagination effects beyond 'limit' and 'offset,' or other operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient and front-loaded with a clear purpose, followed by a concise Args list. The 'IMPORTANT' paragraph about the API not being available is somewhat tangential, but it is brief and provides useful source context without bloating the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter search tool with no schema descriptions and no annotations, the description is largely complete: it covers every parameter's meaning, the data scope, and source limitations. It could be slightly improved by mentioning filter combination behavior and expected result semantics, but an output schema exists to cover return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully by documenting every parameter: query as full-text, patent_number, plaintiff, defendant, court, filing_date_from/to with YYYY-MM-DD format, offset starting position, and limit max results. This is exactly the semantics needed beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search patent litigation cases (74,000+ district court records).' The word 'search' and the focus on litigation cases clearly distinguish this from sibling get_* tools such as get_litigation_case, get_patent_litigation, and get_party_litigation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit when-to-use or when-not-to-use guidance relative to sibling tools. It identifies the data source and parameters, but there is no direction such as 'use this for broad searches, use get_litigation_case for a known case ID.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions 'Live via USPTO ODP v3.0' but does not state that the operation is read-only, describe pagination behavior, or note any rate limits or side effects. The search nature implies safety, but the description carries the burden and under-delivers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a well-structured docstring with a one-sentence summary followed by a compact Args list. Every line provides essential information, with no fluff or redundancy. It is front-loaded with the core purpose and effectively organizes parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return values need not be described. The description covers all 8 parameters and provides useful context such as defaults and live data source. However, it omits details about how filters combine (AND/OR), whether date bounds are inclusive, or if there is a maximum limit, which would enhance completeness for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides a clear one-line semantic for each of the 8 parameters, including the full-text search behavior of 'query', valid values for 'decision_type', and date formats. Since the input schema only lists titles and types with zero description coverage, the description fully compensates and adds significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Search PTAB trial decisions,' which is a specific verb+resource statement that clearly identifies the tool's function. It distinguishes itself from sibling tools like ptab_search_proceedings and ptab_search_appeals by explicitly focusing on decisions, and the name 'ptab_search_decisions' reinforces this.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for searching trial decisions but does not explicitly state when to use this tool versus related tools like ptab_get_decision or ptab_search_proceedings. There is no mention of exclusions or when to prefer alternatives, so the guidance is clear but implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. The verb 'Get' implies a read operation, and the description previews return content (examiner, art unit, status) plus the parameter format. Still, it omits possible error behavior, authentication requirements, or rate limits, making it only minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose, a clear 'USE THIS TOOL WHEN' condition, and an Args section. Every sentence contributes value, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (single parameter, simple read operation) and the existence of an output schema, the description is mostly complete. It covers purpose, usage trigger, and the one parameter, but could improve by noting how this differs from odp_get_application. Overall, it is sufficient for an agent to confidently select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for app_num, but the description compensates fully by specifying 'Application number without slashes' and providing a concrete example ('14412875'). This adds meaningful formatting context that the structured schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource as 'detailed metadata for a patent application,' with concrete examples like examiner info, art unit, and status. It clearly states the tool's function, though it does not explicitly distinguish itself from the sibling tool odp_get_application, which likely provides more basic application data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It includes a 'USE THIS TOOL WHEN' section that gives an explicit condition: when comprehensive application metadata is needed, including specific fields. However, it does not provide any 'when not to use' guidance or mention alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden, but it reveals little beyond the read operation implied by 'Get.' The note about effective filing date is more about purpose than behavior. It does not disclose potential empty results, ordering, or any side effects, but 'Get' does imply a safe read operation. Neutral, adequate, but not rich in behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a one-line purpose statement, a clearly labeled usage directive, and a compact args block. Slight redundancy exists between 'Get foreign priority claims' and the rewording in 'USE THIS TOOL WHEN,' but overall every section earns its place with minimal fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, single-parameter getter with a defined output schema, the description is mostly complete. It provides the trigger context and the required argument format. It could be more complete with a note about what 'foreign priority claims' represent or typical response scenarios, but the presence of an output schema mitigates the need to explain return shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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. The 'Args' section adds format guidance ('without slashes') and a concrete example ('14412875') beyond the schema's bare string type. This provides solid, non-redundant value for the single parameter, though it doesn't cover edge cases like leading zeros or required length.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('foreign priority claims for an application'), which clearly differentiates it from sibling tools like odp_get_application, odp_get_assignment, and odp_get_transactions. Even without naming siblings, the subject matter is specific enough to identify the tool's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE THIS TOOL WHEN' section gives an explicit, actionable trigger: 'find priority claims to foreign applications that may affect the effective filing date.' It lacks explicit alternatives or when-not-to-use cases, but provides clear context for when the tool is relevant, meriting a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects, auth, rate limits, etc. It states the tool 'search' and returns a 'Normalized response', but doesn't explicitly confirm it's read-only, safe, or mention any rate limits or authentication requirements. The absence of such details leaves gaps in behavioral transparency, so a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: a one-line summary, 'USE THIS TOOL WHEN' block, Args list, and Returns note. It is detailed but not overly verbose; every sentence adds value. It's slightly longer than the minimal examples but appropriately sized for the complexity of the query syntax.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (indicated by 'Has output schema: true'), the description need not explain return values in detail. The description covers purpose, usage context, query syntax, and defaults, which is adequate for a moderate-complexity search tool. It could mention output structure briefly, but the schema fills that gap, so completeness is strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the schema, particularly for the query parameter: it explains BRS syntax, field qualifiers, quoting, and that multi-word terms are AND-ed. For offset and limit, it mentions pagination implicitly and states max 500 for limit. Sort is only given a default, no options are listed. Overall, it significantly enriches parameter understanding, but not exhaustively for all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches published US patent applications in Patent Public Search. The subsequent explanation that applications publish 18 months after filing and are pre-grant distinguishes it from sibling tools like ppubs_search_patents, which presumably covers granted patents. This is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'USE THIS TOOL WHEN' section that explicitly states the condition: searching pre-grant published applications. It also references ppubs_search_patents for query syntax, indirectly pointing to an alternative. However, it doesn't explicitly say when *not* to use this tool or mention other alternatives for different scenarios, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavior such as whether the tool is read-only, error handling for invalid application numbers, or any side effects. It only states it retrieves data, lacking transparency about operational nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear purpose statement and a separate usage condition. It avoids unnecessary detail while conveying the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter get tool, the description covers what it does and when to use it. It does not elaborate on return values, but given an output schema exists, that is not required. It lacks mention of potential edge cases or fallback behavior, so it is slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the 'app_num' parameter as an application number without slashes and gives an example, which provides useful formatting guidance. However, it does not cover validation rules or possible formats beyond the example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets patent term adjustment data and specifies the use case for calculating expiration dates with USPTO delays. It is distinct from sibling tools like odp_get_application.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly provides a 'USE THIS TOOL WHEN' condition, guiding the agent to use it when calculating patent expiration dates with delays, which is actionable and differentiates from other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It indicates the tool returns a 'complete timeline' of events, implying a list output, and explains the input format (app_num without slashes). However, it does not describe the output structure, potential errors, pagination, or any side effects. This is adequate but not rich, aligning with a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, a 'USE THIS TOOL WHEN' guideline, and an explicit parameter explanation. There is no repetition of schema content, and every sentence adds value. It is front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple retrieval tool with one parameter and an output schema present. The description adequately covers purpose, usage, and parameter semantics. It does not delve into return values or edge cases, but given the tool's simplicity and the availability of an output schema, the description is sufficiently complete for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, so the description must clarify the parameter. It does so effectively by stating 'app_num: Application number without slashes (e.g., "14412875")', providing format and an example. This adds meaningful value beyond the schema's mere 'App Num' field, though it could elaborate on what constitutes a valid application number.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'prosecution transaction history for an application', specifying the resource and scope. It distinguishes from siblings like odp_get_application (which gets application details) and odp_get_documents (which gets documents) by focusing on the complete prosecution timeline including office actions, responses, and fee payments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'USE THIS TOOL WHEN: You need the complete timeline of prosecution events including office actions, responses, and fee payments.' It provides clear context but does not mention any alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It implies a read-only search and indicates pagination through offset/limit, but it doesn't describe response contents, authorization needs, rate limits, or the exact scope of dataset results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: clear purpose first, then an explicit usage condition, then the Args block. No filler or redundant restatement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple search with only three optional parameters, and an output schema is present so return values need not be spelled out in the description. The description adequately explains the tool's purpose, use cases, and parameter semantics; a little more context about dataset scope or exclusions could fill the remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema itself has no descriptions, but the Args section compensates by defining each param: query is for dataset names/descriptions, offset is the starting position, and limit is the max result count. This is sufficient for an agent to understand and invoke parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clarifies the tool as searching USPTO bulk data products/datasets, giving a specific verb and target resource. This clearly differentiates it from the many sibling tools that search patents, applications, trademarks, or other records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The explicit 'USE THIS TOOL WHEN' line tells the agent it is for finding USPTO bulk download datasets for large-scale analysis. It doesn't name alternatives or when not to use it, but the resource is distinct from the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It candidly reveals a critical limitation (the service is discontinued) and suggests a recommended path forward. It could add more detail on what happens on invocation (e.g., error behavior), but it is highly transparent about the tool's operational status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized, starting with a clear one-sentence purpose, followed by a brief, critical API shutdown notice, and then the args. The warning is slightly verbose but justified given its importance; no unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter schema and the presence of an output schema (which lessens the need to document return values), the description provides solid context: operational status, usage caveat, parameter meaning, and alternative guidance. It adequately covers the key aspects an agent would need to know.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description documents the sole 'ipc_code' parameter with a concrete example ('G06F' for data processing). This compensates well for the bare schema and clarifies the expected input format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Look up IPC (International Patent Classification) code details' uses a specific verb ('look up') and clearly identifies the resource (IPC code). It's clear, though it doesn't explicitly contrast itself with siblings like patentsview_lookup_cpc, relying on the domain distinction to differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns that the underlying API was shut down and provides a named alternative tool ('Use odp_search_datasets') for locating PatentsView bulk data with IPC data. This is an explicit when-not-to-use and alternative recommendation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the PDF is base64-encoded, that the return value is a dictionary, and that Claude Desktop may not display PDFs well. However, it does not mention error behavior for invalid/missing patent numbers, potential file size limits, or any other operational caveats, leaving a noticeable transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose, a clear usage trigger, a brief note on display limitations, and concise args/returns sections. Every line adds useful information without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter download tool with an output schema, the description covers the essential invocation details, return format, and a practical display caveat. It lacks explicit differentiation from similar ppubs tools like ppubs_get_full_document, but the tool's scope is narrow enough that this is not a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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. It does so by specifying that patent_number should be provided 'without commas' and giving a concrete example ('7123456'), adding practical formatting meaning beyond the bare schema property. It could further clarify whether this is a US-only patent number, but the guidance is helpful for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Download a patent as PDF (base64 encoded).' It clearly identifies the tool's function and the output format, and 'official PDF document' distinguishes it from metadata/search sibling tools like ppubs_get_patent_by_number or patentsview_get_patent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit 'USE THIS TOOL WHEN: You need the official PDF document of a patent' statement, giving clear context for invocation. It does not name alternative tools or state when not to use it, but the when-to-use guidance is direct and sufficient for a simple download tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return format (dictionary with base64-encoded image data) and the input requirement, but does not mention error behavior, authentication, rate limits, or what happens if no image exists. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured with clear sections for purpose, usage trigger, arguments, and returns. Every sentence adds value, and there is no redundant or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter retrieval tool, the description covers purpose, when to use, argument format, and return type. It does not mention edge cases like missing images or alternative tools, but the overall context is sufficient for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines serial_number as a string with no description. The tool description adds meaningful semantics by specifying '8-digit application serial number' and providing an example ('78787878'), which goes beyond the schema and helps the agent format the parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the mark image (drawing) for a trademark as base64, using a specific verb and resource. It distinguishes itself from sibling tools like tsdr_get_trademark_status and tsdr_list_trademark_documents by focusing on image retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit 'USE THIS TOOL WHEN' section: 'You need the visual representation of a design mark or stylized word mark.' This provides clear context for when to use it, though it does not mention when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavioral traits. It clearly states the tool is temporarily unavailable due to API decommissioning, which is critical safety information. It also mentions defaults for include_forward/backward. However, it doesn't describe the structure of the returned data or any error conditions, so it is not 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, uses a 'USE THIS TOOL WHEN' header, and every sentence serves a purpose. It is concise yet informative, without fluff. The important unavailability warning is front-loaded, making it highly effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being currently unavailable, the description covers the tool's purpose, parameters, and usage guidance. An output schema exists, so return values don't need to be detailed, but the description could mention more about the enriched metrics or response format. Overall, it is complete enough for an agent to understand what it would do if operational.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description provides definitions for all three parameters (patent_number, include_forward, include_backward) and their defaults, adding value beyond the schema. It doesn't explain the patent number format or details about the metrics, but the core semantics are covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves enriched citation data for a patent, including forward and backward citations. This is specific and distinguishes it from other patent retrieval tools like patentsview_get_patent, although it could be more explicit about what 'enriched' means beyond basic citations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit 'USE THIS TOOL WHEN' section, and importantly, it warns that the tool is currently unavailable and recommends an alternative (patentsview_get_patent) for basic citation data. This is excellent usage guidance for an agent deciding when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description transparently discloses the API unavailability, which is a significant behavioral caveat, but it does not mention expected outputs, error handling, or potential failure modes beyond the note.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear note and bullet-like arguments. It avoids unnecessary fluff and gets to the point efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It provides essential context including the API unavailability and alternative tool, but does not describe the return format or how results are presented, which could be useful for a get operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (party_name, role, limit) are described with meaningful context: party_name is defined as company/individual name, role is explained with allowed values and default behavior, and limit is clarified as max results. This fully complements the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves litigation for a company or individual, but the caveat that the API is not available on the Open Data Portal and directs to search_litigation slightly muddles the primary purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly points users to search_litigation for details and workarounds, providing clear guidance on an alternative tool, though it does not elaborate on other scenarios or when this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the input format (without slashes/commas) and the return content, but it does not explicitly state that the operation is read-only or describe error behavior, rate limits, or authentication requirements. The verb 'Get' implies a safe read, but the lack of explicit behavioral disclosure is a moderate gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with clear sections for purpose, when to use, arguments, and returns. Every sentence provides useful information with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter retrieval tool, the description covers the source, the specific data content, and the parameter format. It does not mention error cases or what happens if the application number is invalid, but given the presence of an output schema and the simplicity of the tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides minimal meaning (just a string field with zero coverage). The description compensates fully by specifying the exact format: 'without slashes or commas' and gives a concrete example ("14412875"). This leaves no ambiguity about how to construct the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get patent application data from USPTO Open Data Portal' with a specific verb and resource. It distinguishes from siblings by specifying 'prosecution/file wrapper data including status, dates, and basic metadata', which differentiates it from related tools like metadata, continuity, or assignment retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit 'USE THIS TOOL WHEN' clause: 'You need prosecution/file wrapper data for an application including status, dates, and basic metadata.' This gives clear usage context. However, it does not mention when not to use it or name specific alternatives, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It conveys a read operation ('Get') and mentions 'current and historical owners,' but provides no further transparency into rate limits, data freshness, or edge cases. It is adequate but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and clearly structured: a one-line summary, a 'USE THIS TOOL WHEN' section, and an Args block. Every sentence adds value, and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool with an output schema, the description covers all necessary aspects: what it does, when to use it, and how to format the argument. There is no missing context that would hinder an agent from using it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The 'Args:' block goes beyond the schema by specifying 'Application number without slashes' and providing an example ('14412875'). This format-level detail compensates for the 0% schema description coverage, though it could further clarify expected formats (e.g., digits only).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get patent assignment/ownership records' with a specific verb and resource, and the qualifier 'patent' differentiates it from trademark assignment tools like tm_search_assignments among siblings. This is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE THIS TOOL WHEN' section explicitly provides usage context: 'You need to know current and historical owners of a patent or application.' It lacks explicit alternatives or when-not-to-use statements, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden of behavioral disclosure. It discloses a major trait: the underlying API is shut down and this tool is effectively deprecated, plus it includes limit bounds. It does not describe error/response behavior, but an output schema exists and the shutdown notice provides substantial context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the purpose, followed by a clearly marked IMPORTANT notice and succinct Args documentation. Every sentence adds necessary information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter search tool with an output schema present, the description covers purpose, deprecation status, workaround, and parameter semantics. It is sufficient for selecting and invoking the tool safely, though it omits potential details about result ordering or pagination behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are empty, so the Args block compensates: 'name' is explained as 'Inventor name (last name, or "First Last")' and 'limit' as 'Max results (default: 100, max: 1000)'. Both parameters gain meaning, though format details like wildcards and case sensitivity are not covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair: 'Search for inventors with disambiguation.' This clearly states what the tool does and hints at its distinct behavior. However, it does not explicitly contrast with sibling tools like patentsview_get_inventor or explain what 'disambiguation' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: the PatentsView API was shut down on March 20, 2026, and directs the agent to use ppubs_search_patents with an IN/"last name" query as a workaround. This is a clear when-not-to-use instruction with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It notes 'Live via USPTO ODP v3.0' and that results are 'Normalized response,' but doesn't cover pagination behavior, rate limits, or what 'normalized' means. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, front-loaded purpose, then usage, args, returns. The trial type explanations are a bit long but add real value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-param search tool with no annotationsede e 0% schema coverage, the description covers all parameters, gives usage context, and notes the live data source. Output is abstractly described but output schema exists to fill gaps. Minor missing: no pagination or rate limit warnings, but offset/limit are self-explanatory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage意識, but the description compensates by listing all 9 arguments with brief meanings (e.g., 'Filing date range start'). It adds clarity for trial type values (IPR, PGR, CBM, DER) and status examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search PTAB trial proceedings (IPR, PGR, CBM, derivation)'. It uses a specific verb ('Search') with a clear resource ('PTAB trial proceedings') and enumerates the covered trial types, distinguishing it from sibling tools like 'ptab_get_proceeding' (which retrieves a specific proceeding) and 'ptab_search_appeals'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance: 'USE THIS TOOL WHEN: You need to find patent validity challenges at the Patent and Appeal Board.' It also explains each trial type (IPR, PGR, CBM, derivation) so the agent knows what each means, and the phrase 'Live via USPTO ODP v3.0' gives context. Distinguishes from siblings via search-vs-get and trial type coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the API key requirement and the 'Normalized response' format, which is useful context. However, it does not mention error behaviors, rate limits, or confirm read-only status explicitly. For a read operation, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (USE THIS TOOL WHEN, Args, Returns) and is concise without unnecessary words. Every section adds value for an agent deciding to use the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two parameters) and the presence of an output schema that presumably defines the response structure, the description covers essential selection criteria, input constraints, and usage context. The API key requirement and authoritative source are noted, making it complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), so the description compensates effectively by providing format examples for both parameters and the crucial 'exactly one required' constraint. This adds meaningful semantic information beyond the bare schema, though it doesn't explain how to obtain the numbers or handle edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves current status from TSDR with a specific verb ('Get') and detailed resource ('status of a trademark application or registration'). The description lists the information fields returned (mark text, owner, classes, dates, prosecution stage) and is distinguishable from sibling tools like tsdr_list_trademark_documents by focusing on status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit 'USE THIS TOOL WHEN' section clarifying the intended use case and required input identifiers (serial or registration number). It also explains the 'exactly one' constraint. However, it does not explicitly state when not to use it or clearly name alternative tools, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses return behavior: 'Classification details including section, title, and description. For section codes (A-H, Y), returns subsection list.' It doesn't explicitly state this is read-only, but that is implied for a lookup. The behavior is transparent enough, though it could mention potential errors 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise: a one-line summary, a 'USE THIS TOOL WHEN' section, and clearly labeled Args/Returns. Every sentence adds value, and it is front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description is complete. It explains both input and output, including the special case for section codes (A-H, Y). No missing guidance for a lookup tool of this nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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. It fully does: 'Args: cpc_code: CPC code to look up (e.g., "G06" for computing, "G06N3/08" for neural networks)' provides meaning, format, and examples. This is highly informative beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Look up CPC (Cooperative Patent Classification) code information.' It also provides examples. However, it does not distinguish itself from the sibling tool 'patentsview_lookup_cpc', which likely serves a similar purpose, so it misses the sibling differentiation needed for a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases with 'USE THIS TOOL WHEN: You need to understand what technology area a CPC code represents, or find related classification codes.' This gives clear context for when to use it, but it lacks any mention of when not to use it or alternatives, so it does not meet the full criteria for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses what the tool returns (configuration status, connection availability, rate limits) and implies a read-only diagnostic behavior. It does not explicitly state side-effect-free behavior, but 'check status' and the return-value focus make the safety profile reasonably clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose, an explicit usage trigger, and a focused bullet list of return content. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter diagnostic tool, the description fully covers what the tool does, when to use it, and what information it returns. The output schema existence is complemented by the enumerated return categories, making the tool self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics burden. The schema coverage is trivially 100%, and the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('check status and availability') and clearly scopes the tool to 'all patent and trademark data sources.' This distinguishes it from sibling data-fetching and search tools, making its purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: when encountering errors or wanting to verify API availability/configuration before research. It does not mention when not to use it or name alternative tools, but the context is clear enough for a diagnostic utility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral load. It discloses that the tool is temporarily unavailable, that legacy endpoints were decommissioned, and that it returns citations from Form PTO-892, PTO-1449, and office action text. This is sufficient for a read-only retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with labeled sections: tool purpose, use-when guidance, an important unavailability warning, Args, and Returns. Every line serves a purpose, and the most actionable availability warning is placed prominently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, range of two parameters, and the presence of an output schema, the description covers what the agent needs to know: what citations are returned, how to filter by mail date, and that an alternative exists because the endpoint is unavailable. No critical selection context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add parameter meaning. It does add that mail_date is an optional filter with YYYY-MM-DD format, but application_number is only restated as 'Application number' without additional specificity. This is minimal but acceptable for a simple two-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Get prior art citations from office actions,' and clarifies that these are references the examiner cited against an application. It also names an alternative tool, get_enriched_citations, which helps distinguish this tool from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit 'USE THIS TOOL WHEN' statement: 'You need to see what references the examiner cited against an application.' It also gives clear guidance to use get_enriched_citations as an alternative because the tool is temporarily unavailable, so the agent knows when and when not to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explicitly states the tool is temporarily unavailable and explains the legacy API decommission, and it describes the return content. This is strong behavioral disclosure, though it could add error-handling details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (intro, usage, important, args, returns). It contains necessary information but is slightly verbose; every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 2-parameter tool and the presence of an output schema, the description adequately covers purpose, usage, parameters, and even provides a replacement tool. The unavailability notice and alternative are especially helpful for agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by giving application_number with an example format and noting mail_date as an optional filter with date format. It also indicates optionality via the word 'Optional.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Get full-text of office actions for an application,' clearly stating the verb, resource, and scope. It further elaborates on examiner rejections, requirements, and objections, distinguishing from sibling tools like get_office_action_rejections or citations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes an explicit 'USE THIS TOOL WHEN' section and an 'IMPORTANT' note instructing to use odp_get_documents as an alternative due to unavailability, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It specifies that the tool returns a 'Status code description and prosecution stage,' which reveals the output behavior. The verb 'Look up' implies a read-only operation, and the examples clarify the input format. It does not mention error handling or side effects, but for a simple lookup this is sufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, when-to-use, args, returns) and no wasted words. The 'USE THIS TOOL WHEN' header is prominent, and the entire description is compact while containing all essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup tool with an output schema, the description covers all necessary context: purpose, usage scenario, parameter explanation, and return value. It is self-contained and gives the agent enough to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'code' as a string, with no description. The tool description compensates fully by explaining 'code: Trademark status code (e.g., "700")' and providing concrete examples. This gives the agent both the meaning and a format hint, adding significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Look up a USPTO trademark status code meaning.' This is a specific verb ('look up') and resource ('USPTO trademark status code'), with concrete examples ('700' = Registered, '686' = Published for opposition) that make the function immediately understandable. It differentiates from siblings by explicitly scoping to trademark status codes, even though sibling tools like 'get_status_code' exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit 'USE THIS TOOL WHEN' section with a concrete scenario: 'Trademark data contains a numeric status code you need to interpret.' This gives clear context for when to invoke the tool. However, it does not mention when not to use it or explicitly name alternative tools, so it stops short of the full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on full responsibility. It explains the output ('Continuity data showing parent/child relationships and priority claims') and adds the note about the application number format ('without slashes'). It doesn't address rate limits or authentication, but for a simple lookup tool, this is sufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sections (purpose, use-case, args, returns) with no redundant wording. Every sentence adds value, and the 'USE THIS TOOL WHEN' is highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup that returns continuity data, the description covers input format, output type, and provides a clear use case. The presence of an output schema further reduces the need to detail return fields. It is complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema itself provides zero description coverage, so the description must compensate. It does so excellently by explaining the format ('without slashes') and giving a concrete example ('14412875'), which is crucial for correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get patent family/continuity data (parent and child applications)' – a specific verb and resource. Among the many patent-related tools, this one is unambiguously about family/continuity, making it distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE THIS TOOL WHEN' section explicitly tells the agent to use it for understanding the patent family tree, including parent applications, continuations, divisionals, and CIPs. However, it does not name alternatives or provide when-not-to-use conditions, only positive when-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It discloses a critical behavioral fact—the API is shut down—which is crucial for agents to know. However, it does not describe what happens if called (likely error) or any other operational details, but the shutdown disclosure is the most important transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the purpose, then the critical deprecation warning in bold, and finally the parameter description. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is deprecated, the description completely covers the essential context: it tells the agent the tool is non-functional and points to the correct alternative. An output schema exists, so return values need no explanation. For its complexity (simple tool with one param), the description is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With one parameter and 0% schema description coverage, the description compensates by providing the parameter name and an example: 'patent_id: Patent ID/number (e.g., 7861317).' This adds meaningful context beyond the bare schema definition, though it could be slightly more detailed about format or validation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get detailed patent information from PatentsView.' It also distinguishes itself from siblings by explicitly naming the alternative tool (ppubs_get_patent_by_number) to use instead, given the API shutdown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-not-to-use guidance: 'IMPORTANT: The PatentsView API (search.patentsview.org) was shut down on March 20, 2026. Use ppubs_get_patent_by_number for patent details.' This names the alternative and clearly states the tool is not to be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses the critical limitation that the underlying API was shut down. It also documents partial-match behavior for name and limit bounds, though it does not explicitly state that calling this tool will fail or what error to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: one sentence stating the tool's purpose, a short IMPORTANT caveat with redirection, and a concise parameter list. Every part adds essential value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter search tool with an output schema, the description covers the purpose, parameters, behavioral limitation, shutdown context, and preferred alternative. No significant information gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining that name supports partial matching and that limit has a default of 100 and maximum of 1000. These details go beyond the schema's bare type declarations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a search for patent attorneys/agents, naming the resource and the action. It also proactively explains the upstream API shutdown, which makes its scope unambiguous despite the tool being effectively deprecated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says the PatentsView API was shut down and instructs the agent to use odp_get_attorney with a specific application number instead. This provides clear when-not-to-use guidance and names the preferred alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the transparency burden. It discloses the tool's unavailable status and the reason for it, which is critical. However, it doesn't explicitly state whether the tool is read-only or any other behavioral caveats, though 'search' implies read-only. Minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a concise purpose line, an IMPORTANT warning, and a formatted Args list. It is slightly verbose due to the Args block, but every line adds necessary value given the lack of schema descriptions. It earns a strong score, though not a 5 due to the extra length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 8 parameters and an output schema, the description provides purpose, availability status, alternatives, and parameter details. It doesn't cover edge cases or output format, but the output schema exists. The unavailability warning is thoroughly handled, making it largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by describing all 8 parameters with meaningful semantics (e.g., 'mail_date_from: Date range start (YYYY-MM-DD)'). It also clarifies defaults for offset and limit, and specifies the date format, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search office actions across applications' — a clear, specific verb ('search') and object ('office actions') with scope ('across applications'). This distinguishes it from siblings like get_office_action_text (which retrieves specific text) and ppubs_search_applications (which searches applications).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Temporarily unavailable — legacy endpoints decommissioned, ODP migration pending. Use odp_get_documents or odp_get_transactions instead.' This provides direct when-not-to-use guidance and names concrete alternatives, fulfilling the usage guideline requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the data source (USPTO Assignment Center public API, no API key required), date coverage (1955 to present), filtering behavior (multiple filters combine AND, at least one required), and return content. This provides solid transparency, though it does not mention potential error conditions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headings (purpose, use case, args, returns). It is concise, with every sentence adding value. The use-case block is upfront, and the parameter list is necessary given the lack of schema descriptions. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no annotations, and an output schema, the description provides all necessary context: when to use, data source, coverage, filter logic, pagination parameters, and a summary of return fields. It is complete enough for an agent to select and invoke correctly without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. The Args section clearly explains all 7 parameters with meanings (e.g., serial_number as 'Trademark application serial number'), gives an example for reel_frame ('9006/0093'), and states defaults for offset and limit. It also explains that filters combine with AND, which is not in the schema. This fully compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'Search recorded trademark assignment (ownership transfer) records.' It clearly distinguishes from sibling tools like tm_search_trademarks (search trademarks) and tm_get_trademark (get single trademark) by focusing on ownership transfer records. The 'USE THIS TOOL WHEN' section further clarifies the exact use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'trace ownership history of a trademark, find the current owner, or find marks transferred to/from a company.' It also provides context like the date range and that at least one filter is required with AND logic. However, it does not explicitly mention alternative tools or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It clearly announces that the tool is temporarily unavailable due to decommissioned legacy endpoints and pending ODP migration. It also states returning rejection data with claim-level details, giving the agent a complete picture of behavior without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (intro, USE THIS TOOL WHEN, IMPORTANT, Args, Returns). It is concise, front-loads key usage guidance, and every sentence serves a purpose. The Args section is somewhat redundant with the schema but adds the optional/required nuance, so it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema (though not shown to the model), the description covers purpose, usage, availability, parameters, and return type. It also includes an alternative tool recommendation, making it complete for an agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), so the description must compensate. It provides basic parameter info: application_number is an application number and mail_date is an optional filter with a specified format (YYYY-MM-DD). However, it does not add deeper semantic context (e.g., validation, constraints, or the relationship between parameters), so it is only minimally sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves structured rejection data from office actions, specifying rejection types (102, 103, 112) and affected claims. It distinguishes itself from sibling tools like get_office_action_text and get_office_action_citations by focusing on structured, claim-level rejection details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool ('USE THIS TOOL WHEN: You need structured data about claim rejections') and immediately warns that it is currently unavailable, directing users to an alternative tool (odp_get_documents). This provides clear usage context and an exclusion condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses critical behavior: typed filters are AND-ed, query accepts Lucene syntax, inventor_name/assignee_name match the *first* inventor/applicant, and application/patent numbers are exact matches. It also notes the return is a normalized response. However, it omits potential rate limits or auth requirements, and does not describe default sort order or whether the API may truncate results beyond limit/offset, leaving minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear intro, usage directive, filter semantics, then an Args list with each parameter on its own line, and a Returns note. Despite having multiple params and examples, it remains readable and every sentence delivers value without fluff. The length is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 optional params, no annotations, no schema param descriptions), the description covers the core: when to use, how filters compose, param meanings, and the return type. It is complete enough for an agent to invoke correctly. Minor omissions like sorting behavior, potential limits on offset/limit values, or whether wildcards are supported prevent a 5, but the overall picture is well-rounded.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate, and it does: every parameter is explicitly listed with a human-readable meaning, including specifics like exact match for application_number/patent_number, 'matches first inventor' nuance, and date format (YYYY-MM-DD). The query parameter even includes concrete examples. This far exceeds schema-only guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb and resource: 'Search patent applications in USPTO Open Data Portal.' It also distinguishes itself from siblings by explicitly stating this is for filtering by criteria 'not available in PPUBS,' aligning with the sibling-tool ppubs_search_applications. This makes the tool's unique scope immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE THIS TOOL WHEN' section explicitly states when to use this tool (filtering by applicant metadata, dates, or other criteria not available in PPUBS), which implicitly advises using PPUBS otherwise. It also clarifies that typed filters are AND-ed and query can be used for OR/complex expressions, guiding the user on how to structure searches effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full transparency burden. It discloses the critical behavioral fact that the underlying API is no longer available, and clearly warns that disambiguated inventor lookups have no direct replacement. It does not explicitly say calls will fail, but the shutdown notice strongly implies non-functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, leading with the core purpose and placing the shutdown warning prominently. The Args section is cleanly separated, and every sentence contributes essential information without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter lookup tool with an output schema, the description provides the necessary operational context: what the tool does, that it is defunct, and what alternative path to pursue. The output schema covers return-value details, so the description does not need to restate them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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. The Args section clarifies that inventor_id is the 'Disambiguated inventor ID from search results,' adding provenance and definition beyond the schema's bare property name. A concrete format or example would improve it, but for a single-parameter tool this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Get detailed inventor information') and its key identifier ('by disambiguated ID'), which distinguishes it from sibling tools like patentsview_get_patent and patentsview_get_assignee. The verb-resource pair is specific and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly discloses that the PatentsView API was shut down and that no direct replacement exists, then names an alternative tool (odp_search_datasets) for bulk data. It also implies the tool is meant to be used after obtaining an inventor ID from search results, providing strong usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden; it clearly reveals the underlying API's shutdown and advises a workaround, which is critical behavioral context. It stops short of describing error/failure behavior if the tool is called, but the presence of an output schema mitigates the need to document return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, leading with the critical shutdown warning before the argument list. Every sentence adds value with no filler or unnecessary repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter, one-step search tool with an output schema, the description covers purpose, parameters, and the crucial deprecation/alternative. It is slightly thin on what happens if someone invokes this tool anyway, but 'API shut down' communicates enough for most agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It does: ipc_code gets an IPC explanation and tangible example ('G06F'), and limit gets default and max constraints, with the max not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource construction: 'Search patents by IPC code,' which clearly states scope and differentiates from sibling tools like patentsview_search_by_cpc and ppubs_search_patents. The IPC example reinforces the unit of search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides a when-not-to-use directive: the PatentsView API was shut down, and it names the alternative, ppubs_search_patents, with the query strategy ('IPC query') to use instead. This is ideal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It indicates a read-only 'get' operation and specifies that the output includes claims, description, drawings, and metadata, but does not explicitly mention side effects or error conditions. The read-only nature is implied by 'get', which is sufficient for most use cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using two short sentences that cover purpose, usage, and parameters without extraneous information. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the operation (get by GUID), the description adequately sets expectations about the returned content (complete document with claims, description, drawings, metadata). It does not specify the exact format, but the mention of 'complete document' and its components provides sufficient context for an agent to decide if this tool fits the need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful details for both parameters: guid is exemplified with a concrete format, and source_type is explained with possible values (USPAT, US-PGPUB). This goes beyond the bare schema, which only lists types, significantly aiding correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves a complete patent document from PPUBS using a GUID, distinguishing it from search and download tools. The verb 'get' and resource 'patent document' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use the tool: when you have a document GUID from search results and need the full patent text including claims and description. This provides clear context and implicitly differentiates from alternative search or retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait (temporary unavailability) but does not explicitly state read-only behavior or potential error outcomes. Since no annotations are provided, the description carries responsibility, and it covers the most critical dynamic aspect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct, leading with the purpose, followed by an important note, then parameter details. It is well-structured and free of unnecessary verbiage, making it efficient for quick reference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (per context signals), it is acceptable that the description omits return details. It covers parameter usage and the availability caveat, but does not explain edge cases like date filtering semantics or pagination beyond defaults, leaving minor ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Each parameter in the schema is given a concise explanation (e.g., 'Patent that is citing', 'Filter by assignee name', 'Date range start (YYYY-MM-DD)'), adding meaningful context beyond the bare schema. This fully clarifies how to use each argument.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as 'Search citation records', which is specific and distinguishes it from other search tools for patents, trademarks, etc. It also provides an alternative when unavailable, reinforcing its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes temporary unavailability and directs users to 'patentsview_search_patents instead', providing clear when-to-use and when-not-to-use guidance. This effectively differentiates it from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries the burden. It indicates the response is normalized and that it is not the authoritative live status, giving useful behavioral hints, though it does not explicitly note read-only nature or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with sections for usage, arguments, and returns, making it easy to parse and apply.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Return value is described as 'Normalized response with the trademark record,' which is sufficient for a basic understanding, though more detail could be beneficial if the output schema is complex.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter serial_number is fully explained as an 8-digit application serial number with an example, making its meaning and format unambiguous despite the schema lacking a description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the function: retrieving a trademark's search-index record by serial number, and distinguishes it from other tools like tm_search_trademarks and tsdr_get_trademark_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use this tool (having a serial number from tm_search_trademarks and wanting the full indexed record) and when to prefer an alternative (tsdr_get_trademark_status for authoritative live status).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the operation is metadata-only, performs no downloads, and is not subject to the 4 req/min PDF rate limit, which is valuable non-obvious behavior. However, it does not mention auth requirements, other rate limits, or error handling, though for a simple read-only list that is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-line summary, a use-case paragraph, and Args/Returns sections. It is front-loaded with the key purpose. Slight redundancy exists (e.g., 'metadata only' appears multiple times), but every sentence contributes functional guidance, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter metadata listing tool with an output schema, the description covers the purpose, usage context, parameter format, return value, and integration with the download sibling. It does not leave critical operational gaps, making it complete for the agent's decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, serial_number, is given an explicit format ('8-digit') and an example ('78787878') in the description, while the schema provides no description for it. This fully compensates for the 0% schema description coverage, giving the agent precise guidance on how to fill the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource phrase: 'List prosecution document metadata for a trademark (no downloads).' It clearly distinguishes itself from the sibling tdrs_download_trademark_documents by explicitly stating it returns metadata only and excludes downloads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It contains an explicit 'USE THIS TOOL WHEN' section that tells the agent to use it to see what file-wrapper documents exist before downloading. It directly names the alternative tool tdrs_download_trademark_documents and explains the rate-limit difference, plus how to feed DocumentTypeCode values into the download tool's filter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavior. The verb 'look up' implies a read-only operation with no side effects, which is transparent. However, it does not explicitly state that it is read-only or mention any error conditions, but given the simple nature of the tool, the lack of such details is not a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with clear sections for the main description, usage guidance, and parameter/return details. It avoids unnecessary fluff while providing all essential information in a compact format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is complete: it states what it does, when to use it, the parameter format, and the return value. It provides enough context for an agent to decide when to invoke it and what to expect from it. No additional details are necessary for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides a detailed explanation of the single parameter 'code', including an example ('30' for 'Docketed New Case'). This adds meaning beyond the schema's simple string type, helping the agent understand the expected input format and content. The schema coverage is 100% as the only parameter is described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Look up USPTO application status code meaning.' It specifies the resource (USPTO application status code) and the action (look up meaning), distinguishing it from sibling tools like trademark status code lookups. The mention of 'examination stage' further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly includes a 'USE THIS TOOL WHEN' section, stating it should be used when encountering a status code in application data and needing to understand the examination stage. It also mentions what it returns, providing clear context for when to invoke it. No alternative tools are mentioned, but the specificity makes the usage unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the return structure ('Class title, type (goods/services), and description') and the read-only nature implied by 'Look up'. However, it does not mention any potential limitations, edge cases, or data source specifics, which would fully satisfy transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with clear sections ('USE THIS TOOL WHEN', 'Args', 'Returns'). Every sentence provides relevant information without fluff, making it easy to parse and act upon.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter) and the presence of an output schema, the description covers all essential aspects: purpose, when to use, parameter semantics, and return values. It is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides 'class_number' with type string and no description, so schema description coverage is 0%. The description compensates excellently by explaining the parameter's meaning, range (1-45), and providing specific examples ('9' for computer software, '25' for clothing, '42' for software services).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Look up a Nice/international trademark class (1-45).' It uses a specific verb ('look up') and resource ('trademark class'), and further distinguishes it from sibling tools by specifying it covers goods/services classes and is used for clearance searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides an 'USE THIS TOOL WHEN' section, listing concrete scenarios: knowing what goods or services a class covers, and picking classes for a clearance search. This gives clear guidance on when to use this tool versus alternatives in the trademark domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the critical fact that the underlying API was shut down, which is a major behavioral trait. However, it doesn't describe what happens if called (e.g., error or stale data), but the warning is sufficient for most purposes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a clear purpose line, an important note in caps, and an Args section. Every sentence earns its place; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (so return values are documented), the description covers purpose, the shutdown caveat, and parameter origin. For a tool that's essentially deprecated, it provides sufficient context to prevent misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds meaning: 'Disambiguated assignee ID from search results.' This tells the agent where to obtain the ID and it's disambiguated, providing valuable context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get detailed assignee information by disambiguated ID.' This specifies the verb (get), resource (assignee), and method (by disambiguated ID), distinguishing it from search tools like patentsview_search_assignees and peer get_inventor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly warns that the PatentsView API is shut down and no direct replacement exists, instructing to use odp_search_datasets instead. This gives clear when-not-to-use guidance and names a concrete alternative, exceeding typical usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since there are no annotations, the description carries the full burden. It discloses the major behavioral detail that the underlying API has been discontinued, which is critical for an agent to know before invocation. It also implies that the tool may fail or be non-functional, which is essential behavioral context beyond any schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and front-loaded with the purpose. The shutdown notice is important and appropriately placed. The use of whitespace slightly reduces density, but the content is efficient and each sentence earns its place, making it easy to parse critical information quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description is complete: it explains the input (attorney_id), the current operational status (shut down), and directs users to an alternative. No additional information about return values is needed due to the presence of an output schema. It fully equips an agent to use or avoid the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'attorney_id' as a string with no description. The description adds valuable context by explaining the parameter as 'Attorney ID from search results,' indicating the origin of the value. While it could be more detailed, it effectively compensates for the 0% schema coverage by providing a source reference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description immediately states 'Get detailed attorney information by ID,' which is a clear and specific declaration of the tool's purpose. It distinguishes itself from sibling tools by naming 'attorney' and 'ID', and further differentiates by explicitly pointing to the legacy status and the recommended alternative, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says the PatentsView API was shut down and instructs users to use 'odp_get_attorney' with a specific application number. This provides clear when-to-use guidance and names the alternative tool, fully covering usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It makes the essential runtime fact explicit: the underlying API is deprecated and unavailable, so the tool likely will not work. While it doesn't describe error formats or output details, the deprecation notice is the most critical behavioral trait and is clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary purpose, includes a clearly highlighted IMPORTANT deprecation note, and ends with an Args section for the parameter. Every sentence adds value with no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite only having one parameter and an output schema already present, the description is complete for decision-making: it explains what the tool would retrieve, why it shouldn't be used now, and which sibling tool will achieve the intended outcome. This makes the disambiguation fully informational.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema gives only the parameter name 'patent_id' with no description, while the description adds a semantic definition: 'Patent ID/number' with a concrete example. Since this is the single required parameter, this fully bridges the schema's coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves patent detailed description/specification text, distinguishing it from sibling tools like patentsview_get_patent and patentsview_get_claims. The verb 'Get' plus resource 'patent detailed description/specification text' is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns that the PatentsView API was shut down on March 20, 2026, and directs the agent to use ppubs_get_full_document instead. This gives a clear 'when not to use' condition and names an exact alternative, making the guidance excellent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses the critical behavior that the tool is non-functional due to the API shutdown, and provides an example query. It doesn't describe the expected error or return format, but the shutdown warning is the most important behavior and is well-covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loads the critical shutdown warning, and then provides parameter details in a clear Args block. Every sentence adds value, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's actual non-functional status, the description is complete: it states what the tool would do, why it can't be used, and exactly which sibling tool to use instead. The parameter documentation is sufficient for understanding the alternative query format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It explains cpc_code with a concrete example ('G06N3/08') and clarifies limit's default (100) and maximum (1000), adding meaning beyond the raw schema types and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search patents by CPC classification code' with a clear verb and resource. It also distinguishes itself by explicitly directing users to ppubs_search_patents as a workaround, which differentiates it from sibling patent search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit IMPORTANT warning that the PatentsView API was shut down and instructs agents to use ppubs_search_patents with a CPC query instead. This gives clear when-not-to-use and an alternative, exceeding the minimum guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of disclosing behavior. It openly reveals that the underlying API is discontinued as of March 20, 2026, implying calls will fail. This is a critical behavioral trait disclosed transparently, and it sets accurate expectations for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a prominent IMPORTANT warning first, followed by an Args list. It is somewhat long due to the essential shutdown notice, but every sentence adds value. It avoids fluff and is front-loaded with the most critical information, earning a high but not perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is fully complete for its context: it tells the agent the tool is non-functional, provides alternatives, and documents all parameters thoroughly. An output schema exists, so return values are covered. There are no gaps given the tool's deprecated status.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful details beyond the schema: it explains what 'query' targets (titles and abstracts), enumerates valid values for 'search_type' (any, all, phrase), and specifies the max limit (1000), none of which are in the schema. This compensates for the 0% schema coverage and enriches parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search US patents with PatentsView full-text search' which specifies the exact action and resource. It also distinguishes the tool by explicitly noting the API shutdown and recommending pPubs as an alternative, thereby differentiating it from sibling tools like ppubs_search_patents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: it states the API is shut down, directs users to ppubs_search_patents for full-text search, and suggests odp_search_datasets for bulk data. This is a clear 'when not to use' and lists concrete alternatives, fulfilling the usage guideline dimension perfectly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses the critical behavioral fact that the API was shut down, warning users of likely failure. It also implies a read-only operation by the verb 'get' without side effects, though it lacks explicit rate limits or auth requirements, which are less critical here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with front-loaded purpose, a brief but critical deprecation notice, and a minimal parameter explanation. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and existing output schema, the description covers the essential context: what it does, why it may not be usable, and what to use instead. The deprecation warning is vital for correct agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite zero schema description coverage, the description provides an Args section with a clear explanation and example (patent_id: Patent ID/number, e.g., '7861317'). This adds essential meaning beyond the bare schema type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all claims text for a patent' with a specific verb and resource. It distinguishes from siblings like patentsview_get_patent (metadata) and ppubs_get_full_document (full text) by focusing solely on claims text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says the API is shut down and instructs users to use ppubs_get_full_document instead. This provides clear when-to-use/alternative guidance, leaving no ambiguity about the tool's current status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure. It reveals the critical operational fact that the tool is non-functional due to API shutdown and points to an alternative. This exceeds the minimum requirement and prevents runtime failures, though it does not detail other behaviors like read-only status, which are irrelevant given the deprecation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct, with a clear warning first and a concise parameter explanation. Every sentence earns its place, providing critical information without fluff. It is well-structured and immediately actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not shown), the description covers essential context: the tool's deprecation and the recommended alternative. It is complete for a deprecated look-up tool, as the shutdown notice is the most critical context an agent needs. The single parameter is well documented, and the output schema presumably handles return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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. It explains the cpc_code parameter with format and examples ('class "G06" or group "G06N3/08"'), adding semantic meaning beyond the bare schema definition of a string. This is excellent for a single-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'looks up CPC classification code details', specifying the resource and action. It further distinguishes from sibling tool get_cpc_info by explicitly naming it as the alternative for CPC descriptions. Although it notes the API shutdown, the purpose remains unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: it declares the PatentsView API shut down and instructs to use get_cpc_info instead. This is a clear directive that prevents misuse and directs the agent to the correct sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well: it discloses the tool's core behavior (partial match support, disambiguation), the limit constraints (default 100, max 1000), and the critical fact that the underlying API is defunct. This is highly transparent about the tool's expected utility and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose, a prominent deprecation notice, and a concise parameter list. Every sentence adds necessary information without redundancy or bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter search tool with an output schema, the description is complete: it covers purpose, usage, deprecation, workaround, and parameter semantics. The presence of an output schema means return-value details are not required, and the description provides all necessary decision-making context for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides meaningful explanations for both parameters: 'name' is described as an assignee/company name with partial match support, and 'limit' is documented with its default and maximum. Since schema description coverage is 0%, this fully compensates for the schema's bare title-only property definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for assignees (companies/organizations) with disambiguation, using a specific verb (Search) and resource (assignees). It distinguishes itself from sibling tools like patentsview_search_inventors and patentsview_search_patents by focusing on the assignee entity and the disambiguation feature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes that the PatentsView API was shut down on March 20, 2026, and directs users to a specific alternative (ppubs_search_patents with an AN/ query) as a workaround. This is clear when/when-not guidance and identifies a sibling alternative, exceeding typical usage documentation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full weight and does so thoroughly: it discloses legacy query syntax failures, silent zero-result behavior, and server 500 errors, plus default sort behavior that affects result relevance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every section earns its place: usage guidance, parameter details, syntax pitfalls, and return summary are clearly structured and front-loaded with the most important decision information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complex query language and the lack of annotations, the description covers usage context, query syntax, failure modes, default behavior, and return fields. The output schema reduces the need to document return values further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates. The query parameter is documented with BRS syntax, field qualifiers, and multiple examples, while offset, limit, and sort all receive defaults and behavioral context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches granted US patents in Patent Public Search, with a specific verb and resource. It is also distinct from siblings like ppubs_search_applications and patentsview_search_patents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'USE THIS TOOL WHEN' guidance and contrasts with patentsview_search based on data freshness. This tells the agent when to select this tool over a key alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on full disclosure burden. It transparently reveals the tool is backed by an undocumented internal API, may break without notice, and has the same risk profile as PPUBS. It also clarifies that results are normalized and covers only federal marks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear headers (summary, USE THIS TOOL WHEN, NOTE, Args, Returns) and every line adds value. It is relatively long but necessarily so given nine undocumented parameters, and it front-loads the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 optional parameters and no annotations, the description covers use cases, parameter semantics, risk profile, scope limitations, cross-tool guidance, and expected return type. The output schema exists, so detailed return shape is not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), but the description's Args section explains every parameter with concrete examples, defaults, and constraints (e.g., international_class example '9', status_filter values 'live'/'dead', limit max 100). This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search US federal trademark applications and registrations.' It clearly distinguishes from sibling tools by noting that 'For authoritative status of a specific mark, use tsdr_get_trademark_status' and limiting scope to federal marks only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE THIS TOOL WHEN' section explicitly lists common scenarios (clearance/knockout searches, mapping a company's portfolio), names an alternative tool for authoritative status, and warns about the undocumented API risk. It also states exclusions like no common-law/state marks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses rate limits (4/min), size limits (10 MB, rejected above 4 MB with RESPONSE_TOO_LARGE), and the required prefiltering step. It also mentions the base64 PDF return format, covering the key behavioral aspects the agent needs to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then usage guidance, constraints, and parameter details in logical order. Every sentence serves a purpose—no filler, and the structure aids quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 params, 1 required) and no annotations, the description is comprehensive: it explains output (base64 PDF), required pre-step (list), constraints (rate/size), and parameter specifics. It fully equips the agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fill the gap. It does: serial_number format (8-digit) with example, document_type with concrete examples (OOA, SPE), and date range formats (YYYY-MM-DD). This adds substantial meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Download the prosecution document bundle for a trademark as PDF (base64)' and specifies content types (office actions, responses, specimens). This verb+resource structure distinguishes it from siblings like tsdr_list_trademark_documents and tsdr_get_trademark_image by focusing on downloading documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'USE THIS TOOL WHEN' and lists the use cases, then advises calling tsdr_list_trademark_documents first and filtering. This provides clear context and workflow direction, effectively differentiating from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![patent_mcp_server MCP server](https://glama.ai/mcp/servers/riemannzeta/patent_mcp_server/badges/card.svg)](https://glama.ai/mcp/servers/riemannzeta/patent_mcp_server)

Score Badge

Copy to your README.md:

[![patent_mcp_server MCP server](https://glama.ai/mcp/servers/riemannzeta/patent_mcp_server/badges/score.svg)](https://glama.ai/mcp/servers/riemannzeta/patent_mcp_server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/riemannzeta/patent_mcp_server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server