manage_conversation

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

Beyond the annotations, the description discloses the Pro-plan-plus-posts:write permission requirement, the 24-hour messaging window that governs whether a send succeeds, per-platform cooldowns (30s, 60s for LinkedIn), and that the send is a two-step preview/confirm flow rather than an immediate side effect. These are exactly the operational facts an agent needs and none of them are recoverable from readOnlyHint/destructiveHint/openWorldHint.

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?

Dense but front-loaded: the scope and permission gate come first, then each action is introduced with an 'action=' token that mirrors the enum. It is a single semicolon-chained paragraph that would read better as bullets, but no sentence is filler.

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 an 8-parameter, two-mode tool with no output schema, it covers permissions, platform limits, rate limits, and the send workflow well. It does not say what the preview actually contains or what happens when the 24-hour window has lapsed, which are the remaining questions an agent would have before its first 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 100%, so the baseline is 3, but the description adds meaning the schema does not: it pairs conversation_id and content with the 24-hour window constraint, frames confirm/preview_id as a workflow rather than a lone boolean, and ties account_id to per-platform cooldown and comments-only behavior for Threads and LinkedIn.

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?

Each action is given a specific verb and resource: 'send a DM reply in an Instagram or Facebook Page conversation' and 'pull the latest Instagram, Facebook Page, Threads, or LinkedIn inbox data for one account.' Platform scope and exclusions ('Threads has no DMs') let an agent distinguish it from siblings like list_conversations, list_comments, and manage_comment without opening a 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?

The description clearly separates the two invocation modes and lays out the exact preview-then-confirm sequence for send, including showing the preview to the user before confirming. It also names list_conversations and list_accounts as ID sources. It stops short of explicitly contrasting this tool with manage_comment or list_comments for comment handling, leaving that routing to inference.

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