dino.markets

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

No annotations provided, so the description carries the full burden. It comprehensively discloses the delay, snapshot nature, fee inclusion, conservative capital estimates, and that values are not guarantees. There are no contradictions.

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 long and dense, containing many details about the data structure and limitations. While it is front-loaded with the core purpose, the length and density reduce conciseness. Some information could be structured or abbreviated.

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 simple parameters and presence of an output schema, the description adds extensive context about the data's nature (snapshot, delay, fee model) that is not inferable from the schema alone. It is fairly complete for the tool's 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 0%, so the description must compensate. It explains the 'sport' parameter with examples and context but does not mention the 'limit' parameter, leaving it unclear. The description adds some value but misses covering all parameters.

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 finds cross-venue arbitrage opportunities between Kalshi and Polymarket. It distinguishes itself from siblings like watch_markets (real-time) and get_spreads (different data) by specifying its nature as a REST snapshot and mentioning the alternative WebSocket feed.

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 clear context that this is a best-effort, delayed snapshot and not execution-grade, and explicitly recommends using watch_markets for real-time needs. However, it does not provide guidance on when to use this versus other sibling tools like find_markets or list_markets.

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 read-only nature (lookup), matching behavior (case-insensitive, against many fields), output type (lean canonical market objects, no live prices, same shape as list_markets), pagination (max 50 per page), and cost/free access. However, it does not specify error handling or rate limits beyond 'free to any active key'.

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 key purpose and usage guidance. Each sentence adds distinct value: purpose, front-door role, matching behavior, return shape, pagination, filters, API endpoint, and cost. No superfluous text; highly efficient for an AI agent.

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's complexity (6 parameters, 0% schema coverage, no annotations) and the existence of an output schema, the description covers all necessary context: when to use, what it returns, pagination limits, filter options with defaults, and cost. It sufficiently enables correct agent invocation without needing external knowledge.

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?

Despite 0% schema description coverage, the description explains all parameters: q as free-text query, page and page_size as pagination (max 50), and filters for category, sport, and status with default 'open,live' and enumerated values. This adds significant meaning beyond the bare schema types and defaults.

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 performs 'free-text market/event lookup' by multiple criteria like team, competition, and market title. It distinguishes itself from siblings by positioning as the 'AGENT FRONT DOOR' and explicitly listing sibling tools that depend on its output (get_market, list_markets, get_spreads).

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 instructs to call find_markets FIRST before other tools to resolve names into market IDs. Provides context on when to use (e.g., 'Yankees', 'EPL') and implies not to skip if an ID is needed. Mentions alternatives indirectly by naming sibling tools that require the returned ID.

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 provided, so description carries full burden. It suggests a read operation ('census') but doesn't explicitly state behavior, auth needs, or what 'coverage census' entails. Adequate but not fully transparent.

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 concise sentences, front-loaded with purpose, no fluff. 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?

Given zero parameters, presence of output schema, and clear purpose with usage guidance, it is mostly complete. Minor gap: does not specify if tool is read-only or restricted, but acceptable for simple no-param 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?

No parameters exist, so baseline 4 applies. Description adds no parameter info, but schema coverage is 100% and parameters are none.

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 'Internal coverage census for the matched feed' which is a specific verb-noun pair, and distinguishes from sibling by noting 'Most integrations want find_markets instead.'

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 advises when not to use by stating 'Most integrations want find_markets instead,' providing clear guidance on alternative 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?

With no annotations, the description fully discloses behavior: accepted id formats, return contents (settlement, venue ids, depth), caching semantics (settlement changes rarely, prices change often), a known limitation regarding fired arbs, 404 return for missing markets, and a REST endpoint mirror. This goes far beyond the annotations (which are absent) and gives the agent reliable expectations.

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?

