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

Crypto News Sentiment (x402)

by whatevercat-creator
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Crypto Sentiment API (x402)

Pay-per-call crypto sentiment API for AI agents. No API keys, no subscriptions — agents discover it, get an HTTP 402, pay in USDC on Base, and get the data.

Sentiment sources (all free, no keys required):

  • Crypto news RSS (9 outlets) — CoinDesk, Cointelegraph, Decrypt, Bitcoin Magazine, The Block, CryptoSlate, NewsBTC, CryptoPotato, The Defiant (DL News was removed on 2026-10-04: its feed served only April-May 2026 items)

  • Fear & Greed Index — alternative.me

Scoring: VADER sentiment analysis, extended with a crypto slang lexicon (moon, rekt, rug, hodl, bullish/bearish, etc.) so slang isn't scored as neutral. Each headline is matched and scored on its title plus its feed description with HTML tags, entities, feed footers and the outlet's own name removed (clean_text in app/sources/news.py; method 72h-hl24-v2 from 2026-10-21). Only headlines published in the last 72 hours count, and each headline's weight halves for every 24 hours of age (app/window.py). When the effective sample size is below 5, the label is insufficient recent news.

1. Get a Base wallet address

You need an address to receive USDC payments. Any standard Ethereum-style wallet works on Base (e.g. Coinbase Wallet, MetaMask configured for Base). You do not need to give this app your private key — only the public address, to receive funds.

Related MCP server: Web3 Signals — Crypto Signal Intelligence

2. Run it locally (testnet — free, no real money)

cd crypto-sentiment-x402
cp .env.example .env
# edit .env and set PAY_TO_ADDRESS to your wallet address
pip install -r requirements.txt
uvicorn app.main:app --reload

Visit http://localhost:8000 — you'll see the API description. Calling http://localhost:8000/sentiment/BTC without payment returns an HTTP 402 with payment instructions, exactly what an agent's x402 client would see and act on automatically.

To actually test a paid call, use the official x402 test client (needs Base Sepolia testnet USDC — free from the Base Sepolia faucet):

pip install x402
python -m x402.examples.client --url http://localhost:8000/sentiment/BTC

3. Deploy (simplest path: Render.com)

  1. Push this folder to a new GitHub repo.

  2. Go to render.com → New → Blueprint → connect the repo. Render will read render.yaml automatically.

  3. When prompted, set the PAY_TO_ADDRESS environment variable to your wallet address.

  4. Deploy. Render builds the Dockerfile and gives you a public HTTPS URL like https://crypto-sentiment-x402.onrender.com.

That's it — testnet mode is on by default, so nothing costs real money until you flip X402_NETWORK to mainnet (step 4 below).

4. Go live with real USDC payments

  1. Sign up for a free Coinbase Developer Platform account and create an API key — this is required for the mainnet facilitator (production-grade payment verification/settlement).

  2. In Render, set:

    • X402_NETWORK=mainnet

    • CDP_API_KEY_ID=...

    • CDP_API_KEY_SECRET=...

    • PAY_TO_ADDRESS = your mainnet Base address (double-check it's not a testnet-only address)

  3. Redeploy. Calls now settle real USDC on Base mainnet.

Start with a low price (X402_PRICE_USD, default $0.01) while you validate everything works end-to-end.

5. List it so AI agents can find and pay you

This is the x402 Bazaar — Coinbase's discovery layer, essentially a search engine for agents looking for x402 services.

  • If you're using the CDP facilitator (i.e. you're on mainnet per step 4), your service becomes automatically discoverable in the Bazaar once you process your first real payment through it — no separate signup.

  • To improve how well agents can find and understand it, keep the description field in app/main.py's RouteConfig clear and specific (already set) — that text is what shows up in Bazaar search results.

  • You can browse the current Bazaar listing yourself at https://api.cdp.coinbase.com/platform/v2/x402/discovery/resources (public, no key needed) to confirm your service appears after going live.

  • Optional extra distribution: submit your API to x402bazaar.org, a community-run directory of x402 services, separate from Coinbase's own Bazaar.

