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

Annotations already carry destructiveHint=true and readOnlyHint=false, and the description does not contradict them. It adds no details about whether source companies are deleted, reversibility, or permissions; the only addition is the prerequisite to read the write-tools skill, which is useful but not a disclosure of merge behavior.

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?

Two sentences with the core operation front-loaded and a single actionable prerequisite following. No filler or redundant phrasing.

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 destructive multi-source merge with no output schema, the description alone lacks the consequences of merging, but it explicitly directs the agent to read the write-tools skill before first use. That reference makes the definition actionable and fairly complete in context.

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?

With 0% schema description coverage, the description must carry the semantic load, and it does convey which parameter is the target and which are sources, plus 'one or more' cardinality. However, it adds little beyond the property names and minItems in the schema, and does not elaborate on ID formats or parameter-specific constraints.

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 the action ('Merge'), the object ('companies'), and the relationship ('source companies into a target company'). This is specific enough to distinguish it from sibling tools like merge_people and merge_topics.

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 gives a clear operation and a prerequisite (read the write-tools skill), but it does not explicitly say when to use this over merge_people/update_companies or what conditions exclude it. The skill reference is a procedural instruction, not a usage-alternative explanation.

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