check_entity_status

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.