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

Annotations already declare readOnlyHint=false and destructiveHint=false, and the description adds meaningful context beyond them: the proposal is non-final until a board/stockholder/subject document is signed, retries should carry an idempotency key, and which backend action is invoked. The confirmation-boundary sentence is generic boilerplate that reads oddly for this tool, but the core behavioral disclosure is solid.

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?

Purpose and prerequisite-call guidance are front-loaded, which is good, but the Canonicality/Idempotency/Confirmation boilerplate is long and largely generic ('this read, reversible save, explicit fact/evidence record, link preparation, plan refresh'), padding the description with template text that is not specific to a departure proposal.

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 6-parameter mutation-style tool with 0% schema coverage, no output schema and a nested context object, the description covers prerequisites, idempotency and the non-final nature of the proposal, but leaves batch semantics (roleRecordIds) and the context envelope unexplained. Adequate but with clear gaps an agent would have to infer.

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%, so the description must carry parameter meaning, and it only partially does: it implies the role-record target via 'from a current role record' and mentions the idempotency key on retries. It never explains the kind enum values, the batched roleRecordIds array (up to 10), or _corply_context, leaving several parameters 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 first sentence states a specific verb (create/propose) and resource (proposed director or officer removal or resignation from a role record), and scopes it to Corply-formed or governance-reviewed imported Delaware C corporations. It does not explicitly differentiate itself from siblings like record_company_director_resignation or create_departure_package, but the purpose itself is unambiguous.

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?

Gives actionable sequencing ('Call list_governed_action_options first to resolve import evidence gaps') and states who may invoke it ('any active company member can propose') and the precondition ('no removal happens until the required ... document is signed'). It lacks an explicit contrast against the sibling record_* continuation tools, so it falls short of a 5.

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