While the description is longer than typical, every sentence contributes crucial information: purpose, id formats, return highlights, caching, limitation, alternative, error behavior, endpoint mirror, and auth. It is well-structured, front-loaded with the main purpose, and contains no filler or redundancy.

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 is exceptionally complete for a simple one-parameter tool with an output schema. It covers input flexibility, key output fields, data freshness, known edge cases, error handling, alternative tools, and access requirements. The agent has everything needed to invoke and interpret results correctly.

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 input schema only says 'id' is a string, but the description adds rich semantics: it accepts dino_<uuid>, a bare UUID, or a persisted slug, and references the same resolution as get_settlement. With 0% schema description coverage, this fully compensates and gives the agent clear guidance on what values to supply.

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 states exactly what the tool does: 'Fetch the canonical market object for a single market by its id.' It specifies the resource and scope, and differentiates from siblings by naming find_arbitrage for alternative shapes and get_settlement for id resolution. The purpose is immediately clear and unambiguous.

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 when to use this tool versus alternatives: 'Use find_arbitrage for the native opportunity shape.' It also advises caching behavior ('Cache this aggressively') and clarifies id resolution compatibility with get_settlement. It effectively tells the agent when this tool is appropriate and when another tool is better suited.

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 the full burden and excels: it discloses accepted ID formats, the absence of price data, the static nature of settlement, the cross-venue verdict behavior (never raw Kalshi winner), 404 on not found, endpoint mirroring, and auth requirement ('active dino.markets key'). This is rich, non-redundant 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 front-loaded with the core purpose and return fields, then provides justifiable behavioral details. Every sentence adds value—no fluff or repetition of schema—making the length appropriate for the information density.

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's simple structure (one parameter, output schema present), the description fully covers key aspects: return shape, caching, error behavior, endpoint mapping, and access requirements. It is complete enough for an agent to select and invoke correctly without further context.

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%, but the description adds substantial meaning by specifying accepted input formats ('dino_<uuid>, a bare UUID, or a persisted slug') and clarifying the parameter corresponds to a market ID. It directly compensates for the schema gap.

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 fetches the identity + settlement view of a single market, lists exact return fields, and explicitly contrasts with get_market ('Skips the price join get_market does'). This gives a specific verb, resource, and scope while distinguishing it from the sibling tool.

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 provides explicit when-to-use guidance by explaining that settlement is static fine print, not a live quote, making it cheaper and cacheable, and implicitly directs users to get_market for live quotes. The alternative is named, and caching behavior is specified.

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 the full burden. It discloses that only verified-band rows are returned, the band allowlist is inherited verbatim, and there is no tier restriction. This provides useful behavioral context beyond the tool's purpose.

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 dense paragraph containing three long sentences. While it conveys necessary information, it could be more concise and structured, especially given the many optional parameters.

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 complexity (10 parameters, no schema coverage, output schema exists), the description covers the tool's purpose, auth, filtering, and a prerequisite. It does not detail output, but an output schema is provided. Overall, it is fairly complete.

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 0%, yet the description only explicitly mentions 'min_gap' and 'limit' parameters, and vaguely references 'category' and 'context fields'. The other 6 parameters (asset, basis, sport, location, indicator, competition, institution) are left unexplained, leaving significant ambiguity.

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 defines the tool as a cross-venue price-gap view for spread-only matched pairs, specifying that it returns only verified-band rows. It distinguishes itself from siblings like find_markets and find_arbitrage by focusing on spreads.

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 to call find_markets first if name resolution is needed, setting a clear prerequisite. It also mentions optional filters but does not explicitly state when to avoid 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?

No annotations are provided, so the description carries the burden. It mentions that the tool is 'free to any active dino.markets key', indicating no extra restrictions. However, it does not disclose other behavioral traits like idempotency, rate limits, or whether it is read-only.

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 with no wasted words. The first sentence states the action and resource, the second gives usage guidance, and the third provides a behavioral note. Front-loaded with purpose.

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?

