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

With no annotations, the description carries full disclosure burden. It details the return structure (line items with CFR citations, total, excluded costs, practical note) and explicitly lists what is NOT included, which prevents user misconceptions.

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 dense but well-organized, front-loading the purpose and then expanding into returns and usage. It's longer than the 'two-sentence ideal' but every sentence adds value.

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 complexity (6 params, no output schema), the description covers inputs, outputs, exclusions, and a prerequisite call. It is complete for an agent to decide when and how to invoke it.

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

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

Schema coverage is 0%, so the description must compensate. It explains the meaning behind independent/total claim counts, multiple dependent claims, page count, and entity status, tying them to fee rules. It doesn't explicitly describe filing_type values, but the schema already enumerates them.

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 ('Compute') with a precise resource (USPTO filing fees under 37 CFR 1.16) and enumerates each fee component, making its purpose unmistakable. It clearly distinguishes from siblings like find_uspto_form or calculate_response_deadline.

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 use cases ('budgeting and comparing scenarios') and mentions calling check_entity_status first when uncertain. It lacks an explicit when-not-to-use clause, but the context is clear enough.

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 transparency burden. It discloses the legal basis (CFR sections), the output structure (deadline, 6-month max, extension table), and the calculation logic, but does not explicitly state the tool has no side effects or is a pure calculation.

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 sentences, each serving a distinct role: purpose, legal basis, output, and usage. No redundancy or filler, making it appropriately sized and 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 tool with neither annotations nor output schema, the description covers inputs, legal basis, output, and usage. The gap around advisory_action handling and date format prevents a perfect score, but it is largely complete.

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

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

Schema coverage is 0%, but the description adds meaning by linking action_type to shortened periods ('2 for restriction requirements'), entity_status to fees, and the mailing date as the starting point. It does not specify the date format or the advisory_action period, which keeps it from a 5.

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 'Compute' with clear resources ('response deadline' and 'cost'), and references CFR sections. It distinguishes itself from sibling tools like 'calculate_filing_fees' by focusing on deadlines and extensions.

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?

Explicitly states 'Use when an inventor receives an Office Action or is deciding whether to buy an extension,' giving clear context. However, it does not name alternative tools or specify 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 are provided, so the description carries the full burden. It discloses what the tool returns: 'the determination, full step-by-step reasoning through the 1.29(a) prongs (gross income, prior filings, assignment obligations), the certification form to file (SB/15A or SB/15B), and a practical note about how to certify correctly.' This gives clear behavioral expectations without relying on annotations. It does not mention side effects or permissions, but for a determination/calculation tool, this is sufficient context.

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

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

The description is structured with a clear opening purpose, usage guidance, a practical caution, and a listing of outputs and inputs. It is about 120 words and contains no filler or repetition. It could be slightly more concise by breaking the output list into bullets, but the current prose is readable and each sentence adds value.

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 complexity and the absence of an output schema, the description does a good job explaining what the tool returns and what it needs. It covers legal basis, output shape, certification forms, and input semantics. It does not explicitly state threshold values or edge cases, but the promise of 'full step-by-step reasoning through the 1.29(a) prongs' suggests the tool will handle the details. The missing optional parameter also affects completeness, so it does not earn a 5.

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

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

