The Pythia Oracle MCP Server delivers on-chain computed technical indicators (EMA, RSI, Bollinger Bands, VWAP, volatility) and market intelligence for smart contracts and AI agents via Chainlink-supported chains.
Token & Feed Discovery: List all tracked tokens, retrieve available indicator feeds per token (5M, 1H, 1D, 1W timeframes), and get a system-wide market summary.
Live Feed Values: Fetch the latest computed value for any indicator feed from the live off-chain cache (updated every 15 minutes).
Oracle Health Monitoring: Per-token 30-day uptime, data source health, active incidents, and infrastructure status.
Smart Contract Integration: Get contract addresses for all supported chains, pricing tiers, free trial details, and ready-to-deploy Solidity code for any tier (Discovery, Analysis, Speed, Complete).
Pythia Events (Alert Subscriptions): Subscribe smart contracts to on-chain indicator conditions (RSI below 30, EMA crossover, Bollinger breakout) with prepaid LINK — no external keepers needed. Includes cost estimation, active subscription lookup by owner address, and feedId reverse-lookup.
Pythia Visions (Pattern Intelligence): Walk-forward validated pattern detection (e.g., OVERSOLD_REVERSION, CAPITULATION_EVENT) with confidence scores and accuracy stats. View recent vision history per token, retrieve full enriched payloads with failure profiles and cooldown context, and get Solidity code to subscribe to VisionFired events — free, no LINK required.
Provides on-chain technical indicators (EMA, RSI, Bollinger Bands, VWAP, volatility) and event-driven alerts for smart contracts via the Chainlink oracle network.
Every smart contract deserves intelligence, not just data.
Pythia is the first oracle delivering calculated technical indicators on-chain — EMA, RSI, VWAP, Bollinger Bands, volatility — for any token, on any Chainlink-supported chain. The same indicators traders use, available to smart contracts and AI agents with a single call via Chainlink.
Pythia Events lets smart contracts subscribe to indicator conditions (RSI below 30, EMA crossover, Bollinger breakout) and get called automatically when they trigger. No keeper, no off-chain bot, no polling — your contract reacts to markets on its own.
Pythia Visions delivers walk-forward validated market intelligence on-chain — pattern type, confidence score, indicator snapshot, and feeds-to-watch for confirmation, all in one event. Backtested across 9 years of history. FREE to subscribe. For the current live token + pattern catalog with accuracy stats and fire frequency, call get_visions_info from the MCP tools below.
Most oracles only give you price. Pythia gives you computed analysis: EMA, RSI, Bollinger Bands, VWAP, volatility — for tokens like BTC, SOL, TAO, RENDER, ONDO, AAVE, UNI, and more, across 4 timeframes, delivered on-chain via Chainlink. New tokens and indicators are added on demand. If your AI agent, DeFi protocol, or trading bot needs on-chain RSI, EMA, or Bollinger Bands — Pythia is the only source.
Use cases:
AI trading agents that need on-chain technical signals
DeFi vault rebalancing based on RSI or volatility thresholds
Smart contract risk management using Bollinger Band width
AI-powered portfolio analysis with real-time calculated metrics
Event-driven strategies — subscribe to RSI thresholds or EMA crossovers, your contract gets triggered automatically
Automated DeFi bots without keepers — no Gelato, no cron jobs, no off-chain infrastructure
Related MCP server: Crypto Indicators MCP Server
pip install pythia-oracle-mcpAdd to claude_desktop_config.json:
{
"mcpServers": {
"pythia-oracle": {
"command": "pythia-oracle-mcp"
}
}
}claude mcp add pythia-oracle -- pythia-oracle-mcpAdd to MCP settings:
{
"pythia-oracle": {
"command": "pythia-oracle-mcp"
}
}Any MCP-compatible client works — just point it at pythia-oracle-mcp.
python -m pythia_oracle_mcpTool | Description |
| All tracked tokens with status, uptime, and data sources |
| All indicator feed names for a specific token |
| System-wide overview — tokens by status, ecosystem coverage, infrastructure health |
| Per-token 30-day uptime (worst-first), data source status, incident report |
| All contract addresses (operator, consumers, faucet, LINK) |
| Pricing tiers and when to use each one |
| Ready-to-deploy Solidity code for any tier |
| How Pythia Events work — subscribe to indicator conditions, get triggered on-chain |
| Solidity code and deployment steps for event subscriptions |
| Subscription details — conditions, pricing, refund mechanics |
| Pythia Visions overview — walk-forward validated patterns, fire-frequency disclosure, contract address |
| Solidity code to subscribe to Visions and listen for VisionFired events |
| Recent Visions fired for a token with pattern breakdown and confidence stats |
| Full enriched object for a fired Vision — failure profile, cooldown context, concurrent fires |
| Reverse-lookup an Event feedId (bytes32) to its human-readable feed name |
| Enumerate active Pythia Event subscriptions for an owner address |
| Latest computed value for any Pythia indicator feed (off-chain cache) |
Ask your AI agent:
"What indicators does Pythia have for Bitcoin?"
Calls get_token_feeds("bitcoin") — returns all indicator feeds for Bitcoin, grouped by type.
"Is Pythia reliable enough to integrate?"
Calls check_oracle_health() — returns per-token uptime, data source health, and active incidents.
"Give me a Solidity contract to consume Pythia's speed bundle"
Calls get_integration_guide("speed") — returns a complete, deployable contract with correct addresses and job IDs.
"What tokens does Pythia cover and are they all working?"
Calls get_market_summary() — returns ecosystem coverage, status breakdown, and infrastructure health.
"How do Pythia Events work? I want my contract to react when BTC RSI drops below 30."
Calls get_events_info() — returns how subscriptions work, supported conditions, and pricing.
"Give me the Solidity code to subscribe to an EMA crossover event."
Calls get_events_guide() — returns a deployable EventSubscriber contract with subscribe/receive pattern.
"What are Pythia Visions? What patterns does it detect?"
Calls get_visions_info() — returns walk-forward validated patterns with accuracy range, fire frequency, contract address, and how it works.
"Show me recent BTC Visions that fired"
Calls get_vision_history("BTC") — returns recent pattern detections with confidence and price.
"Give me Solidity code to subscribe to Pythia Visions"
Calls get_visions_guide() — returns a contract that subscribes to VisionFired events.
Any token, any Chainlink-supported chain — currently serving BTC, SOL, TAO, RENDER, ONDO, AAVE, UNI, MORPHO, and more, with new tokens added on demand
6 indicator types: EMA, RSI, Bollinger Bands (upper/lower), VWAP, Volatility, USD Price
4 timeframes: 5-minute, 1-hour, 1-day, 1-week
4 pricing tiers: Discovery / Analysis / Speed / Complete — for current LINK fees call get_pricing
Free trial: PythiaFaucet contract — no LINK needed
Pythia Events: Subscribe to indicator conditions (ABOVE/BELOW thresholds) — your contract gets called when they trigger. Prepaid in LINK, unused time refunded on cancel or fire. No keeper infrastructure needed.
Pythia Visions: Walk-forward validated market intelligence on-chain — pattern type + confidence + indicator snapshot + feeds-to-watch, delivered via Chainlink. FREE to subscribe. For the live list of patterns + tokens, call get_visions_info.
This MCP server is a thin client over https://pythia.c3x-solutions.com/feed-status.json, the live status feed updated every 15 minutes by the data engine. New tokens, new patterns, contract addresses, and pricing changes appear in MCP tools within seconds of the next data-engine cycle — no package update required.
If the live feed is unreachable, MCP tools raise a clear error rather than serve stale baked-in data. Retry shortly or check status. (As of v0.9.0, fail-loud — earlier versions had baked-in fallbacks that drifted from production state and have been removed.)
See pythia-oracle-examples for Solidity contracts with Hardhat setup — ready to deploy on any Chainlink-supported network.
MIT
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It discloses key behavioral traits: returns per-token 30-day uptime sorted worst-first, daily history, data source health, and infrastructure status. No contradictions present.
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?
Two sentences with zero waste: first sentence states core purpose, second lists what is returned. Front-loaded and efficient, every sentence earns its place.
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?
Given zero parameters, presence of output schema, and the tool's simple nature, the description provides all necessary context: what it checks, what data it returns, and when to use it. Complete and sufficient.
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?
The input schema has no parameters, so description does not need to explain them. It adds value by detailing the output components, effectively compensating for the lack of parameters. Baseline is 4 due to high schema coverage (100%).
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 clearly states the tool checks the reliability and uptime of Pythia's oracle system, using specific verbs and a distinct resource. It differentiates from sibling tools which focus on contracts, events, feeds, etc., leaving no ambiguity about its role as a health check.
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?
Explicitly advises using this tool to verify reliability before integrating or relying on data. While it does not give when-not-to-use or alternative tools, the context is clear and sufficient for the agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Pythia contract addresses for on-chain integration. Shows all supported chains.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explains what the tool does but does not disclose potential behavioral traits such as network calls, caching, rate limits, or authorization requirements. The existence of an output schema mitigates some concern about return format.
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?
Two sentences, no filler, directly conveys the function and scope. Every word contributes meaning.
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?
For a tool with no parameters and an output schema, the description is sufficient. It could slightly expand on what the output contains (e.g., addresses per chain), but the output schema likely covers that. The sibling tools list provides context about available alternatives.
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?
There are zero parameters, and the schema coverage is 100%. The description does not need to add parameter information beyond what the schema already provides. The baseline for zero parameters is 4, and the description meets it.
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 clearly states the tool retrieves Pythia contract addresses for on-chain integration and lists all supported chains. It specifies a concrete verb-resource pair and distinguishes from sibling tools like get_feed_value or check_oracle_health.
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?
The description implies usage for obtaining contract addresses during integration, but does not explicitly state when to use this tool over alternatives or when not to use it. The context is clear enough given the simplicity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It transparently discloses the tool returns a contract that approves LINK, subscribes, listens for events, and can cancel. It implies read-only behavior (returning code) but could explicitly note no side effects.
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?
Two concise sentences with no wasted words. First sentence states primary purpose, second elaborates on contract contents. Front-loaded and efficient.
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?
Given the tool's complexity and presence of an output schema (not shown), description adequately explains the returned contract's capabilities. Missing details on how to use the code, but sufficient for a code generation 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?
No parameters, so baseline of 4 applies. Description adds value by detailing the contract's functionality, compensating for absence of param info.
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?
Description clearly states 'Get Solidity code to subscribe to Pythia Events', specifying a verb and resource. It distinguishes from siblings like get_events_info (info about events) and get_integration_guide (general guide) by focusing on code generation for subscriptions.
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?
Description provides clear context of use (when you need a subscription contract), but lacks explicit exclusions or alternatives to other guide tools. It implies usage but could be more directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description partially discloses behavior by listing returned data, but does not mention side effects, read-only nature, or potential limitations, leaving some behavioral traits unclear.
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?
The description is extremely concise—two sentences plus a clarifying line—with the purpose front-loaded. Every sentence adds value without redundancy.
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?
For a simple, parameterless tool with an output schema, the description covers the tool's purpose, return categories, and conceptual context (event subscriptions). It is complete enough for agent invocation.
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?
The tool has zero parameters, so baseline is 4. The description adds value by clarifying the tool's purpose and output, which is sufficient given no parameters to describe.
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 clearly states the tool returns an overview of Pythia Events, specifying return contents (pricing, conditions, etc.) and distinguishing it from siblings like get_events_guide by focusing on high-level summary.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies it's for overview, but lacks when-not or alternative suggestions, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| feed_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses reading from live cache updated every cycle, describes return structure (value, computed_at, chain, multi-chain behavior), and explains diagnostic pointers for missing values. This fully informs the agent of behavior.
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?
The description is concise yet comprehensive, using clear sections and bullet points. Every sentence adds value without verbosity. Front-loaded with purpose and immediately useful examples.
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?
For a single-parameter tool with an output schema (indicated by context signals), the description covers purpose, usage, parameter format, and return behavior completely. No gaps remain.
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?
With 0% schema description coverage, the description fully compensates by providing explicit examples ('bitcoin_RSI_1H_14', 'pol_EMA_5M_20') and clarifying the 'full feed name' format. This adds significant meaning beyond the schema's simple type and title.
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 clearly states 'Get the latest computed value of a Pythia indicator feed' with a specific verb and resource. It distinguishes from sibling tools like get_market_summary and get_vision_payload by targeting feed values specifically, and contrasts with on-chain usage.
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?
The description explicitly states when off-chain AI agents should use this tool (reasoning about Vision context, choosing Event thresholds, sanity-checking) and provides a clear alternative for on-chain consumers (oracle.request() via get_integration_guide). This is excellent guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Solidity code to integrate Pythia into a smart contract.
Args: tier: 'discovery' (single value), 'analysis', 'speed', or 'complete'.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | discovery |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It indicates this is a retrieval of code (no mutation implied), but does not disclose any potential side effects, authentication needs, or rate limits. It adds minimal context beyond the basic purpose.
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?
Two sentences plus an args line: concise and to the point. No wasteful words. Could benefit from structured formatting, but overall efficient.
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?
Given one optional parameter and an existing output schema, the description covers the essential purpose and parameter values. It does not need to explain return values since output schema exists. Completeness is adequate for a simple retrieval 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?
The schema has 0% description coverage for the 'tier' parameter. The description adds meaning by listing the allowed values: 'discovery', 'analysis', 'speed', or 'complete'. This helps the agent understand valid inputs beyond the schema's type-only specification.
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 states exactly what the tool does: 'Get Solidity code to integrate Pythia into a smart contract.' It uses a specific verb ('Get') and clearly identifies the resource, distinguishing it from siblings like get_contracts or get_events_guide.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when not to use it, or differentiation from sibling tools like get_contracts or get_events_guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It describes the return data categories but does not disclose behavioral traits such as authentication requirements, rate limits, or side effects. The read-only nature is implied but not stated explicitly, and the description lacks details on data freshness or system impact.
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?
The description is four sentences long, front-loads the main purpose, and provides essential details without extraneous information. Every sentence adds value, making it efficient and easy to parse.
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?
Given the absence of parameters and presence of an output schema, the description is fairly complete. It explains the tool's purpose and output categories. However, it does not mention any prerequisites, such as authentication or data latency, which would enhance completeness for a system health overview 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?
The tool has zero parameters, and the schema coverage is 100%. According to guidelines, 0 parameters yields a baseline of 4. The description adds no parameter information, but none is needed.
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 clearly states the tool retrieves a summary of all tokens with an operational overview. It lists specific outputs (system-wide stats, tokens grouped by status, etc.), which makes the purpose clear. However, it does not explicitly differentiate from sibling tools like get_token_feeds or check_oracle_health, which could provide overlapping information.
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?
The description mentions the tool is 'useful for quickly understanding what Pythia covers and whether the system is healthy,' which implies when to use it. However, it does not provide explicit guidance on when not to use it or mention alternatives among the 16 sibling tools, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Pythia pricing tiers and free trial info. Prices are live from the data feed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only mentions that prices are live, lacking details on rate limits, authentication, or other behavioral traits.
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?
Two concise sentences with front-loaded key information, though slightly terse.
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?
Given no parameters and an output schema, the description adequately covers the tool's purpose; could mention return structure but output schema fills that gap.
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?
No parameters exist, so schema coverage is complete; the description adds no param info but is not required since there are none.
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 clearly states the verb 'Get' and the resource 'Pythia pricing tiers and free trial info', and distinguishes from siblings which focus on oracles, contracts, or events.
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?
No explicit when-to-use or when-not-to-use guidance; usage is implied for fetching pricing data, but no alternatives are discussed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| engine_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses that the tool returns feed names, reliability stats, and data source count, but does not mention any side effects, permissions, or rate limits. The read-only nature is implied but not explicit.
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?
The description is concise with a clear structure: purpose sentence, list of output contents, and parameter explanation. No redundant information.
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?
Given that the tool has only one parameter and an output schema (not shown), the description adequately covers what the tool returns and how to use it. It also connects the output to subsequent steps (passing feed names to oracle).
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?
The single parameter engine_id is explained with examples ('bitcoin', 'solana', etc.) and a reference to list_tokens() for valid values. This adds significant value over the schema, which has 0% description coverage.
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 clearly states 'Get all available indicator feeds for a specific token', providing a specific verb and resource. It distinguishes from siblings by focusing on listing available feeds rather than fetching values or managing subscriptions.
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?
It explains that feed names are used for oracle requests and instructs to use list_tokens() for engine IDs. However, it does not explicitly specify when to use this tool over alternatives like get_feed_value.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | BTC |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions 'recent' and 'pattern breakdown and stats' but does not explain what constitutes 'recent', pagination, or whether the operation is read-only. No disclosure on auth or rate limits.
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?
Description is concise and front-loaded, with no filler. However, it could be better structured (e.g., separate sections for purpose and args). Still, it's efficient.
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?
Given an output schema exists, description needn't detail return format, but it misses context on time range for 'recent' and what 'pattern breakdown' entails. Parameter docs are good, but overall completeness is moderate.
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 coverage is 0%, but the description adds meaning: token default is explained, case-insensitivity noted, and currently supported values listed (BTC, ETH). This goes beyond the schema's minimal info.
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 clearly states the tool retrieves recent Pythia Visions for a token, with specifics on pattern breakdown and stats. It distinguishes itself from siblings like get_visions_info or get_vision_payload by focusing on history and breakdown.
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?
The description implies use for checking recent visions by token but lacks explicit guidance on when to use this vs alternatives like get_visions_info or get_vision_payload. No when-not-to-use or prerequisite context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| vision_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns a multi-section text report and how it handles missing vision_ids. While it doesn't mention side effects, authentication, or rate limits, the description is sufficiently transparent for a read-only data retrieval tool.
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?
The description is well-structured with separate sections for what the tool returns, comparison to alternatives, args, and return behavior. It is concise yet comprehensive, with no wasted sentences.
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?
Given that the tool has an output schema (context indicates it exists), the description does not need to fully detail return values. It summarizes the output effectively and explains fallback behavior. The description fully covers the necessary context for a single-parameter 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?
The single parameter vision_id has 0% schema description coverage. The description adds meaning by stating it is an integer id returned by get_vision_history, which provides extraction source. This compensates for the lack of schema description.
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 explicitly states the tool gets the full enriched object for a fired Pythia Vision by id. It details the contents (pattern metadata, failure profile, etc.) and clearly distinguishes between lightweight on-chain consumers and AI agents, the latter being the intended audience. This provides a specific verb-resource combination with differentiation from siblings.
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?
The description provides explicit guidance: 'AI agents reasoning about a specific Vision should use this tool' and contrasts it with on-chain decoding. It also notes that if vision_id is not in the recent window, the tool returns a helpful pointer to history. This tells the agent when to use this tool and what to expect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It reveals that the tool returns a complete contract, details events, and importantly states subscription is free (no LINK required). This adds behavioral context beyond just 'get code'.
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?
The description is concise with two sentences that are front-loaded: first sentence states the core action, second details the return value and a key benefit (free). No unnecessary words.
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?
Given no parameters and no annotations, the description covers the tool's purpose and output. However, it omits information on how to use the returned code or any prerequisites, which would enhance completeness.
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?
No parameters exist, so the description's job is to explain what the tool does. It clearly explains the output (Solidity code) and its purpose, which adds meaning beyond the empty schema.
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 clearly states the tool returns Solidity code to subscribe to Pythia Visions and listen for VisionFired events. It distinguishes from siblings like get_vision_history (history data) and get_events_guide (different guide) by specifying this is for code generation.
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?
The description implies usage when needing subscription code, but does not explicitly state when to use this tool versus alternatives (e.g., get_events_guide for other event types). No when-not-to-use or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It details what the tool returns and mentions the canonical source (feed-status.json). While read-only behavior is implied, it does not explicitly state no side effects or disclose potential limitations, but the coverage is thorough.
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?
The description is a single, coherent paragraph that provides comprehensive information without excessive verbosity. It could benefit from bullet points for structure, but the content earns its place.
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?
Given zero parameters, high schema coverage, and the presence of an output schema, the description fully covers what the tool returns and its source. It is complete and leaves no obvious gaps for an agent to invoke the tool correctly.
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?
The tool has no parameters, so the baseline is 4. The description need not add parameter info, and it correctly omits any.
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 clearly states it returns an overview of Pythia Visions, listing specific components like patterns, contract address, subscription info, and supported tokens. It distinguishes itself from sibling tools by focusing on the walk-forward validated patterns and the comprehensive nature of the returned data.
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?
The description implies usage for obtaining an overview of visions but does not explicitly state when to use it over alternatives or provide exclusions. With many sibling tools, more guidance would be beneficial, but the purpose is clear enough for basic selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| owner_address | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It transparently states it returns only active subscriptions and defines 'active' (not yet fired, expired, or cancelled). It also outlines return sections. Lacks details on side effects or rate limits, but for a read operation, it is sufficient.
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?
The description is well-structured with clear paragraphs and Args/Returns sections. It is concise, providing all necessary information without superfluous words.
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?
Given the tool's simplicity (one parameter, single purpose), the description comprehensively covers purpose, parameter, return value, and use case. The presence of an output schema further reduces the burden.
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?
The input schema provides only title and type for 'owner_address', with 0% schema description coverage. The description compensates fully by explaining it is the subscriber wallet address and case-insensitive, adding critical semantic meaning.
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 clearly states the tool enumerates active Pythia Event subscriptions for an address, specifying the resource (subscriptions), action (enumerate), and scope (active=true). It distinguishes from the alternative of replaying logs, making the purpose unambiguous.
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?
The description explains when to use the tool (to discover current subscriptions) and provides context on the inefficiency of alternatives (replaying logs). While it doesn't explicitly list when not to use or compare with sibling tools like 'subscribe_info', it gives clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description provides clear behavioral context: returns token symbols, categories, data source count, 30-day uptime, and operational status. Covers cross-chain and DeFi tokens. No side effects disclosed (implied read-only).
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?
Two concise sentences that front-load the purpose and enumerate return fields. No wasted words.
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?
Given no parameters and existence of output schema, description sufficiently explains purpose and key return data. Covers scope and examples, making it complete for a list 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?
No parameters in schema; baseline 4 applies. Description does not need to add parameter info since none exist. Schema coverage is 100%.
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?
Clearly states it lists all tokens tracked by Pythia with status and reliability info. Gives specific return fields and examples of covered tokens (BTC, SOL, etc.), distinguishing it from siblings that focus on feeds or oracle health.
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?
Implies usage for getting an overview of all tokens, but does not explicitly state when to use versus alternative tools like get_token_feeds or get_market_summary. No exclusions or context for when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| feed_id_hex | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses that returns a single-section report with feed_name, token, and indicator suffix; if not found, a diagnostic pointer. Also explains input format (hex, optional '0x', any case). No side effects mentioned, but implied read-only.
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?
Concise yet informative. Includes purpose, motivation, parameter description, and return value. Each sentence adds value, though the motivation sentence could be slightly tighter.
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?
Given one parameter and output schema existence, description covers input format and output structure. It mentions the diagnostic pointer for missing hashes. Complete enough for the tool's complexity.
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 coverage is 0%, but description thoroughly explains feed_id_hex: bytes32 hash, with or without '0x' prefix, any case. It adds meaning beyond schema by specifying it's a hash and the accepted formats.
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?
Clearly states it reverse-looks up a bytes32 feedId to a human-readable feed name. The verb 'lookup' and resource 'event feed' are specific, and it distinguishes from sibling tools like get_feed_value or get_token_feeds.
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?
Provides explicit context: when subscribers receive bytes32 feedId in events and need canonical name. Explains why to use it instead of maintaining a local table or querying the registry contract. No explicit when-not, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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)
| Name | Required | Description | Default |
|---|---|---|---|
| feed_name | Yes | ||
| condition | No | ||
| days | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Plan... with cost and exact calls', which is vague about side effects (read vs write). It does not disclose whether a subscription is created, if there are costs incurred, or any authentication or rate limits. Minimal behavioral transparency.
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?
The description is concise: a short introductory sentence followed by a clear, bullet-like list for each parameter. No redundant information. Every sentence adds value, and the key purpose is front-loaded.
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?
Given the tool has 3 parameters and no annotations, the description covers the basics but lacks behavioral context (e.g., whether it's a read or write operation). An output schema exists but is not referenced, though that is acceptable per guidelines. The description does not address the presence of many sibling tools, leaving potential confusion about when to use this one.
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?
The description compensates for 0% schema coverage by providing clear explanations for each parameter: feed_name with examples, condition with enum mapping (0-3), and days with range. This adds significant meaning beyond the raw schema, making it easy for an agent to understand parameter usage.
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 starts with a specific verb 'Plan' and resource 'Pythia Events subscription', clearly indicating the tool's purpose. It mentions cost and exact calls, providing further clarity. This distinguishes it from sibling tools like list_subscriptions (listing) and get_events_info (retrieving info).
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?
The description implies usage through examples and parameter definitions, but does not explicitly state when to use this tool versus alternatives. For instance, it does not contrast with list_subscriptions or get_events_info. Usage context is implicit, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose, targeting different resources such as oracle health, contracts, feed values, events, visions, and subscriptions. No two tools are easily confused.
All tool names follow a consistent snake_case verb_noun pattern (e.g., get_feed_value, list_tokens, lookup_event_feed), making the set predictable and easy to navigate.
17 tools is on the higher end but still well-scoped given the broad domain covering oracle health, contracts, feeds, events, visions, and subscriptions. Each tool has a specific, non-redundant role.
The tool surface covers core domain operations like health checks, feed values, event management, and vision data. Minor gaps exist, such as no tool for historical feed values or direct subscription cancellation, but the overall coverage is strong.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Crypto market signals and portfolio telemetry. 6 tools pay-per-call in USDC, no API key.
Chainlink - 35 tools for price feeds and oracle data
Crypto market signals, technical indicators, and sentiment analysis for AI agents.
Crypto price-event settlement verdicts and US building-permit data, paid per call in USDC.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pythia-the-oracle/pythia-oracle-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
