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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so 'Saves nothing' largely restates the safety profile. It does add one piece beyond the structured data: the response content includes state fees marked, which matters since there is no output schema. That is thin for a quote tool whose main output is a fee breakdown.

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?

Three short fragments, front-loaded with the outcome and followed by prerequisites and the no-persistence note; nothing is wasted. The telegraphic style ('with the state's marked') costs a little clarity, which keeps it off a 5.

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 20-parameter tool with nested objects and no output schema, the description covers only three inputs and says nothing about conditional requirements (shares for corporations, management and members for LLCs, purpose for nonprofits, county for publication states). The per-parameter schema descriptions compensate substantially, but an agent gets no high-level map of which combinations produce a valid, complete quote.

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 100% and each of the 20 parameters is individually documented, so the schema carries the burden and the baseline is 3. The description singles out entity/state/package as required, which adds prioritization but actually conflicts with the schema's empty required list, mildly risking confusion about what is truly mandatory.

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?

States a specific outcome: it returns every fee for a formation with the state's portion flagged. That is a concrete verb-less but unambiguous purpose, clearly a quote rather than a filing. It does not name the sibling it replaces (quote_application) so an agent must infer the difference from the formation-vs-application resource wording.

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?

'Needs entity, state and package' gives the minimum inputs and 'Saves nothing' implies this is the pre-commit preview before create_formation, so the usage context is inferable. However, no alternative is named and no when-not condition is given, leaving the agent to reason about quote_formation vs quote_application on its own.

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