Deduplicated crypto headlines from 37 RSS sources. Free preview; $0.0008/call via x402.
Scored across 2 tools
The two tools have clearly distinct roles: one counts new items since a cursor, while the other returns the latest free headlines. Their names and descriptions make it easy for an agent to choose between checking for newness and fetching a sample.
Both names use consistent snake_case and clearly describe crypto-news actions. The patterns differ slightly—one is verb-led (count_new...) and one is qualifier-led (latest...)—but they remain predictable and readable.
Two tools is thin for a crypto news server, even if both earn their place as free discovery utilities. The scope feels intentionally minimal, but it sits at the borderline of being under-tooled.
The surface only exposes a free count and the latest 5 headlines; the full feed with summaries, tickers, and cursor-based retrieval is described as an external paid endpoint rather than an MCP tool. That leaves a significant gap for agents that need actual full news content through the server.
Free: how many new items arrived since a cursor (next_since) for given topics/tickers, so an agent only pays for /v1/news when there is something new.
| Name | Required | Description | Default |
|---|---|---|---|
| since | Yes | ||
| topics | No | ||
| tickers | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the key behavioral traits: the call is free, it exists to avoid a paid endpoint, and 'since' is a cursor of the next_since form. It omits auth requirements, rate limits, and error behavior, which keeps it below a 5.
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 dense sentence with no waste; the cost rationale is front-loaded alongside the purpose so an agent can decide immediately.
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?
No output schema and no annotations, so the description must cover everything. It hints that a next_since cursor comes back and that the result is a count, but leaves response shape, parameter formats, and failure modes underspecified for a 3-parameter 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?
Schema coverage is 0%, so the description must compensate. It explains 'since' as a cursor (previously next_since) and identifies topics/tickers as filters, but gives no format guidance (comma-separated, repeated, casing) for any of the three 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?
States a specific verb-and-resource: counts new items arriving since a cursor for given topics/tickers. It also implicitly distinguishes itself from the sibling latest_crypto_headlines by being the cheap pre-check rather than the content fetch.
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 frames the use case: call this so an agent only pays for /v1/news when there is something new. That is a clear when-to-use signal, though it names /v1/news rather than the listed sibling latest_crypto_headlines, leaving the mapping to be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free: latest 5 crypto headlines (title, source, url, published_at, topics), optional topics filter. Full feed with summaries, tickers, since cursor: GET /v1/news via x402 ($0.0008 USDC on Base).
| Name | Required | Description | Default |
|---|---|---|---|
| topics | No | comma list, e.g. bitcoin,security |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden well: it discloses the fixed result limit of 5, the fields returned, the free tier, and the paid endpoint with cost and transport. It does not mention auth requirements or rate limits for the free endpoint, which is a minor gap.
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 front-loaded with the free tool operation and its returned fields, then adds paid-feed context. It is compact, though the paid endpoint details are somewhat tangential to invoking this specific free tool.
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 zero-required-parameter headline tool with no output schema, the description is largely complete: it states the count, returned fields, optional filter, and paid alternative. It could say more about access prerequisites or whether the free endpoint returns no cursor, but the core invocation 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 coverage is 100%, and the single topics parameter is already documented with an example in the schema. The description adds that the filter is optional and refers to 'topics,' but does not add syntax or matching semantics beyond what the schema provides.
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 resource and scope: latest 5 crypto headlines with listed fields and an optional topics filter. It distinguishes the free teaser from the paid full-feed endpoint, though it does not explicitly name the sibling count_new_crypto_news.
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 implies when to use this tool by framing it as the free way to get 5 latest headlines, and it mentions the paid full-feed alternative. However, it does not explicitly state when to choose count_new_crypto_news or provide clear exclusions beyond the free/paid split.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
count_new_crypto_newslatest_crypto_headlinesCrypto news, perps, market pulse, price history and token checks for AI agents. USDC per call.
Real-time curated crypto news for AI agents with sentiment, recaps, and search.
Multi-language crypto news with editorial sentiment + importance scoring; cites original publisher.
Hourly crypto news sentiment and typed market events, with sources on every signal.
Add one secure layer between your agents and this server.
