RCQ Data Oracle

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

With no annotations, the description carries the full disclosure burden and does well: it states that the tool is paid, that forward validation is active, and that it provides unproven market intelligence rather than individualized advice. It does not detail failure/error behavior or price, but directs users to rcq://catalog for availability and price.

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?

Four concise sentences front-load the use case and outputs, then add limitation and pricing-lookup context. No redundant restatement of the tool name or schema, and each sentence contributes.

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 single-parameter indicator with no output schema, the description specifies the expected outputs (score, state, multiplier), the paid workflow context, and the validation caveat. It could mention what happens without a valid payment signature or offer more return-format detail, but the core call context is covered.

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 the payment_signature parameter is already documented as an x402 payment authorization. The description adds the paid nature and price lookup but no parameter-specific detail beyond that, which matches the baseline 3 for full schema coverage.

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 identifies the tool as a paid, regime-aware BTC accumulation-intensity indicator and explicitly lists its outputs: a 0-9 score, a LIGHT/BASE/ACCELERATE/AGGRESSIVE state, and an intensity multiplier. It does not use a strong action verb, but the accumulation-intensity use case distinguishes it from sibling funding-regime and macro-risk tools.

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 gives a specific condition: use when a systematic accumulation workflow needs the score/state/multiplier. It does not explicitly mention alternatives or when not to use it, but the stated workflow is sufficiently specific to guide selection among the funding-regime and macro-risk siblings.

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 present, so the description carries the behavioral burden. It discloses that the tool is paid, compact/low-cost, returns summary regime data rather than the full surface, and is not validated directional alpha. It could go further on failure modes or rate limits, but for a read-only regime check the key cost and scope behaviors are covered.

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 front-load the core purpose, then cover usage, return contents, caveat, and catalog pointer with zero filler. Every sentence 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?

With no output schema, the description provides the needed return categories: regime state, normalized surface statistics, venue coverage, and freshness. It also covers cost/availability and names the exact venues. The output shape is somewhat unspecified, but the branch-on-state use case is clear enough for an agent to invoke 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 schema already documents the single optional payment_signature parameter at 100% coverage, including its x402 header purpose and min length, so the description adds no new parameter-level detail. The baseline of 3 applies because the schema does the heavy lifting.

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 uses a specific verb and resource: a 'compact BTC perpetual-funding regime read' across four named venues. It also distinguishes itself from the sibling 'full funding surface' by calling itself a low-cost branch-on-state check, so an agent can tell it apart immediately.

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 says 'Use as a low-cost branch-on-state check before requesting the full funding surface,' which names the alternative and the condition that selects it. It also gives a when-not by stating it is 'not validated directional alpha' and points to rcq://catalog for availability and price.

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 the full burden of behavioral disclosure. It discloses the paid nature, normalization, venue coverage, the rejected directional-alpha hypothesis, and the need to consult a catalog for current availability and price. It does not describe the return format, rate limits, or explicit payment-authentication flow, but the essential behavioral traits are 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?

Four sentences, each with a distinct purpose: resource definition, usage guidance, exclusion warning, and pointer to further details. No redundant phrasing, and the core 'what' is front-loaded in the first sentence.

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 tool with one optional parameter and no output schema, the description covers what the tool provides, when to use it, when not to use it, and where to get availability/price. The main gap is the absence of any indication of the return shape or data format, but that is partially mitigated by the clear purpose and the rcq://catalog pointer.

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% for the single parameter payment_signature, which the schema already explains as an x402 payment authorization for header-aware clients. The description adds no further parameter-specific guidance — it only mentions 'Paid' and points to the catalog for price, leaving the schema to do the heavy lifting.

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 identifies a specific resource — a 'BTC perpetual-funding surface' across Bitnomial, OKX, Hyperliquid and dYdX — and is further clarified by the usage list ('crowding, cross-venue dislocation, leverage-regime monitoring'). However, it lacks an explicit verb like 'fetches' or 'provides', and it does not directly contrast itself with the sibling tool btc_funding_regime, leaving a small ambiguity.

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 gives an explicit positive-use list ('Use for crowding, cross-venue dislocation, leverage-regime monitoring and arbitrage screening') and a clear when-not-to-use statement ('do not use this tool as a validated directional signal'). It also points the agent to rcq://catalog for availability and price, providing context for deciding whether the tool is actionable.

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 must carry behavioral disclosure on its own. It clearly warns the tool is 'Paid', directs the agent to read rcq://catalog for availability and price, and includes a non-advice disclaimer. This is materially more transparent than a bare 'Get BTC intel' description, though it does not specify failure behavior if payment is missing.

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 compact sentences: what it is, when to use it, and the caveat plus next step. Every sentence earns its place, the primary purpose is front-loaded, and there is no redundant or generic filler.

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 no output schema, the description compensates by listing the main data categories the agent can expect. It also covers the payment prerequisite and points to the catalog for operational details. It stops short of describing output shape or update frequency, but for a paid snapshot tool the described context is largely sufficient.

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 the baseline of 3 applies. The description reinforces the payment context by saying 'Paid' and pointing to the catalog, but it does not add practical guidance on how to construct or include the payment_signature beyond what the schema already declares.

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 names a specific deliverable ('BTC decision-context snapshot') and enumerates concrete content: directional bias, conviction, regime score, technical levels, and 72-hour on-chain transfer activity. This clearly distinguishes it from the more specialized siblings like btc_funding_regime or macro_event_risk, even without naming them.

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 opens with 'Use when an agent needs...' and lists the exact decision inputs this tool provides. It does not explicitly contrast itself with sibling tools or state when not to use it, but the when-to-use context is strong and actionable.

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?

