Skip to main content
Glama
pythia-the-oracle

pythia-oracle-mcp

Official

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
list_tokensA

List all tokens tracked by Pythia with status and reliability info.

Returns token symbols, categories, data source count, 30-day uptime, and operational status. Covers cross-chain tokens (BTC, SOL, TAO, RENDER, ONDO, etc.) and DeFi tokens.

get_token_feedsA

Get all available indicator feeds for a specific token.

Shows every feed name (EMA, RSI, Bollinger, Volatility across all timeframes), the token's reliability stats, and data source count. Feed names are what you pass to the on-chain oracle to request data.

Args: engine_id: Token engine ID (e.g., 'bitcoin', 'solana', 'bittensor', 'aave', 'pol'). Use list_tokens() to see all available IDs.

get_market_summaryA

Get a summary of all tokens tracked by Pythia with operational overview.

Returns system-wide stats, tokens grouped by status, uptime distribution, data source health, and infrastructure status. Useful for quickly understanding what Pythia covers and whether the system is healthy.

check_oracle_healthA

Check the reliability and uptime of Pythia's oracle system.

Returns per-token 30-day uptime (sorted worst-first so problems surface immediately), recent daily status history, data source health, and infrastructure status. Use this to verify Pythia's reliability before integrating or relying on its data.

get_contractsA

Get Pythia contract addresses for on-chain integration. Shows all supported chains.

get_pricingA

Get Pythia pricing tiers and free trial info. Prices are live from the data feed.

get_integration_guideA

Get Solidity code to integrate Pythia into a smart contract.

Args: tier: 'discovery' (single value), 'analysis', 'speed', or 'complete'. chain: Optional chain key (e.g. 'mainnet', 'amoy', 'arbitrum'). When unset, the embedded Solidity uses the first available chain's addresses (Polygon mainnet by convention) and the prose lists every chain where this tier's consumer is deployed.

get_events_infoA

Get overview of Pythia Events — on-chain indicator alert subscriptions.

Returns pricing, supported conditions, subscriber flow, registry addresses per chain, and current subscription stats. Events let you subscribe once and get notified when an indicator crosses a threshold.

get_events_guideA

Get Solidity code to subscribe to Pythia Events (indicator alerts).

Returns a complete contract that approves LINK, subscribes to an indicator alert, listens for PythiaEvent, and can cancel for a refund.

subscribe_infoA

Plan a specific Pythia Events subscription with cost and exact calls.

Args: feed_name: Feed name to monitor (e.g. 'pol_RSI_5M_14', 'bitcoin_EMA_1H_20') condition: 0=ABOVE, 1=BELOW, 2=CROSSES_ABOVE, 3=CROSSES_BELOW days: Subscription duration in days (1-365)

get_visions_infoA

Get overview of Pythia Visions — walk-forward validated market intelligence on-chain.

Returns the walk-forward validated patterns with accuracy stats, the Vision Registry contract address, subscription info (FREE), evaluation frequency, and supported tokens. Visions are pattern detections that passed walk-forward validation across multiple years of history. Live token + pattern set is returned in the response (canonical source: feed-status.json visions section).

get_visions_guideA

Get Solidity code to subscribe to Pythia Visions and listen for VisionFired events.

Returns a complete contract that subscribes to the PythiaVisionRegistry, receives VisionFired events with pattern type, confidence, direction, price, and full analysis payload. Subscription is FREE (no LINK required).

get_vision_historyA

Get recent Pythia Visions fired for a token with pattern breakdown and stats.

Args: token: Token symbol to check (default: BTC). Case-insensitive. Currently live: BTC, ETH.

get_vision_payloadA

Get the full enriched object for a fired Pythia Vision by id.

Returns the rich AI-facing companion to the on-chain VisionFired event: pattern metadata with numeric ranges, failure profile (avg return when correct, avg drawdown when wrong, worst drawdown), cooldown context (hours since last same-pattern fire on this token, confidence delta vs last fire), and concurrent fires from other tokens within the last 24h.

Lightweight on-chain consumers can decode the VisionFired payload bytes directly. AI agents reasoning about a specific Vision should use this tool — it contains the data needed to size positions and compare against historical failure modes, which the on-chain event payload does not.

Args: vision_id: integer id of the Vision (returned by get_vision_history)

Returns: Multi-section text report. If vision_id is not in the recent window (last 20 fires per token), returns a helpful pointer to history.

lookup_event_feedA

Reverse-lookup a Pythia Event feedId (bytes32) to its human-readable feed name.