MCP server (Claude Desktop / Claude Code)

Prefer agents calling this over MCP instead of raw HTTP? mcp_server.py wraps the same API as MCP tools (crypto_sentiment, get_hourly_history and three free info tools) -- the server pays for each call from its own CDP-managed wallet, so callers never touch crypto directly. See MCP.md for setup.

Try it free

Three tools need no wallet, no CDP key and pay nothing. The server starts without any CDP variables, so you can install it and try these first:

  • list_supported_coins — the 24 supported ticker symbols and names.

  • archive_coverage — what the hourly archive holds (GET /archive): first reading, row counts and missing hours per symbol.

  • price_quote(symbol) — makes one unpaid request and reads the 402 payment requirements: price, network, asset and the payTo address.

Two tools are paid, from your own CDP wallet in USDC on Base:

  • crypto_sentiment(symbol) — the current reading, $0.01 per call. Unsupported coins and coins with too little recent news are refused and not charged.

  • get_hourly_history(symbol, start, end) — past hourly readings (GET /history/{symbol}), $0.05 per call. Recorded live and never backfilled; start/end are ISO 8601, default the last 7 days, at most 30 days per call. The symbol has to be one archive_coverage lists as logged. Unlogged symbols, invalid ranges and ranges with no readings are refused and not charged.

Wallet setup is in MCP.md.

Subscription tiers (Stripe, no crypto required)

Prefer a monthly bill over pay-per-call USDC? GET /v1/sentiment/{symbol} takes an X-API-Key header instead of an x402 payment, backed by Free / Starter ($15/mo) / Pro ($59/mo) tiers. See BILLING.md for setup, or GET /billing/pricing on a running instance for current pricing.

Sentiment-shift alerts

Watch a symbol and get pinged (webhook / Discord / Telegram) when its sentiment moves, instead of polling /sentiment yourself. Bundled into the Starter/Pro subscription tiers -- see ALERTS.md.

Historical dataset export

