ClearMarket

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

With no annotations provided, the description fully discloses behavior: it lists all returned fields (canonical question, markets, grades, provenance, also_on, catalyst dates), explains the detail parameter's effect on output, and warns about rare cases where shared question_id links different contract shapes. No contradictions with annotations.

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 lengthy but well-organized, front-loading the main purpose. Each sentence adds necessary information, though the warning about arbitrage pairs adds length. Could be slightly more concise, but structure and clarity are strong.

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?

Despite no output schema, the description thoroughly explains return structure, behavior of both detail levels, cross-venue linking via also_on, and edge cases. For a tool with only 2 parameters and no nested objects, this provides complete context for correct agent invocation.

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%, so baseline is 3. The description adds value by explaining slug format with an example and detailing the output differences between 'concise' and 'full' for the detail parameter, which goes beyond the schema's brief enum description.

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 explicitly states 'Fetch the full ClearMarket record for one event by slug', clearly identifying the verb and resource. It distinguishes from sibling tools like get_market and list_events, noting that detail='full' eliminates need for separate get_market calls and that list_events is needed when only a topic is available.

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 provides explicit guidance: 'Use when you need the authoritative, graded view of a SPECIFIC event' and 'If you only have a topic (not a slug), call list_events first.' It also advises on detail levels: 'Set detail="concise" for a quick grade/price/source check' and default 'full' for complete record.

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

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

With no annotations, the description carries full burden. It discloses multiple behavioral traits: the tool judges trustworthiness, returns a Resolution Clarity Grade with a cap explanation, provides full provenance, and outputs the canonical id. No contradictions with any hidden annotations.

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 a single paragraph that front-loads the core purpose. Every sentence adds value, though it is somewhat long and could benefit from bullet points for better readability. It is efficient given the complexity of the 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?

Despite no output schema, the description thoroughly explains what the tool returns (question, price, grade, provenance, etc.) and the significance of the canonical id. It covers input, behavior, and output comprehensively, leaving no critical gaps for an agent.

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?

The single parameter 'market_id' already has 100% schema coverage. The description adds significant value by explaining how different id formats are resolved best-effort (e.g., 'for Polymarket pass the conditionId'), which goes beyond the schema's description.

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 clearly states the tool's purpose: 'Fetch one market and judge whether its price can be trusted.' It specifies the resource (market) and the unique action (judging trustworthiness), differentiating it from sibling tools like get_event or get_signal.

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 provides explicit guidance on acceptable input formats (ClearMarket id, venue-native id, Kalshi ticker, URL) and best-effort instructions for Polymarket. It also advises storing and reusing the returned canonical ClearMarket id. This helps the agent select and invoke the tool correctly.

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

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

No annotations are provided, so the description carries the full burden. It describes the return structure comprehensively but does not disclose any behavioral traits such as rate limits, authentication needs, or error conditions. A 3 is appropriate as it adds value beyond annotations but lacks some behavioral context.

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 a single sentence that front-loads the action and then lists the return components. No filler words; every part adds value.

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?

Given the tool has only one parameter and no output schema, the description fully explains the return value (headline, bullets, claims, etc.). The usage context is also clear.

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% (one parameter) with a good description in the schema. The tool description adds 'from list_signals' context but doesn't meaningfully extend beyond the schema. Baseline 3.

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 starts with a specific verb ('Fetch') and resource ('CM Signal wire by slug'), listing the exact components returned. It distinguishes from siblings like 'get_event' by specifying it's for a wire slug from 'list_signals'.

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 explicitly states when to use it: 'Use when you have a wire slug (from list_signals) and need the complete bulletin with its proof chain.' While it doesn't explicitly state when not to use, the context is clear and alternatives are implied via sibling tool names.

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

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

The description discloses key behaviors: q token-AND matching, return fields (slug, question, etc.), and filtering options. It lacks explicit mention of pagination (limit/offset) and safety, but with no annotations, it still provides substantial behavioral context.

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 a single paragraph that efficiently conveys purpose, filters, query behavior, return format, and usage pattern. It is front-loaded with the most important information and contains no wasted words.

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?

The description covers the tool's purpose, filtering, search behavior, return fields, and usage pattern. It lacks explicit details on pagination and sorting, but given the tool's complexity (6 parameters, no output schema), it is fairly comprehensive.

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 low (33%), and the description compensates by detailing q behavior and listing categories. However, limit, offset, and platform are only mentioned briefly without added semantics, so compensation is partial.

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 clearly states the tool's purpose: 'Browse or search ClearMarket prediction-market events' and lists filtering capabilities. It distinguishes from siblings by advising to start here and then call get_event, differentiating it from other tools like list_signals.

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 provides explicit usage guidance: 'Start here when you have a topic but not a slug; then call get_event for the full graded record.' It also explains that q is token-AND and advises using short keyword queries, effectively guiding when to use this tool.

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

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

Discloses return order (newest first) and that records are compact. However, no output schema exists and description does not detail what fields a compact record contains, nor pagination behavior beyond the limit parameter. Still, given no annotations, the description adds sufficient behavioral context for a read-only list tool.

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?

Three sentences, each serving a purpose: context, filter options, behavior and alternative. No redundancy or fluff. Front-loaded with the core concept.

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?

Covers purpose, filters, ordering, and alternative tool. Lacks details on record structure and filter combination logic, but given the complexity (5 parameters, no output schema) the description is fairly complete for a list tool.

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 only 40%, so description compensates by listing all five filterable fields and enumerating detection_type values. It adds context for event_id and detection_type beyond the schema. However, limit and venue are not elaborated, and category values are only in the schema description.

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?

Description clearly states it lists compact prediction-market bulletins (signals) and differentiates from sibling get_signal. It specifies filters and that it returns the latest editorial read, leaving no ambiguity about the tool's function.

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?

Explicitly mentions when to use get_signal for full bulletins and list_events for thematic filtering. Also implicitly guides use for finding ClearMarket's editorial read, providing clear context for when this tool is appropriate.

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

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

No annotations are provided, and the description does not disclose behavioral traits such as read-only status, authorization needs, or rate limits. It mentions provenance of entries but lacks transparency on side effects or performance, leaving the agent uninformed.

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?

Two sentences with no wasted words. Front-loaded with specific event types and the tool's unique cross-event view. Every sentence adds value.

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?

While there is no output schema, the description indicates entries are provenanced to authoritative sources. It covers the tool's function and scope adequately for a simple list with one parameter. However, it does not specify if results are sorted or limited, leaving minor gaps.

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?

The schema provides no parameter descriptions (0% coverage). The description explains the 'days' parameter as 'in the next N days,' adding meaning beyond the schema's simple integer type. For a single parameter, this is helpful but could be more explicit about the default value.

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 clearly states it lists scheduled catalysts (CPI, jobs, FOMC, GDP, large-cap earnings) with a cross-event view, distinguishing it from sibling list_events and list_signals by specifying the scope and purpose related to prediction markets.

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 explicitly says 'Use to find what scheduled events will reprice the prediction-market universe soon,' providing clear context. It does not explicitly mention alternatives or when not to use, but the cross-event view implicitly differentiates from siblings.

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