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

Crypto News Sentiment (x402)

by whatevercat-creator
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Crypto Market Sentiment Index (free)

get_market_sentiment
Read-onlyIdempotent

Retrieve an overall crypto market news sentiment score and bullish, bearish, or neutral label aggregated across supported coins, so agents can gauge the market mood rather than one coin.

Instructions

Crypto market sentiment index: one news-sentiment score and
bullish/bearish/neutral label for the whole crypto market, aggregated
from the 24 supported coins and weighted by how much recent news each
has, with the contributing coins listed. Free: no wallet needed.

Use when an agent needs the overall crypto news mood rather than one
coin's; use get_sentiment for a single coin and get_movers for which
coins are shifting. Refreshed at most hourly: cached, computed_at and
next_refresh_at in the response say how fresh it is, and a call before
next_refresh_at returns the same index.

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_market_sentiment"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already cover readOnly, idempotent, openWorld, and non-destructive, so the description does not need to restate safety. Instead it adds substantive behavior the annotations cannot convey: hourly refresh ceiling, caching semantics, that a call before next_refresh_at returns the identical index, that computed_at/next_refresh_at report freshness, and that no wallet is required.

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?

Front-loaded with the core definition, then usage routing, then freshness/caching. The first sentence is dense but every clause carries information an agent needs; the second paragraph adds only decision-relevant guidance and cost/freshness facts. No filler.

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 structure does not need spelling out, yet the description still names the key response fields (computed_at, next_refresh_at, contributing coins). For a parameterless, free, read-only index tool, nothing an agent needs in order to call it correctly 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate beyond confirming the market-wide scope. Baseline for a no-parameter tool applies; the mention that contributing coins are listed is a bonus, not a parameter detail.

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 ('Crypto market sentiment index: one news-sentiment score and bullish/bearish/neutral label') along with its scope and aggregation basis (24 supported coins, news-weighted, contributing coins listed). It explicitly distinguishes itself from get_sentiment (single coin) and get_movers, so an agent can choose correctly without opening any schema.

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 condition ('when an agent needs the overall crypto news mood rather than one coin's') and names both alternatives with their selecting conditions: get_sentiment for a single coin, get_movers for which coins are shifting. This is the when/when-not/alternative structure at full strength.

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