With zero parameters and an output schema (present but not shown), the description adequately covers the tool's role in discovering filters for other tools. It could mention whether the list is exhaustive or time-sensitive, but for a straightforward listing tool, it is complete.

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 input schema has zero parameters with 100% coverage. The description adds meaning by specifying the resources listed (categories, types, facets) and the purpose of discovering filters, which is valuable context beyond the schema.

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 verb 'list' and the resource 'normalized market categories, market types, and category-valid contextual facets'. It also distinguishes from sibling tools by indicating it should be called first to discover filters.

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 'Call this first to discover valid filters for the other tools', providing when to use it. It lacks explicit when-not-to-use statements but implies that subsequent tools like list_markets or find_markets are for actual market searches.

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 provided, the description carries full responsibility for transparency. It thoroughly discloses behavioral traits: the snapshot is best-effort and ~2 minutes delayed, not execution-grade; `has_more` is an upstream page hint and may be empty even when true; it explains the `resolving` status; warns that signal=arb is explicitly rejected; and details special behaviors for ladder markets and settlement risk. This goes far beyond a basic description.

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 long but well-structured. It starts with the core purpose, then moves to filtering, special market types, limitations, and alternatives. While every sentence adds value, the length could be slightly trimmed without losing clarity. The front-loading of the main action is good.

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 complexity of the tool (13 parameters, no schema descriptions, but with an output schema), the description is remarkably complete. It covers all major aspects: purpose, filters, special cases, limitations, and alternatives. With an output schema present, it need not enumerate return values, and it appropriately focuses on the behavioral and filtering details that the schema cannot convey.

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 input schema has 13 parameters with 0% description coverage, so the description must compensate. It does so effectively for most parameters: status values (open/live/resolving/closed/settled) are explained, signal values (spread/candidates/arb) are detailed, market_type values (including ladder types) are listed, and context filters (sport, competition, location, asset, indicator, institution) are mapped to categories. However, the `limit` and `basis` parameters receive minimal or indirect explanation (basis is mentioned only in output context), preventing a perfect score.

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 begins with a clear action and resource: 'List the matched, unified cross-venue catalog as canonical market objects.' It also distinguishes itself from the sibling `find_arbitrage` by stating that signal=arb is rejected and that tool should be used instead. This level of specificity and differentiation earns a top score.

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 when to use this tool versus alternatives. It states to use `list_categories` first to discover valid category/context values, and to call `find_arbitrage` for arbitrage signals. It also contrasts with `watch_markets` for real-time needs. These clear when-to and when-not-to instructions make it highly helpful for an agent.

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 mentions the HTTP method (POST) and that it's free to any active key. However, it does not disclose side effects, authentication requirements, or what the report triggers, leaving some behavioral traits unclear.

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 with no wasted words. The purpose is front-loaded, and each sentence adds essential information: action, key parameter guidance, endpoint reference, and access condition.

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 reporting tool with 5 optional parameters, the description covers the key usage aspects. It references the source of opp_id, the minimum inclusion rule, and the endpoint. The output schema exists, so return values are not needed. Slight gap on what happens after reporting, but overall adequate.

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%, so description must add value. It explains opp_id should come from find_arbitrage and that at least one parameter is required. However, it does not detail the purpose or expected format of reason, sport, market, or detail, leaving partial compensation.

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 flags bad arbitrage opportunities for operator review, with a specific verb ('Flag') and resource ('arbitrage opportunity'). It references the related tool find_arbitrage, but does not explicitly differentiate from siblings, though the purpose is distinct.

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?

Provides explicit guidance: pass opp_id from find_arbitrage and include at least one of listed parameters. Does not specify when to avoid using the tool or mention alternatives, but the context of sibling tools makes usage clear.

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: the ticket is short-lived (~120s), the tool does not hold the connection, tier restrictions on channels, locked channels are shown, and a lapsed key returns a 402 with upgrade URL. No annotations were provided, so the description carries full responsibility and does so thoroughly.

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 but contains all necessary information. It is front-loaded with the main action. While slightly dense, it remains concise and to the point.

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 no parameters and an output schema exists, the description covers all needed context: purpose, behavior, tier differences, error handling. It is complete for an AI agent to understand 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?

The input schema has no parameters, so the baseline score is 4. The description does not need to add parameter meaning, and it does not attempt to describe non-existent parameters.

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: 'Mint a short-lived (~120s) connect ticket for the real-time WebSocket market stream' and returns the URL and allowed channels. It distinguishes from sibling tools which are mainly for querying market data, not for real-time subscriptions.

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 context on when to use the tool (to get a WebSocket connection for real-time market data) and explains tier-based entitlements. However, it does not explicitly mention when not to use it or compare to alternatives.

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