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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) by disclosing that the run is asynchronous (~2 minutes), that a run finding nothing is free, that it costs 8 credits charged only on success, that the agent must quote the price and wait for confirmation, and that nothing is posted. It also states the return value (a link to the drafts). This is exactly the operational context annotations cannot carry.

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-loads the action in the first clause and every sentence carries behavioral payload (cost, timing, confirmation gate, no posting). The platform branches are dense run-on sentences with nested parentheticals ('the exact tool it plugs into, the buyer's exact job'), which costs some readability but not information.

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 single-parameter, no-output-schema tool with open-world behavior, the description covers modality, duration, cost and billing trigger, the human-confirmation requirement, the return value, and the side-effect boundary ('Nothing is posted'). Nothing material is left for the agent to guess.

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 0% and the single enum parameter is undocumented in the schema, so the description carries the whole burden — and it does, defining precisely what 'reddit' searches (product communities plus one broad sub, up to six drafts) versus what 'x' searches (recent posts, up to five replies). An agent can choose the enum value from the description alone.

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 action — starting an Assisted-post run in the results app — and spells out the two modes (reddit: buyer questions in the product's own communities plus a broad sub, replies, an optional own post, up to six drafts; x: recent posts about the problem, one reply each, up to five). The phrasing 'start the run behind Assisted posts' is product jargon that a fresh agent must infer, but the platform branches make the resource concrete. It does not explicitly distinguish itself from reach_drafts or reach_mark, which keeps it below a 5.

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?

Gives an operative selection rule — 'for the platform the founder asked about' — and explains what each enum value will produce, so an agent knows which mode to pick and what to expect. It never says when to prefer this over sibling tools like reach_drafts or ideas_replies_find, so the alternative-selection layer is missing.

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