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

No annotations are provided, so the description must carry the full burden. It explains the return values (configuration, connection, rate limits) and implies a read-only operation. However, it does not explicitly state that the tool is non-destructive or has no 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences: purpose, when to use, and return contents. It is front-loaded and every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and an output schema exists (not shown but indicated), the description covers purpose, usage, and returns. It is complete for this simple diagnostic tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the input schema (empty) already fully covers them. According to guidelines, baseline is 4 for 0 parameters. The description does not need to add parameter info, and it does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verb 'Check status and availability' and identifies the resource 'USPTO ODP API'. It clearly distinguishes this tool from siblings which perform specific data lookups, as this is a diagnostic tool for API health.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly provides a 'USE THIS TOOL WHEN' section, stating to use it upon encountering errors or to verify configuration before starting research. This gives clear context and differentiates it from other ODP tools.

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

No annotations provided, but the description details auto-quoting, wildcards, parameter translation, and AND/OR logic. However, it lacks disclosure on rate limits or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with sections and front-loaded purpose, but lengthy due to comprehensive examples; could be slightly more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers major usage patterns and parameter details, but lacks explicit error handling or edge case descriptions; output schema is mentioned but not detailed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the description provides extensive parameter documentation including mapping, auto-quoting, wildcard usage, and advanced query syntax.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Search patent applications in USPTO Open Data Portal' and contrasts with PPUBS, distinguishing it from other retrieval 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Includes a 'USE THIS TOOL WHEN' section with explicit criteria, parameter mapping, and advanced query guidance, clearly indicating when to use this tool.

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

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

No annotations are provided, so the description carries the 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.

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.

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.

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.

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.

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.