$0.09 via x402: Scan public crypto communities and feeds (Reddit /r/cryptocurrency, HackerNews search) for keywords and compute real-time sentiment scores.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Keyword or token symbol to scan for | |
| x_payment | No | Optional signed x402 payment payload |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full disclosure burden. It usefully discloses the $0.09 x402 cost and real-time computation, which are behaviors not visible in the schema. However, it omits payment mechanics (the schema marks x_payment optional while the description implies a hard cost), rate limits, and failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with zero waste: price, action, sources, and output each earn their place. The $0.09 cost is front-loaded, which is exactly where cost information matters most for an agent choosing among tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a 2-parameter tool: purpose, sources, and high-level output are clear. Gaps remain because there is no output schema and no annotations: the shape or scale of the sentiment scores is unspecified, and the tension between the stated $0.09 x402 cost and the schema's 'optional' x_payment payload is unresolved, which an agent must handle correctly to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The word 'keywords' in the description echoes q's schema text and adds domain context (scanned against crypto communities), but adds no format, syntax, or default details. The x_payment parameter receives no meaning beyond the schema's 'Optional signed x402 payment payload.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action (scan for keywords and compute sentiment scores), a concrete resource (Reddit /r/cryptocurrency and HackerNews search), and a distinct output (real-time sentiment scores). This clearly differentiates it from generic search/data siblings like web_search, tavily_search, and hn_top_stories, which retrieve content but do not compute sentiment over crypto communities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: an agent can infer this tool is for sentiment questions about crypto keywords rather than general lookup. However, the description names no sibling alternatives (e.g., web_search, crypto_ai_visibility, crosschain_attention_radar) and provides no when-not-to-use or exclusion guidance, leaving the routing decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Many tools occupy the same conceptual space: web_scrape vs markdown_web_scraper, post_check vs brand_ai_visibility_check, llm_chat_completions vs post_api_v1_chat_completions, chain_transaction_status vs chain_confirmations, and connect_token vs token_security_check + dex_token_data. Descriptions help in places, but for an agent facing 92 tools these near-overlapping endpoints will frequently cause misselection.
Everything is snake_case, but the conventions diverge sharply: get_chain_* and chain_* coexist for the same RPC family, post_* names are HTTP-route artifacts, api_generate reverses noun_verb order, and many names are bare nouns rather than verb_noun. There is no predictable naming pattern an agent can rely on.
At 92 tools this is far beyond the range where an agent can keep the surface coherent, even for a store. The flat tool list mixes products, bundles, aliases, proxies and single-use verticals, so most of the count is noise for any given task. A catalog/search/payment model with fewer exposed tools would fit the storefront purpose better.
The server has impressive breadth and covers key storefront/market workflows: catalog, samples, credits, directory listing, notary, and the task lifecycle. But each domain is shallow: there is no chain transaction broadcast, no task update/cancel/dispute, no AI-visibility history, and many verticals are a single tool with no follow-on operation. The surface is broad but not deeply complete.