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

Well beyond the annotations, it discloses cost/model behavior ('Model-backed and metered', the document arm performs 'no model call' with llm_called false), the failure mode for ambiguity (returns clarification_needed with one specific question and can be re-called), and lifecycle ('Nothing changes the books... returns the sealed document by value'). This reconciles the apparently contradictory create/readOnly combination: nothing persists until register/submit. Minor gap: it doesn't say what authorization or workspace state is required.

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 core purpose and the enum choice are front-loaded, which is correct, but the prose is padded with ornamental phrasing ('true in shared workspace reality', 'accountable assertion') that costs tokens without adding precision. Some sentences are load-bearing (document arm, clarification_needed, metering), but the paragraph is denser than a 6-parameter tool with full schema coverage requires.

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?

With an output schema present, return values needn't be explained, and the description still covers the hard parts: the two authoring arms and their exclusivity, the ambiguity/retry path, metering, the advisory filename, and the downstream register/submit step. What's left implicit is the relationship to sibling declaration tools and any preconditions on workspace_tag.

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 coverage is 100%, so the baseline is 3, but the description genuinely adds meaning: the canonical partyType value set (individual, business, trust, nonprofit, government, unknown), the constraint that parties carry only name/partyType/aliases, that one account_identity identifies one account, and that one parties declaration may assert a set with aliases. The mutual exclusivity of description vs document is reinforced in prose as well as schema.

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 gives a specific verb and resource — 'Authors one sealed declaration' — scoped to a workspace, and explicitly contrasts the return shape with create_standard_chart ('this door returns the sealed document by value; create_standard_chart returns a handle'). The phrase 'true in shared workspace reality and names no chart' is opaque jargon, but the follow-up enumeration of the five declaration kinds makes the actual purpose 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?

It tells the agent which of the five declaration kinds to select and gives routing rules for the tricky cases: contacts and addresses must go in party_profiles rather than parties, and source_assessment should prefer 'its exact document arm with the original finding and a reason.' It also states the follow-on workflow (review, register, submit). It never states when NOT to use this tool versus create_standard_declaration_chart or open_standard_document, so it stops short of full alternative coverage.

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