get_daily_brewThe day's machine-readable digest of the whole signal set — the CoinBucha Daily Brew. Takes no arguments. Returns { date, btc_price_usd, headline, signals_summary[] }, one summary line per signal with its strength, direction and one-line why. Example: {}. Information, not financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds valuable context by specifying the exact return structure (date, btc_price_usd, headline, signals_summary[]) and explaining each signal line. The disclaimer 'Information, not financial advice' also clarifies the tool's nature. No contradiction with annotations.
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 concise and front-loaded, immediately stating the tool's purpose. It includes a compact example of the return structure and a disclaimer, all within three sentences. Every sentence contributes to understanding, with no fluff or repetition.
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 fully specifies the response format and content, ensuring the agent knows what to expect. It also covers the tool's input (none), return fields, and a caveat. Combined with strong annotations for safety, the description is complete for this simple read-only 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, and the schema confirms this with 100% coverage. The description states 'Takes no arguments,' which is redundant but harmless. Per the baseline for 0 params, a score of 4 is appropriate since no parameter meaning needs to be added.
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 providing 'The day's machine-readable digest of the whole signal set,' distinguishing it from siblings that focus on individual signals. The verb 'returns' and specifics (date, btc_price, headline, signals_summary) make its purpose 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 implies use for a broad overview via 'whole signal set' and lists what the digest contains, but it does not explicitly state when to choose this over sibling tools like scan_signals or get_hiring_signal. No exclusions or alternative recommendations are provided, so guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct Bitcoin intelligence domain—ETF flows, hiring, hashrate, sovereign reserves, treasury holdings, daily digest, and cross-signal scan—with no functional overlap. Even similar-sounding holdings tools are clearly separated by nation-state vs. corporate focus.
Six of seven tools follow a consistent get_<domain> pattern, making them predictable and discoverable. The single outlier, scan_signals, breaks the pattern slightly but remains readable and within the same verb_noun style.
Seven tools is well-scoped for a Bitcoin signals server—broad enough to cover multiple indicator categories without bloat. Each tool serves a clear, non-redundant purpose.
The tool set covers the stated domain of leading non-price indicators comprehensively, including individual domain-specific queries and an aggregated, filterable scan. No obvious missing operations or dead-ends; the daily brew provides a digest while scan_signals offers detailed rankings.