Skip to main content
Glama
Crypto News Sentiment (x402)

Crypto News Sentiment (x402)

Hourly Crypto Sentiment History (paid)

get_sentiment_history

Retrieves hourly historical crypto news sentiment for a coin over a chosen time range, including scores, sample sizes, Fear & Greed, and top headlines, for aligning sentiment with price.

Instructions

Historical crypto news sentiment for one coin: hourly readings (score,
sample size, Fear & Greed and the top headlines for each hour), oldest
first. Paid: $0.05 in USDC on Base per call, from this MCP server's own
CDP wallet.

Use when an agent needs how a coin's news sentiment moved over past hours
or days, e.g. to line it up with price. For the current reading use
get_sentiment.

symbol goes into the request path (/history/{symbol}) and start/end are
sent as query parameters, so together they pick one coin and one time
range. Omit both for the 7 days up to now; with only end the range starts
7 days before it, with only start it runs to now. A reading is included
when start <= observed_at < end; at most 30 days per call. Readings are
recorded live at the top of each UTC hour and never backfilled.

Refused and not charged (an error with charged: false): 400 for a
malformed symbol or time, start not before end, or over 30 days; 404 for
a symbol not in the archive, no_readings_in_range (gives first_reading)
or no_headlines_in_range (no hour had headlines). For low-coverage coins,
check get_archive_coverage first. Without CDP keys or past the session
spend cap, it pays nothing and says why.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "symbol": "<symbol>"
    },
    "name": "get_sentiment_history"
  }
}

Input Schema

NameRequiredDescriptionDefault
endNoISO 8601 timestamp, e.g. 2026-10-13T00:00:00Z (UTC if no offset). start defaults to end minus 7 days; end is exclusive and defaults to now. At most 30 days per call.
startNoISO 8601 timestamp, e.g. 2026-10-13T00:00:00Z (UTC if no offset). start defaults to end minus 7 days; end is exclusive and defaults to now. At most 30 days per call.
symbolYesCrypto ticker, e.g. BTC; uppercased and trimmed before the request. get_archive_coverage lists the logged symbols.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.0

TDQS

A4.6/5.0
Behavior4/5

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

Goes well beyond the annotations: it discloses the price ($0.05 USDC on Base per call), the CDP wallet that pays, the refusal cases that are not charged (400/404 with reason codes), the 30-day cap, and the recording cadence ("recorded live at the top of each UTC hour and never backfilled"). This also explains why readOnlyHint is false despite a read-like operation, so there is no contradiction. The gaps are minor, such as whether payment settles per attempt or per success beyond the stated charged:false behavior.

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 purpose, then usage, then parameter composition, then failure modes, so a reader can stop early. The error paragraph is dense but each clause (status code, reason, charged flag) carries decision-relevant information, and trimming is arguably the only improvement.

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 everything that is needed to call it correctly: pricing and authorization failure modes, time-range defaults and boundaries, the per-call cap, the hourly granularity, how errors are reported, and where to look for data availability. Return shape is largely covered by the output schema, so the description does not need to repeat 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%, so the baseline is 3, but the description adds real meaning the schema does not: the start-only case ("with only start it runs to now") and the half-open inclusion rule ("start <= observed_at < end"), plus how symbol, start, and end compose to pick one coin and one range. It does not repeat ISO formatting or capitalization rules already documented in the schema.

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 verb and resource: "Historical crypto news sentiment for one coin: hourly readings (score, sample size, Fear & Greed and the top headlines for each hour), oldest first." It also explicitly separates itself from the sibling that returns the live value ("For the current reading use get_sentiment").

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 when-to-use ("needs how a coin's news sentiment moved over past hours or days, e.g. to line it up with price"), names the alternative for the current reading, and adds a prerequisite check for thin data ("For low-coverage coins, check get_archive_coverage first").

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