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

With no annotations provided, the description carries the full behavioral burden and does so well: it discloses draft behavior, publishNow semantics, paid-plan requirement, automatic image fitting, rejection with per-platform issues list, and app-panel rendering instructions. These are exactly the traits an agent needs before invoking a write operation.

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 long but front-loads purpose, usage, and the compose_post alternative before diving into platform rules. Most sentences carry operational detail, though the platform list and some image-ratio guidance could be tightened; still, it is structured for scanning.

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 17-parameter, multi-platform tool with no output schema and no annotations, the description covers core invocation behavior, platform constraints, error handling, and UI rendering. It still omits how to source accountIds (get_accounts), alternatives like update_post/publish_post for existing drafts, and constraints for several supported platforms.

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 65%, so the description must add value, and it does: it gives platform-specific constraints for YouTube title, Pinterest media, X character/media limits, and Google Business Profile limits. It does not explain every parameter (e.g., external_id, accountOverrides, mediaUrl vs mediaUrls, timezone), leaving some gaps.

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 opens with a specific set of verbs (create, schedule, queue, publish, cross-post) and the resource (content to connected social accounts), lists supported platforms, and explicitly names compose_post as the alternative for self-serve editing. An agent can distinguish this from siblings like compose_post, update_post, and publish_post.

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 states exactly when to use it ('any request to post now, schedule for later, publish to multiple platforms at once, or add something to the posting queue') and when to prefer compose_post ('when the user wants to set the post up themselves or per-platform options are still open'). It also clarifies draft vs immediate behavior with scheduled_at/publishNow.

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