bitcoin-signals

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 only says 'machine-readable signal digest' without disclosing side effects, idempotency, rate limits, or authentication needs. A read operation is implied but not 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?

The description is a single sentence with no wasted words. It is perfectly concise and front-loaded with the key 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?

With no annotations, no output schema, and zero parameters, the description is minimal. It tells the agent what the tool returns (today's digest) but not in what format (e.g., JSON). For a simple retrieval tool, it is adequate but could be more precise about 'machine-readable' structure.

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 and 100% schema description coverage, so the baseline is 4. The description adds no extra parameter info because none is needed. It correctly implies no inputs are required.

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 retrieves 'Today's machine-readable signal digest' (the CoinBucha Daily Brew). It uses a specific verb ('get') and resource ('daily brew'), and distinguishes itself from sibling tools that target individual signals like get_etf_flows or get_hiring_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 implies the tool is for retrieving the daily digest, but it does not explicitly state when to use this tool versus alternatives like scan_signals or other specific signal tools. No guidance on when not to use or prerequisites.

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 full behavioral disclosure burden. It states the output (net flows for latest day, trailing 5/30-day) but does not explicitly confirm read-only nature, data freshness, or potential errors. For a simple 0-parameter tool, the lack of side-effect disclosure is acceptable but not exemplary.

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, front-loaded sentence with no wasted words. It conveys the essential information (what, time period, context) in 9 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?

Given the tool's simplicity (0 params, no output schema), the description covers the key aspects: data type, time periods, and context. It lacks mention of data source or update frequency, but these are not critical for a basic retrieval tool. The sibling tool list provides sufficient 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 description coverage is 100% with 0 parameters, so baseline is 4 per rule. The description adds no parameter-level detail, but none is needed since there are no 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 uses a specific verb ('get') and resource ('Spot Bitcoin ETF net flows') and clearly distinguishes from sibling tools by specifying the data type (ETF flows) and context (institutional demand). The sibling tools cover other signals, so this tool's domain is unique.

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?

No explicit guidance on when to use this tool vs alternatives. The description implies usage for Bitcoin ETF flow data, but lacks statements like 'use for institutional demand trends' or 'do not use for retail flow data'. The context signals (sibling tools) provide implicit differentiation.

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 exist, so the description must bear full behavioral transparency. It only mentions data source ('live ATS boards') but fails to disclose traits like read-only nature, permissions needed, rate limits, or whether data is historical or real-time. This is minimal.

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?

A single sentence of ~15 words conveys the tool's purpose and data source efficiently. It is front-loaded with the key concept and contains no extraneous 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?

For a simple read-only tool with one optional parameter and no output schema, the description covers the core functionality and data source. Minor omission: it could specify the geographic scope (global) but the company filter mitigates this gap.

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?

With 100% schema description coverage, the parameter 'company' is already documented in the schema. The description does not add any further meaning, 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?

The description clearly states it provides Bitcoin/crypto-infra hiring velocity with open roles and 30/90-day deltas from live ATS boards. The verb 'get' and resource 'hiring signal' are specific, and the tool is well-differentiated from sibling tools (e.g., get_etf_flows, get_network_signal) which cover different financial metrics.

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 implies the tool is for obtaining crypto hiring data but does not provide explicit guidance on when to use it versus alternatives or when not to use it. No exclusions or context triggers are given.

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; description only states what data is returned but does not disclose behavioral traits like read-only nature, authentication requirements, or side effects. Without annotations, description carries full burden but falls short.

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?

Single sentence that is front-loaded with key information. No wasted words; every part serves a 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?

Given no parameters, no output schema, and no annotations, the description provides the core information (hashrate level and trend) with useful context (miner conviction/security). Could include more about output format or update frequency, but it is adequate for a simple 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?

Tool has zero parameters, and schema coverage is 100%. Per guidelines, baseline for 0 params is 4. Description adds no parameter info, but 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?

Clearly states it provides Bitcoin network hashrate level and 30/90-day trend, distinguishing it from sibling tools like get_daily_brew or get_etf_flows. However, it could be more explicit about returning data (e.g., 'Returns...').

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?

No explicit guidance on when to use this tool versus alternatives. The mention of 'miner conviction / security' hints at use cases but doesn't provide clear when/when-not usage.

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. Description does not disclose whether it is read-only, requires authentication, has rate limits, or any side effects. Basic operation is implied but not 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?

Single sentence that is clear and front-loaded with the core purpose ('Sovereign Bitcoin holdings, ranked'). No redundant 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?

Provides basic purpose and filtering options, but lacks details on default behavior (e.g., what if no filter?), ranking criteria, and response format. No output schema, so description should elaborate more.

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?

Description adds meaning for 'tier' by explaining '1 = largest holders', which is not in the schema. For 'country', the schema already provides description. Schema coverage is 50%, description compensates partially.

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 sovereign Bitcoin holdings in a ranked list, with filtering by country or tier. Distinguishes from sibling 'get_treasury_holdings' which likely focuses on corporate entities.

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?

Implies usage for fetching and filtering sovereign reserves, but lacks explicit guidance on when to use this tool versus alternatives (e.g., get_treasury_holdings) or when not to use it.

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 should compensate. It only states the output (total BTC and top holders) without disclosing behavioral traits such as data freshness, authentication needs, rate limits, or retry behavior. Minimal transparency beyond the return value.

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 extremely concise (one short sentence) and front-loads the purpose. No wasted words; every part 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?

Given zero parameters and no output schema, the description is adequate but has gaps. It does not describe the structure of the response (e.g., whether 'top holders' includes names or just totals) or how the data is sourced. Could be improved for a more complete picture.

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?

With zero parameters and 100% schema coverage, the description adds no parameter-level detail because none is needed. Baseline 4 applies, and the description is sufficient for a parameterless tool.

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 specifies the resource (corporate Bitcoin treasury holdings) and the action (retrieve total BTC held by public companies and top holders). It distinguishes from siblings by focusing on a specific niche (corporate Bitcoin holdings) vs other financial 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?

No guidance is provided on when to use this tool versus alternatives like get_sovereign_reserves or get_network_signal. The description only states what it returns, not the context for its use.

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 full behavioral burden. It does not disclose traits like pagination, ranking criteria, rate limits, or read-only vs. destructive nature. For a tool that returns a ranked feed, this omission is significant.

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 with no unnecessary words. It front-loads the core purpose and filtering capabilities, earning its place efficiently.

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 output schema and no annotations, the description lacks details on return format, ranking behavior, and pagination. For a feed tool, this information would enhance completeness, but the description minimally covers the essential filtering capability.

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 67% (2 of 3 parameters described). The description adds the concept of filtering by the three parameters but does not elaborate on formats or constraints beyond what the schema provides. For direction, it doesn't mention the enum values, so value is modest.

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 provides a ranked composite feed of Bitcoin signals and explicitly mentions filtering by strength, direction, or type. This distinguishes it from sibling tools like get_hiring_signal and get_network_signal, which focus on individual 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 implies usage when a filtered, aggregated view of Bitcoin signals is needed. It does not provide explicit when-not-to-use guidance or alternatives, but the context of sibling tools helps differentiate. The guidance is clear but lacks exclusions.

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