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

Annotations only provide openWorldHint=false and destructiveHint=false, so the description carries the burden of behavioral disclosure. It adds meaningful context: the value travels onto a bank application, a wrong classification is a compliance problem, the code is checked against the 2022 edition, and a code naming no real industry is refused. This goes beyond the annotations and helps the agent understand consequences.

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 a single paragraph of three sentences, front-loaded with the core action and then providing critical usage constraints. Every sentence earns its place, though it could be slightly more concise by trimming the compliance explanation.

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 (2 params, nested object, output schema present), the description covers the key context: sequencing, consent requirement, compliance stakes, and validation against the 2022 edition. It doesn't describe the return value, but an output schema exists, so that's not required. The main gap is not explicitly stating that naicsCode should be one of the suggested candidates, though that is strongly implied.

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 50%: formationId has a description ('UUID value wrapper') but naicsCode has no description beyond its pattern and maxLength. The description explains the meaning of the NAICS code and its compliance significance, but doesn't explicitly describe the naicsCode parameter format or that it should come from the suggested candidates. The description adds some value but doesn't fully compensate for the missing parameter 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 the tool records a NAICS industry classification a founder has chosen for their formation, with a specific verb ('Records') and resource ('NAICS industry classification'). It distinguishes itself from the sibling formation_suggest_naics_codes by explicitly naming it and explaining the sequencing.

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 when-to-use guidance: call formation_suggest_naics_codes first, show candidates, and call this ONLY after the person has explicitly picked one. It also states when not to use it ('Never choose on their behalf and never infer a code from the business description alone'), which is strong usage guidance.

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