ClearMarket

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

No annotations were provided, so the description carries the full burden. It does not explicitly state this is a read-only operation or mention any side effects, auth needs, or rate limits. While it is implied as a fetch, transparency is lacking.

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 front-loaded with the main action and lists the returned data. It is efficient but slightly long; however, every sentence serves a purpose. No waste.

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 a single parameter and no output schema, the description thoroughly explains the return content (canonical question, markets, grades, etc.) and provides context for when to use this vs. sibling tools. It is fully adequate for the complexity.

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 parameter 'slug'. The description provides the same example as the schema ('kxgdpyear-26'), adding no new meaning beyond what the schema already conveys.

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 fetches the full ClearMarket record for one event by slug, listing specific data fields (canonical question, linked markets, prices, grades, etc.). It distinguishes from sibling tools like list_events which are for topics.

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?

It explicitly states when to use: 'when you need the authoritative, graded, cross-venue view of a SPECIFIC event before reasoning about or acting on a prediction market.' It also gives an alternative: 'If you only have a topic (not a slug), call list_events first.'

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 verb 'Fetch' implies read-only, but no annotations are provided, and the description does not explicitly state side effects or safety. Lists returned fields, adding some context beyond a simple fetch.

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?

Concise single sentence listing fields followed by usage guidance. Front-loaded with action, but could be slightly restructured for readability.

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 a single input parameter and no output schema, the description covers return fields well. Missing details on error cases or return format, but adequate for a simple fetch 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?

Only one parameter (market_id) with schema description. The tool description does not add meaning beyond the schema; schema coverage is 100%, so baseline 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?

Clearly states 'Fetch one market by market_id' and lists specific fields returned. Distinguishes from siblings (get_event, get_signal, etc.) which operate on different resources.

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 states when to use: 'Use when you have a specific market and need its resolution trustworthiness and provenance before trusting its price.' Does not explicitly mention when not to use, but context implies alternatives for listing.

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?

Given no annotations, the description carries the full burden. It discloses return format ('compact graded summaries (slug, question, venues covered, primary grade, price)') and explains the `q` parameter searches event questions. It does not mention pagination behavior beyond limit/offset parameters or rate limits, but the description is reasonably transparent 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?

The description is exceptionally concise: two sentences that cover main action, examples, output, and usage flow. Every sentence adds value; there is no redundancy or fluff. It is front-loaded with the purpose, then details.

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 6 parameters, no output schema, and no annotations, the description provides a good overview. It explains what the tool returns and how to use it with siblings. Minor gaps: no explicit mention of ordering of results, no explanation of 'venues covered', but overall it is sufficient for an agent to correctly invoke the 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 description coverage is only 33%, so the description must compensate. It adds value for the `q` parameter with concrete examples ('recession', 'bitcoin 150k', 'fed rate'), and explains `grade` as 'Resolution Clarity Grade' consistent with schema. Other parameters (category, platform, limit, offset) are self-explanatory in schema, but description does not elaborate further; still, it is helpful.

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 browses/searches prediction-market events with specific verb 'Browse or search' and resource 'ClearMarket prediction-market events'. It distinguishes from sibling get_event by advising to start here when lacking a slug, then call get_event for full record. Examples of search queries ('recession', 'bitcoin 150k') make purpose concrete.

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 says 'Start here when you have a topic but not a slug; then call get_event for the full graded record', providing clear context for when to use this tool versus its sibling. It also lists categories. No explicit when-not advice, but the guidance is strong and helpful.

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.