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

The annotations already mark the tool as non-read-only, idempotent, and destructive; the description adds useful process context such as 'no server LLM', persistence of existing gates, and the boundary that original Office/PDF forms are not created or signed. However, it does not explicitly disclose what is destroyed or overwritten by reassembly beyond the word 'Reassemble', so the destructive effect is only implied.

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 front-loaded with the main purpose in the first sentence and every subsequent sentence adds a distinct, non-redundant constraint: prerequisites, internal-content exclusion, gate rules, timing, and boundary with document-pack tools. No filler or repetition.

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 complex mutating tool with no output schema, the description covers many operational aspects (prerequisites, exclusions, gates, alternatives), which is strong. It is incomplete, though, on how the required revision parameters are obtained or what the tool returns after assembly, leaving an agent without the full picture needed to invoke it confidently.

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%, with expectedRevision and expectedDraftRevision lacking descriptive text. The description does not explain how to construct these objects or what payloadHash/outputJobId refer to; it only mentions 'dossier revision' in passing. It adds little semantic value beyond what the input schema already states.

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 names a specific action ('Assemble') and a specific resource ('all mapped buyer-facing text fields into the existing sourced draft workflow'), plus a distinctive constraint ('without a server LLM'). It explicitly contrasts itself with document-pack tools by saying it does not create or sign original Office/PDF forms, which differentiates it from siblings like produce_document and export_document_pack.

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 states a clear precondition ('Requires complete section coverage'), exclusion criteria ('Internal knowledge, opportunity notes without buyer audience, strategy and audit stay internal'), and timing ('Reassemble after any dossier revision before final review'). It also names the alternative family ('use document-pack tools with exact original targets') when the task is creating or signing original forms, making the when/when-not decision explicit.

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