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

Annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=false) only say it is a non-destructive mutation. The description adds real behavioral context beyond that: the board-then-stockholder consent sequence, that company facts change only after Delaware filing/acceptance, an idempotency-retry directive, and canonicality guidance to trust the returned output rather than issuing a state-recovery call. The 'confirmation boundary' sentence is generic boilerplate, but overall disclosure is strong.

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 workflow sentence is front-loaded and earns its place, but the remainder is padded with reusable policy boilerplate ('Canonicality:', 'Idempotency:', 'Confirmation boundary:', 'Prerequisite: ... every prerequisite stated above') that reads as template text rather than tool-specific guidance. Roughly a third of the description could be cut without information loss.

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 high-complexity governed mutation with no output schema, the description covers the approval workflow, prerequisites, retry behavior, and where to read the real result. It still leaves the agent without per-parameter semantics and without any statement of failure modes or what identifier the proposal returns, so it is adequate rather than 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 description coverage is 0% across 8 parameters (5 required, one enum, one nested object), so the description carries the burden. It partially compensates: 'company-name or authorized-common-share' maps to the `kind` enum, 'latest accepted certificate' implies `sourceCharterHash`, and the idempotency sentence implies `idempotencyKey`. It says nothing about `companyId`, `officerPersonId`, `newLegalName`, `newAuthorizedCommon`, or `_corply_context`, leaving half the surface undocumented.

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+resource+scope: 'Propose a company-name or authorized-common-share charter amendment against the latest accepted certificate.' That maps directly onto the two enum values of `kind` and distinguishes it from formation-change and frozen-application siblings. It stops short of naming an alternative tool, so it is clear but not sibling-differentiating at the 5 level.

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 describes an ordering context (board approval opens first, then stockholder written consent, then operator filing) which implies when the tool fits. However, the prerequisite line is self-referential filler ('plus every prerequisite stated above'), and it never states when to prefer this over `propose_formation_change` or `amend_frozen_application`, or what conditions block use.

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