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

Annotations already declare the mutation/idempotent/non-destructive profile, so the description only needs to add context — and it does: output lands as drafts, nothing is published, retries are deduplicated by key, and it discloses the auth prerequisite ('Needs the customer's key'). It stops short of saying what happens to channels that fail or what the saved draft contains.

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?

Four short sentences, front-loaded with the core transformation before the safety and retry details, and each sentence carries distinct information. No preamble or hedging.

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 7-parameter open-world write tool with no output schema, the description covers the main flow, the draft-only guarantee, dry-run, idempotency, and the auth requirement. It leaves gaps around the mutation's return payload and the one undocumented parameter, but nothing that would cause a wrong call.

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 86%, so the baseline is 3; the description's notes on dry_run and idempotency_key largely restate what the schema already documents. The 'title' parameter is undocumented in both places, and nothing is said about what happens if both url and text are supplied.

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 concrete verb-and-resource pair with full scope: one page or text into a native post for every enabled channel in every chosen language, saved as drafts. The 'saved as drafts' / 'nothing is published' framing cleanly separates it from amplify_schedule_posts and amplify_list_posts without needing the schema.

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?

Explicitly states when to reach for dry_run ('to see posts without saving') and idempotency_key ('so a retry never makes a duplicate'), and rules out publishing. It does not name the sibling amplify_preview as the alternative for the no-save case, which would have made the routing unambiguous.

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