Recent crypto headlines for narrative context and catalysts. Summarize in your own words with attribution to the reporting outlet; do not reproduce articles.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes | Recent headlines, newest first. Summaries are our own words, not article text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the baseline safety and idempotency are covered. The description adds value by revealing the output expectation (summarization with attribution) and the constraint on reproduction, which are behavioral traits beyond the 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 two sentences long and front-loaded with the core purpose. Every sentence adds essential information: the first states the purpose, the second states usage rules. No wasted 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?
The tool has no parameters and a rich annotations set. The description is complete for the tool's simplicity, covering purpose, usage guidelines, and output handling. An output schema exists, so the description does not need to detail return structure. Given the minimal complexity, the description is fully 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 description coverage is 100% with zero parameters, so the description does not need to document parameters. The description adds context about what the tool returns (headlines with narrative context and catalysts) and how the agent should use them, which is meaningful semantic guidance 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 specifies a verb ('get') and resource ('crypto headlines'). It distinguishes the tool from siblings by focusing on 'narrative context and catalysts,' which sets it apart from market data tools like get_crypto_market or on-chain tools like get_eth_address.
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 directs the agent to summarize in its own words and attribute to the reporting outlet, which is a concrete usage guideline. It also prohibits reproduction of articles, setting clear boundaries. This helps the agent use the tool appropriately and avoid copyright issues.
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 data domain—network health, market prices, news, DeFi, derivatives per-venue vs aggregate, economic calendar, ETH address, whale flows, execution cost, sentiment, implied volatility, macro rates, market brief, dominance, history, and traditional market quotes. The only similar pair (get_derivatives vs get_derivatives_aggregate) is clearly differentiated by level of detail, so there is no real ambiguity.
All tools follow the get_<domain> pattern with descriptive noun phrases (e.g., get_btc_network, get_eth_whale_flows, get_market_brief). No mixed verb styles or casing conventions appear, making the naming fully predictable and consistent.
At 17 tools, the surface is slightly above the ideal 3-15 range, but the breadth of the domain—spot, derivatives, on-chain, macro, sentiment, and execution—justifies each tool. It's borderline but each tool earns its place in a comprehensive market analysis agent.
The toolset covers nearly every major facet of crypto market analysis: prices, history, dominance, derivatives, on-chain activity, DeFi, macro, economic calendar, sentiment, implied volatility, execution cost, and a composite brief. Minor gaps like historical OHLCV or multi-chain on-chain analytics are not critical given the agent's stated focus.