Schema coverage is 0%, so the description must compensate by explaining parameters. It explicitly describes the three required inputs ('the inventor's gross income last year, count of prior US nonprovisional applications they have been named on, whether their employer has any obligation to claim ownership of this invention'). However, it omits the optional `university_or_nonprofit_affiliation` parameter, which is relevant to the 1.27 micro entity criteria. This gap means the agent might not know to ask for or consider that input, despite its default value.

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 opens with a specific verb and resource: 'Determine whether the inventor qualifies as a USPTO micro entity, small entity, or large entity under 37 CFR 1.27 and 1.29.' This immediately distinguishes it from siblings like calculate_filing_fees or find_uspto_form by stating the role of the tool. It also explicitly notes the tool should be used BEFORE calculate_filing_fees, reinforcing its specific 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 gives explicit guidance on when to use the tool: 'Use this tool BEFORE calculate_filing_fees so the fee math uses the right entity status.' It also provides contextual motivation by explaining the common error of pro se inventors defaulting to 'large entity.' However, it does not explicitly state when NOT to use it or mention alternative tools beyond calculate_filing_fees, 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.

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

With no annotations provided, the description carries full transparency burden. It thoroughly explains what the tool determines (filing windows, forms, fees, certifications) and adds regulatory context (duty of disclosure under 37 CFR 1.56). It doesn't explicitly state it's read-only, but the analysis-oriented language implies no mutation.

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 two sentences with substantive content, no filler. The first sentence densely packs the tool's core capabilities, and the second provides motivational context. It is appropriately sized for the tool's complexity, though the first sentence is long.

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?

Despite having no output schema and six parameters, the description covers the tool's decision logic, usage context, and relevant legal references comprehensively. It explains what the tool determines and when to use it, but doesn't describe the return format or edge cases, which is a minor 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?

Schema description coverage is 0%, so the description must compensate. It explains the conceptual stages (before first OA, final/allowance) and references conditions like RCE and prior art, which relate to parameters like `last_office_action_type` and `has_rce_been_filed`. However, it doesn't map each parameter or explain ambiguous ones like `references_first_known_date`.

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 determines IDS requirements, filing window, form selection, and fee/certification needs. It uses specific terminology (Information Disclosure Statement, SB/08A, SB/08B, 37 CFR 1.97(e)) and distinctly differentiates from sibling tools focused on forms, fees, and deadlines.

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 says 'Use this tool whenever an inventor learns of new prior art or asks about IDS.' It provides clear context for when to invoke it, though it doesn't explicitly contrast with alternatives or mention when not to use it.

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 burden of behavioral disclosure. It transparently states that it returns up to 5 best matches ranked by relevance and includes procedural gotchas. However, it does not mention how entity_status affects results or any edge-case behavior, but for a read-only mapping 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.

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

The description is three sentences, front-loaded with the core action, and includes examples and return behavior without unnecessary fluff. Every sentence adds value, making it appropriately 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?

The description covers the tool's output (form number, name, URL, usage, gotchas) and use case, which is helpful given no output schema. The only notable gap is the unexplained 'entity_status' parameter, which prevents full completeness for an optional input that could affect results.

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 clarifies the 'purpose' parameter as the plain-language description of the inventor's intent. However, it gives no explanation for the 'entity_status' parameter, leaving its purpose ambiguous despite the enum in the schema. With 0% schema coverage, the description only partially compensates for the lack of parameter documentation.

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 maps a plain-language description to the correct USPTO form, with a specific verb ('Map') and resource (USPTO PTO/SB or PTO/AIA form). It lists the output fields and differentiates from sibling tools that handle status, fees, and deadlines.

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 states when to use the tool: when an inventor describes an intent but does not know the form number, and provides concrete examples. This makes the intended usage unambiguous and distinguishes it from alternatives.

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 fully carries the transparency burden. It goes beyond the basic intent by disclosing that 37 CFR 1.7(a) weekend/federal-holiday rollover is applied automatically, and it clarifies that the month-10 target is a best practice rather than statutory—crucial context for user expectations. This level of behavioral detail exceeds what most tool descriptions provide.

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 relatively long but organized as a clear list of computed dates, with statutory references. Every sentence contributes necessary information (e.g., rollover rule, best-practice clarification). It is front-loaded with the primary purpose and use case, making it easy to parse despite its length.

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 legal complexity and the absence of an output schema, the description adequately covers the what, why, and when. It explains the statutory bases, distinguishes non-statutory deadlines, and mentions the automatic rollover. It does not describe the return format or error handling, but these are secondary given the detailed scope and usage guidance.

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 for parameter meaning. It clearly implies the required provisional_filing_date ('Given a provisional patent application's filing date') and hints at jurisdiction_priorities via 'if foreign filings are planned' for the PCT deadline. However, it does not specify the expected date format or the exact values/meaning of the jurisdiction_priorities array strings, leaving significant room for ambiguity.

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

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

The description uses a specific verb and resource ('compute every date the inventor needs to track' from a provisional filing date) and enumerates the exact outputs (nonprovisional deadline, month-10 target, 102(b)(1) grace period, PCT deadline). It clearly distinguishes itself from sibling tools like calculate_response_deadline by focusing on provisional-specific statutory deadlines.

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 states 'Use when an inventor mentions a provisional filing date or asks "when is my nonprovisional due"', giving clear context for when to invoke. It does not name alternative tools or provide when-not-to-use exclusions, so it falls short of a 5 but is well beyond vague or absent guidance.

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