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

With no annotations, the description carries the full behavioral burden, and it does disclose the core behavior in detail: the comparison scope and the exact conditions that produce a flag (YES prices/asks/bids not summing to ~1, ladder ordering violations). It leaves gaps on read-only/safety status, data freshness, and the shape of the flags it emits, but the analytical semantics are unusually well exposed.

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?

A single front-loaded sentence: verb and scope come first, and the colon-plus-examples clarify the detection rules without padding. It is dense and slightly run-on, but every clause (the mutually-exclusive, threshold-ladder, and date-ladder cases) earns its place.

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 read/analysis tool with no output schema and no annotations, the description is complete enough on what it computes and what a flag means. It could say more about the returned structure (e.g. which markets and inconsistencies are listed) and its read-only nature, but nothing critical to invoking it correctly is missing.

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 100% and both params are documented in the schema (market id/slug with parent event analysed, or an event id/slug). The description only echoes this by noting it accepts "a market (or an event)", adding no format or precedence detail, so the baseline of 3 is appropriate.

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 precise verb ("Compare") and resource ("all open markets in the same Polymarket event") and spells out the exact analytical output (flagging mutually-exclusive sums off ~1, out-of-order threshold/date ladders). This cross-market scope inherently separates it from single-market siblings like get_market and market_snapshot, so an agent can route correctly without opening either 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 trigger is clear: you call it with a market or event id when you want to detect inconsistent pricing across an event's markets. It doesn't explicitly name alternatives or state when not to use it (e.g. for a single market, use market_snapshot), so it stops short of full when/when-not guidance.

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