Without annotations, the description carries the behavioral burden, and it does well: it states the tool is paid, that event proximity 'never changes the frozen core score,' and that it is descriptive rather than directional. It also tells the agent to check availability and price via rcq://catalog, which is important operational context for a paid 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 with zero filler. The paid status and primary use case are front-loaded, followed by behavioral disclaimers and the catalog pointer. Every sentence 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 single-optional-header tool with no output schema, this description covers purpose, usage context, non-mutating behavior, payment gatekeeping, and availability. The main gap is that it does not describe the shape or units of the returned macro-fragility/event context, but the catalog reference and explicit non-directional framing still make selection and invocation reasonably safe.

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% because the single payment_signature parameter is already documented in the schema. The description adds value beyond the schema by explaining that the tool is paid and directing the agent to rcq://catalog for current availability and price, which clarifies why the authorization header matters.

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 opens with a specific resource: 'Paid cross-asset macro-fragility and scheduled-event context.' It names concrete event types (BOJ, FOMC, CPI, NFP) and explicitly distinguishes itself from a directional BTC signal, which separates it from the sibling BTC-focused tools.

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 gives explicit when-to-use triggers: 'when evaluating risk exposure, carry-unwind conditions, or proximity to BOJ, FOMC, CPI and NFP events.' It also gives a when-not-to-use signal by saying it is 'not a directional BTC signal,' though it does not name a specific alternative tool as a replacement.

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 the full burden. It discloses that the tool is paid, requires a signature, is not self-serve, and points to the catalog for details, which covers access requirements. However, it does not describe the output format, side effects (e.g., read-only nature), or error behavior, leaving some behavioral ambiguity.

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 composed of four concise sentences, each delivering distinct information: what it is, when to use it, the access constraint, and where to find more details. It front-loads the purpose and avoids redundancy, with no filler or unnecessary technical jargon.

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 output schema, the description should clarify what the response contains. It mentions 'monthly performance series' but not the structure or format of the data, and doesn't describe pagination or any return envelope. It compensates somewhat by directing to the catalog for availability and price, but for a data-retrieval tool, more detail on the returned dataset would be expected.

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 sole parameter (payment_signature) is fully documented in the input schema with a detailed description ('x402 payment authorization for MCP 2026 header-aware clients'). The tool description adds no additional parameter guidance, but since schema coverage is 100%, the baseline score of 3 applies—the schema already provides the necessary meaning.

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 identifies the tool as a 'Paid signed RCQ BTC monthly performance series' for historical review, audit, and research, which clearly conveys its purpose. It differentiates from siblings by emphasizing the 'complete currently published monthly dataset' and noting that the separate access-key subscription applies only to monthly_series, though it doesn't name an alternative verb or resource explicitly. It is not tautological and provides a specific subject.

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 use cases ('historical review, audit and research workflows that require the complete currently published monthly dataset') and warns that access is not self-serve via MCP, directing users to rcq://catalog for availability and price. It lacks an explicit 'when not to use' or named alternative tool, but the guidance is clear enough to determine appropriate invocation.

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 the disclosure burden. It states the tool is free, returns only a filtered operational summary, and explicitly excludes paid market intelligence and internal infrastructure details. This gives useful boundary information beyond the tool name, though it does not detail response behavior or potential side effects, which is acceptable for a status endpoint.

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 two concise sentences with no filler. The most important information (free, operational check, use-before-paid-calls) is front-loaded, and the exclusionary details follow naturally without 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?

For a parameterless status check with no output schema, the description adequately explains what it returns and what it explicitly does not return. It could mention format or typical usage cadence, but the combination of purpose, trigger condition, and boundary information is sufficient for an agent to decide whether to use this 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 tool has zero parameters, so the schema is trivially complete and the description does not need to explain parameter meaning. The baseline of 4 applies here, and the description adds no parameter information because none 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 identifies the tool as a free operational status check for the RCQ Data Oracle and specifically says it confirms product availability and freshness. It also distinguishes itself from paid calls by stating it is not paid market intelligence or internal infrastructure details, which helps an agent tell it apart from the broader data tools.

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 advises using this tool before paid calls to check availability and freshness, giving a clear trigger condition. It does not enumerate alternative tools or exclusions, but the purpose is specific enough that the agent can infer when this is appropriate compared to the sibling tools.

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