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

Annotations already establish readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds real behavioral value by disclosing the shape of the response (federal + state deadlines, penalty warning), but says nothing about coverage limits (all 50 states?), how future/multi-year deadlines are handled, or what happens for fiscal-year entities — meaningful gaps for a 'closed world' tool.

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

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

Front-loads the core question, then inputs, then outputs, then example queries — a sensible information order with no filler sentences. It is dense in one block rather than separated, but every clause carries 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?

No output schema exists, and the description compensates by describing the returned components. With only three required, fully documented parameters and a simple read-only operation, the only missing pieces are edge-case coverage notes, which are minor.

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 100%, so the baseline is 3, and the description earns above that by explaining the causal role of each input: entity type selects between the 5472/1120 path and the 1065 path, state drives the state due date, and formation date anchors the 'next' deadline. That is meaning beyond the schema field labels.

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?

Opens with a specific question-shaped purpose ('filing deadlines for a US LLC') and enumerates exactly what comes back: the next federal deadline (Form 5472 + pro-forma 1120 or Form 1065), the $25,000 penalty warning, and the state annual report/tax due date. The scope is narrow and clearly distinct from adjacent tools like ein_timeline or llc_cost_calculator, though the description never names those siblings or explicitly rules them out.

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?

Supplies concrete trigger phrasings ('when is my LLC tax return due', '5472 deadline', dormant-LLC questions), which is strong positive guidance about when to call it. It stops short of stating exclusions or pointing to alternatives such as tax_filing_estimate or compare_llc_states, so routing against siblings is left to inference.

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