Crypto News Sentiment (x402)

Biggest 24h Crypto Sentiment Movers (paid)

get_movers

Track which coins' news sentiment rose or fell over the past ~24 hours in one call, ranking supported coins by change instead of querying each individually.

Instructions

Crypto sentiment movers: the coins whose news sentiment rose or fell the
most over the last ~24 hours, ranked across all 24 supported coins in one
call. Paid: $0.02 in USDC on Base per call, from this MCP server's own
CDP wallet.

Use when an agent wants to know which coins' news mood is shifting
without calling get_sentiment for every coin. Compares each coin's
current reading (refreshed at most hourly; computed_at says when) with
its archived reading closest to 24 hours earlier. Returns movers_up
(rises, largest first) and movers_down (falls, largest first) with each
coin's current score, previous score and delta.

limit is sent as the ?limit= query parameter and caps movers_up and
movers_down each; omit it for 10. Coins without enough recent news, now
or ~24 hours ago, are left out. A call that can rank no coin is refused
with HTTP 422, returned as an error with charged: false. Without CDP
keys or past the session spend cap, it pays nothing and says why.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_movers"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	Max coins in movers_up and in movers_down, 1 to 24, e.g. 5. Omit for the API's default of 10.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.2.0Nov 10, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Discloses cost and payment rail ($0.02 USDC on Base per call from the server's CDP wallet), data freshness (refreshed at most hourly, computed_at tells when), comparison basis (archived reading closest to 24h earlier), exclusion rules for thin-news coins, HTTP 422 refusal with charged: false, and no-charge behavior without CDP keys or past the spend cap. These are substantive details the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false) do not convey, and the metered billing is consistent with the non-readOnly hint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with what the tool returns, then usage, then mechanics, with no filler sentences. The final paragraph bundles limit semantics, exclusion rules, and billing errors together, which is slightly dense, but every element carries information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the full surface for a metered read tool: purpose, freshness, return shape (movers_up/movers_down with current score, previous score, delta), defaults, omission behavior, and both refusal modes. An output schema exists, yet the description adds the ordering and field semantics needed to interpret results without opening it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already documents limit's range and default, so the baseline is 3. The description adds real meaning beyond that: limit caps movers_up and movers_down each and is transmitted as the ?limit= query parameter, clarifying that the cap applies per list rather than to combined results.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource and computation: coins whose news sentiment rose or fell most over ~24 hours, ranked across all 24 supported coins in one call. It explicitly distinguishes itself from get_sentiment by noting it avoids calling that tool once per coin.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger ("Use when an agent wants to know which coins' news mood is shifting without calling get_sentiment for every coin"), naming the alternative and the condition that selects this tool over it. The paid-call caveat further scopes when it is worth invoking.

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

Deploy Server