Skip to main content
Glama
Sign In
Crypto News Sentiment (x402)

Crypto News Sentiment (x402)

by whatevercat-creator
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Current Crypto News Sentiment (paid)

get_sentiment

Returns live crypto news sentiment for one supported coin with a bullish/bearish/neutral label, -1 to 1 score, Fear & Greed value, and headlines. Costs $0.01 in USDC on Base per call.

Instructions

Crypto news sentiment for one coin right now: a bullish/bearish/neutral
label, a score from -1 to 1, sample sizes, the Fear & Greed value and up
to 5 headlines that moved the score. Paid: $0.01 in USDC on Base per
call, from this MCP server's own CDP wallet.

Use when an agent needs the current news mood for a crypto ticker.
Scores headlines from the last 72 hours across 9 crypto news RSS outlets,
newest weighted most. Each call fetches and scores the feeds live (no
cache), so repeat calls can differ as news arrives. For past readings
use get_sentiment_history; for the coins shifting most use get_movers.

symbol picks the coin and goes into the request path: one of the 24
uppercase tickers from list_supported_coins. Any other symbol is
rejected by the input schema, so nothing is charged. Too few recent
headlines: HTTP 422 "insufficient recent news", returned with charged:
false (get_archive_coverage shows coverage_7d_pct). 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"
  }
}

Input Schema

NameRequiredDescriptionDefault
symbolYesUppercase crypto ticker, one of the 24 from list_supported_coins (e.g. BTC). Stock tickers and other symbols are refused and not charged.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only flag openWorld/not-idempotent/non-destructive; the description goes well beyond them by disclosing the $0.01 USDC charge on Base from the server's own CDP wallet, that feeds are fetched and scored live with no cache (so repeat calls differ), the 72-hour window across 9 outlets with recency weighting, and the 422 'insufficient recent news' path that returns charged:false. It also covers the no-CDP-keys and spend-cap failure modes, which is exactly the pre-call context an agent needs for a paid, non-idempotent tool.

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 price and failure modes — a sensible order with no filler sentences. It is on the long side for a single-parameter tool and restates the 24-ticker enum already in the schema, which keeps it short of a 5.

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?

An output schema exists, so return values need not be re-explained, and the description still covers pricing, freshness/no-cache semantics, source corpus, error codes with billing consequences, and prerequisite credentials. For a paid, non-idempotent call with one enum param, nothing material is missing.

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, and the description earns a bump by explaining that symbol is interpolated into the request path and that a rejected symbol costs nothing because schema validation fires first. That charge-behavior detail is genuinely beyond the schema text, though the ticker list itself is repeated from the enum.

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?

The first sentence names the specific resource (crypto news sentiment for one coin) and its scope ('right now'), and enumerates what comes back: label, -1..1 score, sample sizes, Fear & Greed value, up to 5 headlines. It is immediately distinguishable from get_sentiment_history, which the description later names as the historical alternative.

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?

It states explicitly when to use it ('when an agent needs the current news mood for a crypto ticker') and routes two adjacent needs elsewhere by name: get_sentiment_history for past readings and get_movers for coins shifting most. No alternatives are left to inference.

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

Deploy Server

Other Tools