Headless Oracle

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

No annotations provided, so description carries full burden. It discloses that the tool is not cryptographically signed, does not reflect real-time circuit breaker halts or KV overrides, and provides latency info (sub-100ms p95). Fail-closed behavior is explicitly stated.

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?

Description is comprehensive but well-structured with clear sections (WHEN TO USE, lunch breaks, return format, limitations). Every sentence adds useful information, though some redundancy could be trimmed without losing clarity.

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 tool complexity (28 exchanges, holiday awareness, lunch breaks, crypto), the description covers all necessary aspects: return fields, special cases (Middle East weekends, crypto), limitations, and fail-closed. No output schema but return format is described in detail.

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 single parameter mic, with a description listing it as 'ISO 10383 Market Identifier Code.' Description adds value by specifying default (XNYS) and pointing to list_exchanges for full list, but schema already covers semantics adequately.

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 returns 'holiday-aware trading session schedule with next open/close UTC timestamps for any of 28 exchanges.' It distinguishes itself from siblings by mentioning get_market_status for signed receipts and list_exchanges for available codes.

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?

Includes a dedicated 'WHEN TO USE' section listing specific scenarios (planning trade windows, checking holiday closures, scheduling tasks) and explicit exclusion: 'For authoritative signed status use get_market_status.' Also specifies fail-closed behavior if unreachable.

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: returns signed attestation with TTL, issuer, schema version, latency, and explains how to use signature for x402. 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?

Description is long but well-structured with sections for usage, safety, regulatory context, return format, and exchange list. Every sentence adds value, though some details could be split into dedicated documentation.

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 complexity (28 exchanges, cryptographic attestation, regulatory compliance, multiple usage contexts), the description covers all aspects: when to use, how to interpret, return fields, latency, and fail-safes. No output schema, but return format is fully described.

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?

Single 'mic' parameter has schema description coverage 100%, but description adds human-readable exchange names, examples, and refers to list_exchanges for discovery. This adds significant meaning beyond enum values.

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 it 'Returns Ed25519-signed market-state receipt for pre-trade verification'. The verb 'Returns' and resource 'market-state receipt' are specific. Distinguishes from siblings: not schedule, payment, or exchange listing.

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 BEFORE executing a trade, describes use as pre-trade safety check, and provides fail-closed rule for UNKNOWN/HALTED status. Also advises on handling unreachable 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, description carries full burden. States 'No authentication required' and 'Always returns 200', which are key behavioral traits. Also describes return structure (upgrade ladder). Could add more details about side effects, but as a read-only info tool, this is adequate.

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?

Description is well-structured with a clear purpose sentence, a 'WHEN TO USE' section, and a detailed list of return fields. It is appropriately concise for the complexity, though the return details could potentially be condensed. Still efficient and easy to parse.

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 simplicity (no parameters, no output schema), the description covers all necessary aspects: purpose, usage guidelines, return structure, authentication status, and error behavior (always 200). Sibling tools provide additional context for differentiation.

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?

Input schema has zero parameters with 100% schema description coverage (trivially). Baseline is 3, but the description provides meaningful context about what the tool returns and when to use it, which adds value beyond the empty schema. According to the rule for 0 params, baseline 4 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?

Description clearly states it returns payment and authentication options for live market data, using specific verb 'Returns' and resource 'payment and authentication options'. Differentiates from sibling tools which cover market schedule, status, and exchange lists.

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 includes 'WHEN TO USE' section guiding agents to use this tool when needing to understand authentication or payment before making a request. Does not provide explicit 'when not to use' but context is clear given distinct sibling purposes.

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 the description fully carries the burden. It discloses it returns static data, always returns 200, requires no authentication, and has sub-50ms p95 latency. It also details the return format and examples.

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 fairly long but well-structured with a WHEN TO USE section. Every sentence adds value, though the exhaustive list of examples could be seen as slightly verbose. It remains informative without being wasteful.

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 no parameters and no output schema, the description is highly complete. It explains return structure, number of entries, example values, performance, and use case. There is no missing critical information.

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?

There are zero parameters; the input schema is empty. Baseline for 0 params is 4. The description adds context about when to call and that it returns static data, but since there are no parameters, no further param info is needed.

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 returns a directory of all 28 exchanges with specific fields like MIC codes, names, timezones, etc. It distinguishes itself from siblings by stating it should be called once at startup before using get_market_status or get_market_schedule.

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 provides a WHEN TO USE section: 'call once at agent startup to discover supported markets before calling get_market_status or get_market_schedule.' Also mentions it is model-agnostic and compliant with SEC/CFTC attestation.

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