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

Annotations only declare openWorldHint=false and destructiveHint=false; the description adds the key non-obvious behavior that this is a set-and-unset operation with a single-default-per-user-per-company invariant, plus the reassurance that no image bytes are involved. It does not mention permission requirements or reversibility, so it is strong but not exhaustive.

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?

Dense but front-loaded: the operation and its invariant come first, then the rationale for exposure. The trailing clause about ListSavedSignatures being 'already' exposed is meta-commentary that is slightly self-indulgent, but it does add context on why this tool exists.

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?

An output schema exists and covers return values, annotations cover the safety profile, and the description supplies the mutation invariant and payload note. For a two-param preference write, the only remaining gap is auth/Permission requirements and error behavior on an unknown signature id.

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%, so the two UUID wrapper parameters are already documented; the description only implies them indirectly ('per company', 'one of the caller's signatures'). Baseline 3 is appropriate when the schema carries the parameter burden.

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 verb and resource ('marks one of the caller's signatures as the default') and names the exact side effect that disambiguates it from the sibling set (unsetting any prior default, single default per user per company). An agent can distinguish it from documents_list_saved_signatures and documents_delete_saved_signature on the strength of the description alone.

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 a clear use condition ('the agent could name a founder's signatures but not act on them'), which frames this as the action counterpart to the listing tool. It does not state exclusions (e.g., when to delete vs. set default, or whether dirs must be pre-created via documents_create_document), so it stops short of full when/when-not guidance.

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