Sells access to the history of sentiment readings, not just the current one -- a background job takes one snapshot per symbol per day, and subscribers on the Pro or "Data Access" tier can export everything collected so far as CSV or JSON via GET /dataset/export. See DATASET.md (there's no backfilled history -- it only has data from whenever you turn the snapshot loop on).

Also on RapidAPI

Listed on the RapidAPI Hub for developers who'd rather discover and pay for it through RapidAPI's marketplace instead of Stripe or x402 directly. Same underlying data, served from GET /rapidapi/sentiment/{symbol} -- traffic is only accepted when it's routed through RapidAPI's proxy (validated via a shared secret header), so this endpoint isn't meant to be called directly. Plans there mirror the Stripe tiers: Free (100 req/mo), $15/mo (3,000 req), $59/mo (15,000 req).

Zapier & TradingView integrations

Route sentiment-shift alerts into Zapier (via the existing webhook channel -- no new endpoint needed) or enrich TradingView price alerts with live sentiment before relaying them to your webhook/Discord/ Telegram. See INTEGRATIONS.md.

API reference

Endpoint

Price

Description

GET /

Free

Service info

GET /health

Free

Health check

GET /sentiment/{symbol}

$0.01 (configurable)

Aggregate sentiment for a symbol, e.g. /sentiment/BTC

Example paid response:

{
  "symbol": "BTC",
  "name": "Bitcoin",
  "overall_sentiment": {
    "sample_size": 42,
    "average_compound": 0.21,
    "label": "bullish",
    "positive_pct": 55.0,
    "negative_pct": 15.0,
    "neutral_pct": 30.0,
    "unweighted_compound_72h": 0.17,
    "effective_sample_size": 31.4,
    "newest_headline_age_hours": 1.6,
    "window": "72h-hl24-v2"
  },
  "drivers": [{ "title": "...", "source": "CoinDesk", "link": "https://...", "published": "...", "score": 0.62, "weight": 0.93, "effect": 0.03 }],
  "drivers_summary": "3 of the top 5 headlines are positive, 2 are negative.",
  "breakdown": {
    "news": { "...": "..." },
    "fear_greed_index": { "value": 62, "classification": "Greed" }
  },
  "sources": ["coindesk.com RSS", "..."]
}

Notes and limitations

  • Reddit was removed as a source: Reddit's Responsible Builder Policy prohibits commercial use of their data without written approval, which this paid API would violate. app/sources/reddit.py is left in the repo unused in case that changes in the future.

  • Coin coverage: app/coins.py has a starter list of ~15 symbols. Add more as needed — unmapped symbols still work, just with slightly less accurate news matching (falls back to matching on the symbol itself).

  • Only supports the exact payment scheme on Base/EVM. The x402 SDK also supports Solana (ExactSvmServerScheme) if you want to accept SOL-based USDC too — see the commented-out import in app/main.py's dependencies.

  • Add more paid endpoints (e.g. historical sentiment, multi-symbol batch queries) by adding entries to the routes dict in app/main.py.

Available Tools

5 tools
archive_coverageArchive CoverageA
Read-onlyIdempotent
Free: what the hourly sentiment archive holds (GET /archive). No wallet
needed.

Per symbol: first and latest reading, row counts, missing hours, and
coverage_7d_pct, the share of the last 7 days' logged hours that had at
least one matching headline (with hours_with_headlines_7d and
hours_logged_7d). Check it before get_hourly_history to pick a symbol and
range with data: low-coverage coins often get no_headlines_in_range from
get_hourly_history or "insufficient recent news" from crypto_sentiment,
both refused and not charged.
NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the read-only annotations, it discloses that the call is free, needs no wallet, and that downstream failures are 'refused and not charged'. These are meaningful auth, cost, and error-behavior details that annotations do not provide.

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

Conciseness5/5

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

The description is two short paragraphs with no filler. It front-loads the free/no-wallet constraint and then immediately explains what the coverage report contains and why to call it.

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?

Given zero parameters, rich annotations, and an existing output schema, the description supplies everything else an agent needs: cost, required access, output metrics, and the recommended call ordering relative to get_hourly_history and crypto_sentiment.

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?

The tool has zero input parameters, so there is no parameter semantics to explain. The description does add output-field meaning such as coverage_7d_pct, but the baseline for a zero-parameter tool is 4.

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 description states a specific resource and operation: 'what the hourly sentiment archive holds (GET /archive)'. It also distinguishes the tool from siblings by positioning it as a coverage check before get_hourly_history.

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 gives explicit usage guidance: 'Check it before get_hourly_history to pick a symbol and range with data'. It also explains the consequences of skipping this check, naming no_headlines_in_range from get_hourly_history and 'insufficient recent news' from crypto_sentiment.

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

crypto_sentimentCurrent Crypto SentimentA
Current news sentiment for one crypto ticker. Paid: $0.01 in USDC on Base
per call, from this MCP server's own CDP wallet.

symbol must be exactly one of the 24 uppercase tickers from
list_supported_coins (e.g. BTC). Lowercase ("btc") or any other symbol is
rejected by the input schema before a request is sent, so nothing is
charged.

Scores headlines from the last 72 hours across 9 crypto news RSS outlets
(VADER plus a crypto slang lexicon, weighted toward the newest) alongside
the Fear & Greed Index. Returns a bullish/bearish/neutral label, a
compound score (-1 to 1), sample sizes, the news and Fear & Greed values,
and up to 5 headlines that moved the score.

Low-coverage coins: when recent headlines are too few (effective sample
size below 5), the API refuses with HTTP 422 "insufficient recent news",
returned here as an error with charged: false. archive_coverage shows each
coin's coverage_7d_pct. Without CDP keys the tool returns a no-wallet
message and pays nothing. For past readings use get_hourly_history.
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

NameRequiredDescription

No output parameters

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say openWorldHint=true and readOnlyHint=false; the description supplies the crucial missing context: a $0.01 USDC charge per call from the server's own CDP wallet, no charge on schema rejection, charged:false on the HTTP 422 low-coverage path, and a no-wallet fallback that pays nothing. It also discloses the scoring method and the return payload shape, which annotations cannot convey.

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?

Purpose and cost are front-loaded, followed by input constraints, then output, then failure modes — a logical progression with no filler sentences. It runs long for a single-parameter tool, but nearly every clause carries distinct operational information.

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 payment, input validation, output fields, the low-coverage 422 failure with charged:false, the no-wallet path, and a pointer to archive_coverage for pre-checking coverage. Even though an output schema exists, the description still explains what the label and compound score mean, leaving no gap an agent would need to guess at.

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% with a full enum, so the baseline is 3. The description adds real meaning beyond the schema: the uppercase-only requirement is tied to a concrete consequence (rejected before a request is sent, nothing charged), which changes how an agent validates input rather than merely restating 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?

States a specific verb and resource — 'Current news sentiment for one crypto ticker' — and immediately scopes it to 72 hours of headlines plus Fear & Greed. It is clearly distinguishable from get_hourly_history (past readings) and list_supported_coins (ticker enumeration), which are both named.

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?

Explicitly routes the agent: use list_supported_coins to obtain a valid ticker, and use get_hourly_history for past readings. The rejection condition (lowercase or non-listed symbol) is stated with its consequence, so the agent knows exactly what input is acceptable before calling.

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

get_hourly_historyHourly Sentiment HistoryA
Past hourly sentiment readings for one coin, oldest first. Paid: $0.05 in
USDC on Base per call, from this MCP server's own CDP wallet.

Range: omit both bounds 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. The span can be at most 30 days,
so split longer periods into several calls. Readings are recorded live at
the top of each UTC hour and never backfilled; a missed hour stays missing.

Refused and not charged (returned as an error with charged: false):
- 400: malformed symbol or time, start not before end, or a span over 30 days.
- 404: symbol not in the archive.
- 404 no_readings_in_range: no readings in the range (gives first_reading).
- 404 no_headlines_in_range: every hour in the range had zero matching
  headlines (gives rows_in_range and coverage_7d_pct).
A range with at least one hour of headlines returns all its rows.

For low-coverage coins, check archive_coverage first: its coverage_7d_pct
and first_reading show where data exists. Without CDP keys the tool returns
a no-wallet message and pays nothing. For the current reading use
crypto_sentiment.
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. archive_coverage lists the logged symbols.

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.9/5.0
Behavior5/5

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

The description adds substantial context beyond annotations: cost of $0.05 USDC per call, wallet requirements, charging behavior on refused requests, live-only recording with no backfill, and the exact 404 cases. These details are essential for a paid external-data tool and are not contradicted by 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.

Conciseness5/5

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

The description is front-loaded with the purpose, then gives range rules, error behavior, and alternatives in a scannable order. Despite being detailed, every section earns its place for a paid historical-data tool.

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?

Given the rich schema, annotations, and output schema, the description supplies the remaining operational context an agent needs: payment model, wallet dependency, range limits, non-backfilled data, and refusal semantics. 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 schema already documents the parameters well. The description still adds useful range semantics: omitting both bounds means the last 7 days, only end backfills 7 days, only start runs to now, and inclusion is start <= observed_at < end.

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 description states a specific verb and resource: retrieving past hourly sentiment readings for one coin, oldest first. It also distinguishes this historical tool from the sibling crypto_sentiment, which is explicitly described as the tool for the current reading.

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 gives explicit range behavior for omitting both bounds, providing only end, or providing only start, plus the 30-day maximum and the instruction to split longer periods. It also names when to use archive_coverage for low-coverage coins and crypto_sentiment for current readings.

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

list_supported_coinsList Supported CoinsA
Read-onlyIdempotent
Free: list the 24 ticker symbols crypto_sentiment supports, with names.

Useful before choosing a symbol for crypto_sentiment or price_quote.
No wallet needed and no network call. Any other symbol is rejected by
those tools' input schema before a request is sent, so nothing is
charged.
NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely non-obvious context beyond that: no wallet needed, no network call, and therefore nothing charged. It stops short of saying whether the list is static or can change, which would be the last useful detail.

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

Conciseness5/5

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

Three short sentences: what it returns, when to use it, and the cost/validation guarantee. The "Free:" lead is front-loaded and every sentence carries information not available elsewhere.

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 described, and "with names" still hints at shape. For a zero-parameter, side-effect-free lookup, the description covers purpose, routing, and cost implications completely.

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?

The tool takes zero parameters, so there is nothing to disambiguate and the baseline is 4. The description correctly spends no words on arguments.

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 — list the 24 ticker symbols supported by crypto_sentiment — and even quantifies the result size. It is immediately distinguishable from siblings like crypto_sentiment and price_quote, which consume symbols rather than enumerate them.

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?

"Useful before choosing a symbol for crypto_sentiment or price_quote" names the exact downstream tools and the decision point that triggers this call. It also explains what happens with an unsupported symbol (rejected by those tools' input schema before a request is sent), closing the obvious follow-up question.

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

price_quotePrice QuoteA
Read-onlyIdempotent
Free: the live x402 price of one crypto_sentiment call, read from an
unpaid request's 402 response. Nothing is signed; no wallet needed.

When not to use it: prices are fixed at $0.01 per crypto_sentiment call
and $0.05 per get_hourly_history call, so there's no need to call this
before every paid call. Use it to confirm the live price and payment
requirements, e.g. before funding a wallet. It quotes crypto_sentiment
only.

symbol must be exactly one of the 24 uppercase tickers from
list_supported_coins; lowercase or any other symbol is rejected by the
input schema before a request is sent. A low-coverage coin still gets a
quote; a crypto_sentiment call for it may then be refused with
"insufficient recent news" (not charged).
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

NameRequiredDescription

No output parameters

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds meaningful context beyond those annotations: nothing is signed, no wallet is needed, quotes are free, low-coverage coins still get a quote, and a subsequent crypto_sentiment call may be refused without charge. These are exactly the behavioral details an agent needs for a price-probing tool.

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

Conciseness5/5

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

The description is front-loaded with the core purpose, immediately followed by exclusions, usage guidance, and validation caveats. Every sentence contributes operational information, and there is no filler or repetition.

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?

Given that an output schema exists, the description does not need to explain return values. It still covers the important complexities of this tool: free access, no signing, fixed pricing rationale, symbol validation, and low-coverage refusal behavior. The definition is complete for correct invocation.

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 enum already lists the 24 valid uppercase tickers. The description still adds value by stating that lowercase symbols are rejected by the input schema before a request is sent, that quotes come from list_supported_coins, and that low-coverage coins may still be quoted even if a later call is refused. This goes beyond the schema without fully redefining the parameter.

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 description states a specific verb and resource: it returns the live x402 price of one crypto_sentiment call from an unpaid 402 response. It also explicitly limits scope to crypto_sentiment and rules out wallet signing, making it clearly distinguishable from sibling tools like crypto_sentiment and get_hourly_history.

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 gives explicit when-not-to-use guidance ('no need to call this before every paid call') and when-to-use guidance ('use it to confirm the live price and payment requirements, e.g. before funding a wallet'). It also names list_supported_coins as the source of valid tickers, leaving little ambiguity.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.1.6
    • Changedget_hourly_history1 field changed
      • addedInput schema / properties / symbol / description
        Added value: +"Crypto ticker, e.g. BTC; uppercased and trimmed before the request. archive_coverage lists the logged symbols."
  2. 3 tool updatesv0.1.4
    • Changedcrypto_sentiment2 fields changed
      • addedInput schema / properties / symbol / description
        Added value: +"Uppercase crypto ticker, one of the 24 from list_supported_coins (e.g. BTC). Stock tickers and other symbols are refused and not charged."
      • addedInput schema / properties / symbol / enum
        Added value: +[
+  "BTC",
+  "ETH",
+  "SOL",
+  "XRP",
+  "DOGE",
+  "ADA",
+  "AVAX",
+  "LINK",
+  "MATIC",
+  "DOT",
+  "SHIB",
+  "LTC",
+  "BNB",
+  "USDC",
+  "USDT",
+  "NEAR",
+  "HYPE",
+  "QNT",
+  "AAVE",
+  "TAO",
+  "PEPE",
+  "PUMP",
+  "ENA",
+  "STRK"
+]
    • Addedget_hourly_history
    • Changedprice_quote2 fields changed
      • addedInput schema / properties / symbol / description
        Added value: +"Uppercase crypto ticker, one of the 24 from list_supported_coins (e.g. BTC). Stock tickers and other symbols are refused and not charged."
      • addedInput schema / properties / symbol / enum
        Added value: +[
+  "BTC",
+  "ETH",
+  "SOL",
+  "XRP",
+  "DOGE",
+  "ADA",
+  "AVAX",
+  "LINK",
+  "MATIC",
+  "DOT",
+  "SHIB",
+  "LTC",
+  "BNB",
+  "USDC",
+  "USDT",
+  "NEAR",
+  "HYPE",
+  "QNT",
+  "AAVE",
+  "TAO",
+  "PEPE",
+  "PUMP",
+  "ENA",
+  "STRK"
+]
  3. 4 tool updatesv0.1.2
    • First observedarchive_coverage
    • First observedcrypto_sentiment
    • First observedlist_supported_coins
    • First observedprice_quote
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.6/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a clearly distinct role: current sentiment, historical readings, supported ticker listing, archive metadata, and live price quoting. The descriptions explicitly clarify boundaries, especially between crypto_sentiment and get_hourly_history and between archive_coverage and list_supported_coins.

Naming Consistency3/5

The set mixes verb_noun names like get_hourly_history and list_supported_coins with noun-only or noun_noun names like crypto_sentiment, archive_coverage, and price_quote. It remains readable, but there is no single predictable pattern across all five tools.

Tool Count5/5

Five tools is well-scoped for a focused sentiment API: one paid current-reading tool, one paid history tool, and three lightweight supporting tools. Each tool earns its place without obvious redundancy.

Completeness4/5

The surface covers the core lifecycle well: discover supported coins, check archive coverage, fetch current sentiment, fetch historical readings, and confirm pricing. Minor gaps exist, such as price_quote covering only crypto_sentiment and no dedicated Fear & Greed or raw-headline lookup, but these are workable around and not central to the domain.

Maintenance

ActivityActive
ResponsivenessLimited data

Resources

Related MCP Connectors

Related MCP Servers

  • Fear & Greed Index MCP Server

    ycjcl868
    A
    license
    A
    quality
    D
    maintenance
    A Model Context Protocol server that provides real-time CNN Fear & Greed Index data for the US stock market, including current sentiment scores and historical comparisons.
    1
    45 npm
    4
    MIT

  • Web3 Signals — Crypto Signal

    manavaga
    A
    license
    Not graded
    quality
    D
    maintenance
    AI-powered crypto signal intelligence for 20 assets (BTC, ETH, SOL, etc). 6 scoring dimensions: whale activity, technical analysis, derivatives flow, narrative strength, sentiment, market structure. Market regime detection (TRENDING/RANGING), portfolio optimization, and accuracy tracking. 9 read-only MCP tools. Free via MCP, $0.001 USDC via x402 on Base for REST API.
    3
    MIT

  • crypto-news

    Br0ski777
    A
    license
    Not graded
    quality
    D
    maintenance
    Real-time crypto news aggregation with sentiment scores and token mentions, enabling market analysis and trading signals via pay-per-call micropayments.
    MIT