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

Beyond the annotations (destructiveHint=true, openWorldHint=true), it discloses that no publish occurs, that the response carries the post's id and uuid, that scheduling inputs are silently dropped, that media must be public URLs, and it encodes platform-specific constraints (caption length 4096/1024/500, Telegram target must be ACTIVE and can_post, 2-20 items for Threads CAROUSEL). That is substantive behavioral context the agent cannot get from the structured fields.

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?

Front-loaded with the most decision-relevant fact (draft, never published) before the reference material. The per-platform enumeration is dense semicolon-delimited prose; it earns its length because the schema is undocumented, but a more scannable structure would improve it.

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 5-parameter write tool with no output schema, the description covers what is created, what is returned (id and uuid), platform-specific body shape, caption limits, and media/target preconditions. An agent has enough to construct a valid call for any listed platform.

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 schema description coverage at 0%, the description carries the entire burden and mostly does: it maps `platform` codes, explains `account_id`/`account_uuid`, and gives per-platform key breakdowns for the free-form `fields` object. Minor gaps remain — it does not state which of account_id/account_uuid is mandatory when neither is required by the schema, nor cover every platform key exhaustively (e.g. fb privacy/link nuances).

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?

Opens with a specific verb+resource ('Create a DRAFT post') and immediately constrains scope to one social account, enumerating the valid platform codes. It explicitly separates itself from publish/schedule siblings by stating the post is 'not live, never auto-published', so an agent can tell it apart without opening 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?

Names the alternative explicitly and the condition that selects it: schedule fields are ignored here, use schedule_social_post after approval. The draft-vs-live distinction tells the agent when this tool is the correct first step rather than a publishing call.

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