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

With no annotations, the description carries the full burden and does so well: pricing and billing source (clink shop credits, get key via buy_credits or /buy/credits), free-on-empty/failed behavior, 404 when no market matches, and the facts-only/no-investment-advice disclaimer. It also describes the return shape (probability, X read, alignment verdict), which is exactly the behavioral detail an agent needs.

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 core capability leads, followed by output shape, then cost/billing, then the compliance disclaimer. The disclaimer sentence is long but arguably necessary for a finance-adjacent tool; otherwise little is wasted.

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?

Even without an output schema, the description explains what comes back (headline probability, crowd lean, alignment verdict) and covers cost, failure behavior, and disclaimers. An agent has everything needed to invoke it correctly and interpret the result.

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% for the single required 'q' parameter, so the schema already documents it fully. The description reinforces that it takes a question/topic but adds no syntax, format, or example detail beyond the schema's own example.

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 specific combined verb+resource: prediction-market probability (Polymarket + Kalshi) fused with X/Twitter sentiment on the same question. It also names the concrete outputs (headline probability, crowd lean, aligned/diverges/no_clear_read verdict), which clearly differentiates it from siblings like pm_odds (odds only) and x_search (social only).

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 makes the use case clear: fetch both market probability and social sentiment in a single call, with the cost ($0.05) and the free-on-failure condition as decision inputs. It does not explicitly say when to prefer a narrower sibling such as pm_odds instead, so it stops short of full when/when-not routing.

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