Subscribers receive bytes32 feedId in SubscriptionCreated and PythiaEvent events. This tool maps that hash back to the canonical feed name (e.g. 'pol_RSI_5M_14') so dApps don't need to maintain their own feedId → name table or query the registry contract on every event.

Args: feed_id_hex: bytes32 hash, with or without '0x' prefix, any case.

Returns: Single-section report with feed_name + matching token + indicator suffix. If the hash is not in the registered lookup table, returns a diagnostic pointer.

list_subscriptionsA

Enumerate active Pythia Event subscriptions owned by an address.

Returns every subscription where active=true (not yet fired, expired, or cancelled). Without this tool, dApps and dashboards have to replay every SubscriptionCreated log from the registry deploy block to discover what an owner is currently subscribed to.

Args: owner_address: subscriber wallet address ('0x...', case-insensitive).

Returns: Multi-section report listing each active subscription with feed name, condition + threshold, expiry, registry address, and creation tx.

get_feed_valueA

Get the latest computed value of a Pythia indicator feed.

Reads from the live cache (feed_values table) populated by the indicator pipeline on every cycle. Off-chain AI agents use this when reasoning about a Vision context, choosing an Event threshold, or sanity-checking a feed's current level. On-chain consumers should request the value through oracle.request() to get a Chainlink-attested response — see get_integration_guide().

Args: feed_name: full feed name (e.g. 'bitcoin_RSI_1H_14', 'pol_EMA_5M_20').

Returns: Latest value + computed_at + chain, one block per chain if a feed exists on multiple chains. If the feed has no cached value, returns a diagnostic pointer (warm-up window, deactivated, or unknown name).

get_indicator_historyA

Read Pythia's public, immutable indicator history for a feed over a date range — and optionally settle a condition against it.

Backed by the free day-file archive at https://pythia.c3x-solutions.com/history/{chain}/{feed_name}/{YYYY-MM-DD}.json (one file per feed per closed UTC day, 5-minute points, never rewritten once published). Use it to audit or re-derive "was RSI below 30 at any point last week?", to reconstruct what a Vision or Event saw, to backtest a threshold before subscribing to an Event, or to settle a prediction-market style question from public inputs anyone can re-fetch and verify.

Args: feed_name: full feed name, same key as Feeds/Events (e.g. 'bitcoin_RSI_1D_14'). start_date: first UTC day, YYYY-MM-DD (inclusive). end_date: last UTC day, YYYY-MM-DD (inclusive). Defaults to start_date. At most 31 days per call — split longer ranges. chain: delivery chain the feed is archived for (e.g. 'polygon'). Only needed when the manifest lists the feed on more than one chain. condition: optional 'ABOVE' or 'BELOW' — with threshold, evaluates whether ANY point in the range satisfies it. threshold: numeric threshold for condition, in the feed's own units.

Returns: Per-day coverage (points, min, max, first, last), the range summary, the day-file URLs used (so a verifier can re-fetch the exact inputs), and — when condition+threshold are given — a verdict: TRUE (first matching timestamp + value), FALSE (full coverage, no match), or INSUFFICIENT_DATA (missing day-files or gaps large enough that FALSE cannot be asserted). Never interpolates across gaps.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.8/5.0

Scored across 18 tools

Disambiguation2/5

Several tools have unclear boundaries: list_tokens, get_market_summary, and check_oracle_health all return uptime, status, and data-source health, with list_tokens already including 30-day uptime. Pricing/cost info also overlaps across get_pricing, get_events_info, and subscribe_info. Most other tools are distinct, but these multi-way overlaps make tool selection genuinely ambiguous.

Naming Consistency4/5

The vast majority of tools follow a clean lowercase snake_case verb_noun pattern, and the get_* family is dominant. Parallel names like get_events_info/get_events_guide and get_visions_info/get_visions_guide reinforce consistency, though a few outliers such as subscribe_info and check_oracle_health use different verbs.

Tool Count3/5

18 tools sits in the 16–25 range that feels heavy for a single-purpose server. The domain has multiple sub-areas, but the overlapping status/health tools suggest the surface could be consolidated. It is not excessive enough for a 2, but it is beyond the ideal 3–15 scope.

Completeness4/5

The tool set covers token discovery, feed data, historical verification, event subscription planning, vision analysis, contract addresses, integration guides, and pricing, which supports most real workflows. Minor gaps exist, such as no direct historical Event fire enumeration and no on-chain subscription actions, but agents can work around these via guides and get_indicator_history.

Maintenance

ActivityMaintained
ResponsivenessNo issues