Tanod MCP server

utilpeek: crypto Fear & Greed Index (value 0-100, label, last 7 days; alternative.me)

get_crypto_fear_greed_index

Read-onlyIdempotent

Retrieve the crypto Fear & Greed Index to gauge market sentiment: current 0-100 value, label, and 7-day history from alternative.me for informational use.

Instructions

utilpeek: Get the crypto Fear & Greed Index: market sentiment value, label and 7-day history. For local exchange premiums use get_local_crypto_premiums. Returns the crypto Fear & Greed Index (alternative.me): value 0-100, label and the last 7 daily values, with source and attribution in the reply. One value per day from an hourly cache; the attribution to alternative.me must stay next to the data. No cache, or older than 3 days, is a 503 (not charged). Informational only, not investment advice. Typically under 0.1 s (served from the cache). Price: USD 0.001. Free: 10 utilpeek calls per IP per UTC day. Docs: https://tanod.dev/learn/crypto-fear-greed-index-api.html

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`as_of`	No
`error`	No	Only on an error result: an object {code, message}, or the reason string of an x402 PaymentRequired object.
`label`	No
`scale`	No
`stale`	No
`value`	No	0 = extreme fear, 100 = extreme greed
`source`	No
`disclaimer`	No
`history_7d`	No	newest first, one value per UTC day
`attribution`	No	credit to alternative.me; carry it next to the data
`retrieved_at`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Oct 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the read-only and idempotent annotations, the description adds substantial behavioral context: one value per day from an hourly cache, typical latency under 0.1s, 503 behavior when cache is stale or absent, attribution requirements, pricing, and a free-call limit. These details tell an agent exactly what to expect at runtime.

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?

The description is front-loaded with purpose and usage, and most sentences carry operational value such as cache behavior, pricing, and limits. It is somewhat repetitive between the first sentence and the 'Returns...' sentence, but the repetition does not obscure the most important 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?

Given the simple parameterless interface, the existing annotations, and an output schema, the description is complete for correct selection and invocation. It covers return content, cache and error behavior, attribution requirements, cost, rate limits, and an alternative tool.

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 are no parameter semantics to explain. The baseline for a parameterless tool is 4, and the description does not need to compensate for any schema gaps.

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 names a specific resource and verb: 'Get the crypto Fear & Greed Index,' and specifies the exact returned fields (value 0-100, label, 7-day history). It also distinguishes the tool from a sibling by directing agents to get_local_crypto_premiums for a different use case.

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 explicitly routes agents to an alternative for local exchange premiums and provides clear usage boundaries, including that the data is informational only and not investment advice. It also states the cache-freshness limit and the 503 condition when data is unavailable or older than 3 days.

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

Deploy Server