Pyth Network MCP Server
Provides access to Bitcoin price feeds including BTC/USD, BTC/ETH, and BTC/EUR pairs
Provides price feed access across BNB Chain as part of the 107+ supported blockchain networks
References Pyth's Discord community for network-related support and discussions
Supports Ethereum price feeds and operates across Ethereum and other blockchain networks
Source code hosted on GitHub with issue tracking and contribution support
Provides real-time access to Pyth Network's decentralized oracle price feeds via the Hermes API, enabling retrieval of current prices, historical data, TWAP calculations, and publisher stake information across 1,930+ price feeds covering crypto, equity, forex, metals, and rates
Provides price feed access across NEAR Protocol as part of the supported blockchain networks
Server implementation written in Python 3.10+ using the official MCP SDK and httpx for HTTP requests
Supports Solana price feeds and operates across the Solana blockchain network
Supports price feed access across Sui blockchain as part of the multi-chain coverage
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Pyth Network MCP Serverget the current price of Bitcoin in USD"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Pyth Network MCP Server
An MCP server that provides real-time access to Pyth Network's decentralized oracle price feeds via the Hermes API, optimized for seamless integration into AI agents and autonomous systems.
Author: @itsomsarraf
Table of Contents
Related MCP server: OracleForge MCP
Features
🔧 Tools (5 Available)
Search Price Feeds: Search and filter through 1,930+ price feeds by symbol or asset type across 107+ blockchains
Get Latest Prices: Fetch real-time price updates for specific price feed IDs with parsed data (no binary clutter)
Historical Price Data: Query price updates at specific timestamps for backtesting and analysis
Publisher Stake Caps: Access the latest publisher stake caps data from the Pyth network
Time-Weighted Average Prices (TWAP): Calculate TWAP with custom time windows (1-600 seconds) for more stable pricing
💬 Prompts (4 Available)
Analyze Price Feed: Get detailed analysis of any asset with current price, TWAP, and volatility metrics
Compare Prices: Side-by-side comparison of multiple assets with volatility analysis
Market Overview: Comprehensive market report for any asset type (crypto, equity, fx, metal, rates)
Price Alert Setup: Step-by-step guidance for setting up price monitoring systems
📚 Resources (3 Available)
Pyth Network Information: Overview of the network, data providers, and capabilities
Popular Price Feeds: Quick reference of commonly used price feed IDs for major assets
API Documentation Reference: Quick reference guide for Hermes API endpoints
🌐 Universal Features
Universal Price Feed IDs: Unlike chain-specific oracles, Pyth uses universal price feed IDs that work across all supported blockchains
Full MCP Compliance: Implements tools, prompts, and resources according to MCP specification
Supported Asset Types and Coverage
Pyth Network aggregates data from 125+ first-party financial institutions, including major exchanges, market makers, and trading firms, providing:
1,930+ Price Feeds across 107+ Blockchains
Asset Types:
crypto- Cryptocurrencies (BTC/USD, ETH/USD, SOL/USD, etc.)equity- Traditional equities and stocksfx- Foreign exchange pairsmetal- Precious metals (Gold, Silver, etc.)rates- Interest rates and rate products
Pyth operates on a pull-based oracle model, delivering high-frequency price updates (refreshed every ~400ms) directly from data providers to smart contracts across multiple chains including Ethereum, Solana, Avalanche, BNB Chain, Aptos, Sui, Near, and many more.
Prerequisites
Python: Version 3.10 or higher
Package Manager: pip or uv (recommended)
Claude Desktop (optional): For integration with Anthropic's Claude interface
Cursor/Windsurf (optional): For IDE integration
Installation
Clone the Repository
git clone https://github.com/itsomsarraf/pyth-network-mcp.git
cd pyth-network-mcpInstall Dependencies
Using uv (recommended):
uv syncUsing pip:
pip install mcp httpxThe project requires:
mcp>=1.0.0- Official MCP SDKhttpx>=0.27.0- For HTTP requests to Pyth Hermes API
Configure MCP Client
To use this server with an MCP client like Claude Desktop, add the following to your MCP settings configuration file:
For Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json on macOS, %APPDATA%\Claude\claude_desktop_config.json on Windows):
{
"mcpServers": {
"pyth-network": {
"command": "python3",
"args": ["pyth_mcp_server.py"],
"cwd": "/absolute/path/to/pyth-network-mcp"
}
}
}For Cursor/Windsurf (.cursorrules or MCP settings):
{
"mcpServers": {
"pyth-network": {
"command": "python3",
"args": ["pyth_mcp_server.py"],
"cwd": "/absolute/path/to/pyth-network-mcp"
}
}
}Using uv:
{
"mcpServers": {
"pyth-network": {
"command": "uv",
"args": ["run", "pyth_mcp_server.py"],
"cwd": "/absolute/path/to/pyth-network-mcp"
}
}
}Running the Server
The server uses stdio transport (standard input/output) for MCP communication:
python3 pyth_mcp_server.pyTo test the server with the included client:
python3 pyth_mcp_client.pyUsage
The server exposes 5 tools, 4 prompts, and 3 resources via the MCP protocol, accessible through Claude Desktop (for natural language queries), Cursor/Windsurf, or programmatically.
MCP Capabilities Overview
Capability | Count | Description |
Tools | 5 | Direct API interactions for getting price data |
Prompts | 4 | Pre-configured analysis templates for common tasks |
Resources | 3 | Static reference information and documentation |
Below are detailed descriptions of each capability with examples.
Tool: get_price_feeds
Description: Search and filter price feeds from the Pyth network by symbol or asset type. This is useful for discovering available price feeds before querying their prices.
Parameters:
query(string, optional): Filter results to price feeds whose symbol contains this string (case insensitive). Example: "bitcoin", "eth", "gold"asset_type(string, optional): Filter by asset type (case insensitive). Options:crypto,equity,fx,metal,rates
Returns: List of price feed metadata with IDs and attributes.
Natural Language Example (Claude Desktop):
User: "What Bitcoin price feeds are available?"
Assistant: "I found several Bitcoin price feeds including:
BTC/USD (ID: e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43)
BTC/ETH
BTC/EUR
These feeds are available across all 107+ supported blockchains."
Example JSON Response:
{
"price_feeds": [
{
"id": "e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43",
"attributes": {
"symbol": "Crypto.BTC/USD",
"asset_type": "Crypto",
"base": "BTC",
"quote_currency": "USD",
"description": "Bitcoin vs US Dollar"
}
}
]
}Tool: get_latest_price_updates
Description: Fetch the latest price updates for specific price feed IDs. Returns clean, readable price data without binary clutter.
Parameters:
ids(list[string], required): List of price feed IDs to get updates forencoding(string, optional): Encoding type for binary data. Options:hex,base64. Default:hexparsed(boolean, optional): If true, include parsed price data. Default:trueignore_invalid_price_ids(boolean, optional): If true, invalid price IDs are ignored. Default:falseinclude_binary(boolean, optional): If true, include binary data. Default:false(clean output)
Returns: Price updates with parsed, human-readable data.
Natural Language Example (Claude Desktop):
User: "What's the current price of Bitcoin in USD?"
Assistant: "The current BTC/USD price is $113,395.22 (as of 2 seconds ago). The price has a confidence interval of ±$234.77."
Example JSON Response:
{
"parsed": [
{
"id": "e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43",
"price": {
"price": "11339522000000",
"conf": "23477142598",
"expo": -8,
"publish_time": 1760133288
},
"ema_price": {
"price": "11620589900000",
"conf": "7599704800",
"expo": -8,
"publish_time": 1760133288
},
"metadata": {
"slot": 247985552,
"proof_available_time": 1760133290,
"prev_publish_time": 1760133288
}
}
]
}Note: The price value must be multiplied by 10^expo to get the actual price. Example: 11339522000000 × 10^-8 = $113,395.22
Tool: get_price_updates_at_time
Description: Get historical price updates at or after a specific timestamp. This is useful for backtesting strategies or analyzing historical price movements.
Parameters:
publish_time(integer, required): Unix timestamp in secondsids(list[string], required): List of price feed IDs to get updates forencoding(string, optional): Encoding type for binary data. Options:hex,base64. Default:hexparsed(boolean, optional): If true, include parsed price data. Default:trueignore_invalid_price_ids(boolean, optional): If true, invalid price IDs are ignored. Default:falseinclude_binary(boolean, optional): If true, include binary data. Default:false
Returns: Price updates at or after the specified timestamp.
Natural Language Example (Claude Desktop):
User: "What was the BTC/USD price at timestamp 1760132736?"
Assistant: "At timestamp 1760132736, the BTC/USD price was $112,103.54 with a confidence interval of ±$869.53."
Example JSON Response:
{
"parsed": [
{
"id": "e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43",
"price": {
"price": "11210354370540",
"conf": "86953286118",
"expo": -8,
"publish_time": 1760132736
},
"ema_price": {
"price": "11629198600000",
"conf": "6729670300",
"expo": -8,
"publish_time": 1760132736
},
"metadata": {
"slot": 247984264,
"proof_available_time": 1760132737,
"prev_publish_time": 1760132735
}
}
]
}Tool: get_publisher_stake_caps
Description: Get the most recent publisher stake caps update data. This provides information about publisher staking limits in the Pyth network, which is important for understanding network security and data quality.
Parameters:
encoding(string, optional): Encoding type for binary data. Options:hex,base64. Default:hexparsed(boolean, optional): If true, include parsed update data. Default:trueinclude_binary(boolean, optional): If true, include binary data. Default:false
Returns: Latest publisher stake caps update data in parsed, readable format.
Natural Language Example (Claude Desktop):
User: "What are the current publisher stake caps on the Pyth network?"
Assistant: "The latest publisher stake caps data shows staking limits for each publisher in the network. This includes caps for all 125+ data providers, with the highest cap being 87.4 trillion units."
Example JSON Response:
{
"parsed": [
{
"publisher_stake_caps": [
{
"publisher": "7YQg8Tz9KHKsg7yHiAFRBsDkLoKvZbMXt7VbW44F7QM",
"cap": 87415862629839
},
{
"publisher": "8Mg3RA4aNRzw68pZKjB3rsBJ7gB3UDcFwKBbiXLnhHX",
"cap": 54545454545
}
]
}
]
}Tool: get_twap_latest
Description: Get the latest Time-Weighted Average Price (TWAP) with a custom time window. TWAP provides more stable pricing by averaging prices over time, which is useful for reducing the impact of short-term volatility.
Parameters:
window_seconds(integer, required): Time window in seconds (1-600). Example: 60 = 1 minute TWAP, 300 = 5 minute TWAPids(list[string], required): List of price feed IDs to get TWAP forencoding(string, optional): Encoding type for binary data. Options:hex,base64. Default:hexparsed(boolean, optional): If true, include calculated TWAP in parsed field. Default:trueignore_invalid_price_ids(boolean, optional): If true, invalid price IDs are ignored. Default:falseinclude_binary(boolean, optional): If true, include binary data. Default:false
Returns: Time-weighted average prices for the specified window.
Natural Language Example (Claude Desktop):
User: "What's the 5-minute TWAP for BTC/USD?"
Assistant: "The 5-minute TWAP for BTC/USD is $113,318.45, which is slightly lower than the current spot price of $113,395.22. This indicates recent upward price movement."
Example JSON Response:
{
"parsed": [
{
"id": "e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43",
"start_timestamp": 1760132736,
"end_timestamp": 1760133036,
"twap": {
"price": "11331845299185",
"conf": "48677830724",
"expo": -8,
"publish_time": 1760133036
},
"down_slots_ratio": "0"
}
]
}Prompts
Prompts are pre-configured templates that guide AI assistants through complex multi-step tasks.
Prompt: analyze_price_feed
Description: Get a detailed analysis of any asset including current price, TWAP, confidence intervals, and volatility metrics.
Arguments:
asset_symbol(required): Symbol of the asset to analyze (e.g., BTC, ETH, SOL)
Example Usage in Claude Desktop:
User: "Use the analyze_price_feed prompt for ETH"
Claude: Executes multi-step analysis including:
Searches for ETH price feeds
Gets latest price
Calculates 5-minute TWAP
Provides comprehensive analysis with trends
Prompt: compare_prices
Description: Compare multiple assets side by side with price, TWAP, and volatility analysis.
Arguments:
symbols(required): Comma-separated list of asset symbols (e.g., BTC,ETH,SOL)
Example Usage:
"Use the compare_prices prompt with symbols BTC,ETH,SOL"
Creates a comparison table showing relative performance and volatility.
Prompt: market_overview
Description: Generate a comprehensive market report for a specific asset type.
Arguments:
asset_type(required): crypto, equity, fx, metal, or rates
Example Usage:
"Use the market_overview prompt for crypto assets"
Provides overview of all crypto feeds with prices and trends.
Prompt: price_alert_setup
Description: Get step-by-step instructions for setting up automated price monitoring.
Arguments:
asset_symbol(required): Symbol of the asset to monitor
Example Usage:
"Use the price_alert_setup prompt for SOL"
Provides feed ID, current price, polling recommendations, and code examples.
Resources
Resources provide static reference information about Pyth Network.
Resource: pyth://network/info
Content: General information about Pyth Network
Network overview
125+ data providers
Coverage statistics (1,930+ feeds, 107+ chains)
Key features and capabilities
Access in Claude Desktop: "Show me the Pyth Network information resource"
Resource: pyth://feeds/popular
Content: JSON reference of popular price feed IDs
Top crypto pairs (BTC/USD, ETH/USD, SOL/USD, etc.)
Major equities (AAPL, TSLA, MSFT)
FX pairs (EUR/USD, GBP/USD)
Precious metals (Gold, Silver)
Access: "Show me popular Pyth price feeds"
Resource: pyth://docs/api
Content: Quick reference for Hermes API
All endpoint documentation
Query parameter formats
Price format explanation
Example requests
Access: "Show me the Pyth API documentation resource"
Testing the Server
The repository includes a demonstration client (pyth_mcp_client.py) that shows how to use all five tools with the official MCP protocol. Run it with:
python3 pyth_mcp_client.pyFinding Price Feed IDs
To find the correct price feed ID for your desired asset:
Use the
get_price_feedstool to search by symbol:"Search for Ethereum price feeds"Or visit the Pyth Network Price Feeds page to browse all available feeds
Common price feed IDs:
BTC/USD:
e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43ETH/USD:
ff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0aceSOL/USD:
ef0d8b6fda2ceba41da15d4095d1da392a0d2f8ed0c6c7bc0f4cfac8c280b56d
Project Structure
pyth-network-mcp/
├── pyth_tools.py # Pyth Network API client
├── pyth_mcp_server.py # Official MCP server
├── pyth_mcp_client.py # Example client
├── pyproject.toml # Dependencies
├── README.md # This file
├── STRUCTURE.md # Structure guide
├── .gitignore
└── fastmcp-implementation/ # Alternative FastMCP implementationArchitecture
This official MCP server uses:
Official MCP SDK: Standards-compliant MCP protocol implementation
stdio transport: For efficient communication with MCP clients
Pyth Hermes API: Pyth's REST API for accessing price feed data (
https://hermes.pyth.network)httpx: Async HTTP client for making API requests
The server operates statelessly, fetching fresh data from Pyth's Hermes API on each request. Binary data is disabled by default for clean, human-readable responses.
When to Use This vs FastMCP?
This repository contains two implementations of the Pyth Network MCP server:
Official MCP (This Root Directory) ✅ Recommended
When to use:
✅ Production deployments - Standards-compliant and battle-tested
✅ Claude Desktop integration - Official protocol support
✅ Cursor/Windsurf integration - Best compatibility with AI IDEs
✅ Better performance - Efficient stdio transport
✅ Future-proof - Follows MCP specification exactly
✅ Stable & reliable - Official SDK with proper error handling
Transport: stdio (standard input/output)
Protocol: Official MCP SDK
Best for: Production, AI agents, real applications
FastMCP Implementation (Subdirectory)
When to use:
🧪 Learning & experimentation - Simpler to understand
🧪 HTTP/SSE preferred - If you need HTTP-based transport
🧪 Quick prototyping - Fast to set up and test
🧪 Educational purposes - Great for learning MCP concepts
Transport: HTTP with Server-Sent Events (SSE)
Protocol: FastMCP framework
Best for: Learning, experimentation, HTTP-based workflows
Quick Comparison
Feature | Official MCP (Root) | FastMCP (Subfolder) |
Production Ready | ✅ Yes | 🔶 Basic |
Performance | ✅ Excellent | 🔶 Good |
Claude Desktop | ✅ Full support | ✅ Supported |
Transport | stdio | HTTP/SSE |
Ease of Learning | 🔶 Moderate | ✅ Easy |
Protocol Compliance | ✅ Official spec | 🔶 Framework-based |
Recommended for | Production use | Learning/testing |
📝 Note: Both implementations provide the same five tools and access to the same Pyth Network data. The difference is in the underlying transport and protocol implementation.
See fastmcp-implementation/README.md for FastMCP documentation.
License
This project is licensed under the MIT License.
About
Pyth Network is a decentralized oracle protocol that delivers real-time market data to smart contracts across 107+ blockchains. By aggregating data from over 125 first-party publishers—including major exchanges, market makers, and trading firms—Pyth provides reliable and low-latency price feeds for various asset classes.
This MCP server makes Pyth's extensive price feed network easily accessible to AI agents, autonomous systems, and other applications through the Model Context Protocol, enabling intelligent agents to make informed decisions based on real-time market data.
External Resources
Pyth Network: https://pyth.network
Pyth Documentation: https://docs.pyth.network
Hermes API Docs: https://hermes.pyth.network/docs
Price Feeds: https://pyth.network/price-feeds
MCP Protocol: https://modelcontextprotocol.io
Contributing
Contributions are welcome! Please feel free to submit a Pull Request.
Support
For issues related to:
This MCP Server: Open an issue on GitHub
Pyth Network: Visit Pyth's Discord or documentation
MCP Protocol: See Model Context Protocol documentation
Available Tools
5 toolsget_latest_price_updatesC
Get the latest price updates for specific Pyth Network price feed IDs
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | List of price feed IDs to get updates for | |
| encoding | No | Encoding type for binary data (default: hex) | |
| parsed | No | Include parsed price update (default: true) | |
| ignore_invalid_price_ids | No | Ignore invalid price IDs (default: false) | |
| include_binary | No | Include binary proof data (default: false) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't mention any behavioral traits like rate limits, authentication requirements, error handling, or what happens when invalid IDs are provided. The description is purely functional without operational context.
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, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a tool with this level of complexity and is perfectly front-loaded with the essential 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?
For a tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns, how to interpret results, or provide context about the Pyth Network ecosystem. The agent would need to guess about the output format and practical usage scenarios.
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 100% schema description coverage, all parameters are well-documented in the schema itself. The description doesn't add any meaningful parameter semantics beyond what's already in the schema - it mentions 'specific price feed IDs' which corresponds to the 'ids' parameter, but provides no additional context about parameter usage or interactions.
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 action ('Get') and resource ('latest price updates for specific Pyth Network price feed IDs'), making the purpose immediately understandable. It doesn't explicitly distinguish from siblings like 'get_price_feeds' or 'get_price_updates_at_time', but the focus on 'latest' and 'specific IDs' provides some implicit differentiation.
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 no guidance on when to use this tool versus alternatives like 'get_price_feeds' or 'get_price_updates_at_time'. It mentions 'specific price feed IDs' but doesn't explain when to prefer this over other tools for similar data retrieval tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_price_feedsC
Search and filter Pyth Network price feeds by symbol or asset type
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Filter results to price feeds whose symbol contains this string (case insensitive) | |
| asset_type | No | Filter by asset type: crypto, equity, fx, metal, or rates (case insensitive) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool searches and filters, implying a read-only operation, but doesn't cover critical aspects like whether it's safe (non-destructive), potential rate limits, authentication needs, or the format of returned results. This leaves significant gaps for a tool with no output schema.
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, efficient sentence that front-loads the core action ('search and filter') and resource ('Pyth Network price feeds'), with no wasted words. It's appropriately sized for the tool's complexity.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., list of feeds, metadata), behavioral traits like safety or performance, or how it differs from siblings, making it inadequate for an agent to use effectively without additional context.
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 schema fully documents both parameters ('query' and 'asset_type') with details like case insensitivity and allowed values. The description adds minimal value beyond the schema by mentioning filtering by symbol or asset type, aligning with baseline expectations.
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's purpose with specific verbs ('search and filter') and resources ('Pyth Network price feeds'), and identifies filtering criteria ('by symbol or asset type'). However, it doesn't explicitly differentiate from sibling tools like 'get_latest_price_updates' or 'get_price_updates_at_time', which likely return different data formats or time-specific results.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools, prerequisites, or exclusions, leaving the agent to infer usage based on the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_price_updates_at_timeA
Get historical Pyth Network price updates at or after a specific timestamp
| Name | Required | Description | Default |
|---|---|---|---|
| publish_time | Yes | Unix timestamp in seconds | |
| ids | Yes | List of price feed IDs to get updates for | |
| encoding | No | Encoding type for binary data (default: hex) | |
| parsed | No | Include parsed price update (default: true) | |
| ignore_invalid_price_ids | No | Ignore invalid price IDs (default: false) | |
| include_binary | No | Include binary proof data (default: false) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic operation without disclosing behavioral traits. It does not cover rate limits, authentication needs, error handling, pagination, or response format. The phrase 'at or after a specific timestamp' hints at temporal behavior but lacks detail on how multiple updates are handled.
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, efficient sentence that front-loads the core purpose. Every word earns its place, with no redundant or vague language. It directly communicates the tool's function without unnecessary elaboration.
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 6 parameters, no annotations, and no output schema, the description is minimal. It adequately states the purpose but lacks behavioral details, parameter guidance, and output information. Given the complexity and absence of structured data, it should provide more context about usage and results.
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 schema fully documents all 6 parameters. The description adds no parameter-specific information beyond implying temporal filtering via 'publish_time'. It does not explain parameter interactions or provide additional context beyond what the schema offers.
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 action ('Get historical Pyth Network price updates') with specific temporal scope ('at or after a specific timestamp'), distinguishing it from siblings like 'get_latest_price_updates' (current) and 'get_twap_latest' (time-weighted). It explicitly identifies the resource (Pyth Network price updates) and verb (Get historical).
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 historical data retrieval, contrasting with 'get_latest_price_updates' for current data. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_price_feeds' or 'get_twap_latest', and does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_publisher_stake_capsC
Get the most recent publisher stake caps data from Pyth Network
| Name | Required | Description | Default |
|---|---|---|---|
| encoding | No | Encoding type for binary data (default: hex) | |
| parsed | No | Include parsed update data (default: true) | |
| include_binary | No | Include binary proof data (default: false) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what data is retrieved ('most recent publisher stake caps data') without mentioning any behavioral traits like rate limits, authentication needs, error handling, or what 'most recent' entails (e.g., time-based or event-based). This leaves significant gaps in understanding how the tool behaves in practice.
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, efficient sentence that directly states the tool's purpose without any unnecessary words. It is appropriately sized and front-loaded, making it easy to understand at a glance. Every part of the sentence earns its place by conveying essential 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 the complexity of retrieving network data with three parameters and no annotations or output schema, the description is incomplete. It doesn't explain what 'publisher stake caps data' entails, how the data is structured, or any behavioral aspects like latency or data freshness. Without this context, the agent lacks sufficient information to use the tool effectively beyond basic 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 input schema has 100% description coverage, with clear documentation for all three parameters (encoding, parsed, include_binary). The description adds no parameter-specific information beyond what the schema provides, such as explaining how these parameters affect the returned data. Given the high schema coverage, a baseline score of 3 is appropriate as the schema does the heavy lifting.
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 action ('Get') and resource ('most recent publisher stake caps data from Pyth Network'), providing a specific purpose. However, it doesn't explicitly differentiate this tool from its siblings (like get_latest_price_updates or get_price_feeds), which all seem to retrieve different types of Pyth Network data, so it misses full sibling distinction.
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 no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, leaving the agent with no usage instructions beyond the basic purpose. This lack of guidance makes it harder to choose between sibling tools effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_twap_latestC
Get the latest time-weighted average price (TWAP) from Pyth Network with a custom time window
| Name | Required | Description | Default |
|---|---|---|---|
| window_seconds | Yes | Time window in seconds (1-600). Example: 300 for 5-minute TWAP | |
| ids | Yes | List of price feed IDs to get TWAP for | |
| encoding | No | Encoding type for binary data (default: hex) | |
| parsed | No | Include calculated TWAP in parsed field (default: true) | |
| ignore_invalid_price_ids | No | Ignore invalid price IDs (default: false) | |
| include_binary | No | Include binary proof data (default: false) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool gets TWAP data but doesn't describe what the output looks like (e.g., format, structure), error handling, rate limits, authentication needs, or whether it's a read-only operation. The mention of 'custom time window' hints at configuration but lacks operational details.
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, efficient sentence that front-loads the core purpose ('Get the latest TWAP') and adds necessary context ('from Pyth Network with a custom time window'). There's no wasted verbiage or 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 tool with 6 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain the return format, error conditions, or how the TWAP is calculated (e.g., over what time period 'latest' refers to). The lack of behavioral context and output information leaves significant gaps for an agent to use this tool effectively.
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 parameters are fully documented in the schema. The description doesn't add any semantic information beyond what's in the schema (e.g., it doesn't explain why window_seconds is limited to 1-600 or how TWAP calculation works with multiple ids). Baseline 3 is appropriate since the schema does the heavy lifting.
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 resource 'latest time-weighted average price (TWAP) from Pyth Network', specifying the action and data source. It mentions 'custom time window' which adds specificity, but doesn't explicitly differentiate from sibling tools like get_latest_price_updates or get_price_feeds beyond the TWAP calculation aspect.
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 no guidance on when to use this tool versus alternatives like get_latest_price_updates or get_price_feeds. It mentions a 'custom time window' but doesn't explain why one would choose TWAP over other price data methods, nor does it specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Each tool has a clearly distinct purpose with no overlap: get_latest_price_updates for real-time prices, get_price_feeds for searching feeds, get_price_updates_at_time for historical data, get_publisher_stake_caps for publisher data, and get_twap_latest for time-weighted averages. The descriptions make it easy to differentiate between current, historical, search, publisher, and TWAP operations.
All tools follow a consistent verb_noun pattern starting with 'get_' followed by descriptive nouns (e.g., latest_price_updates, price_feeds, price_updates_at_time). The naming is uniform and predictable, making it easy for agents to understand the action and target resource without confusion.
With 5 tools, this server is well-scoped for its purpose of accessing Pyth Network price and data feeds. Each tool earns its place by covering distinct aspects like real-time, historical, search, publisher, and TWAP data, avoiding bloat while providing comprehensive functionality for the domain.
The tool surface is nearly complete for accessing Pyth Network data, covering real-time prices, historical data, feed search, publisher information, and TWAP calculations. A minor gap exists in the lack of write operations (e.g., submitting data or managing feeds), but this is reasonable for a read-only data access server, and agents can work effectively with the provided tools.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Pyth Hermes MCP — real-time price feeds and oracle data for DeFi agents.
Live USD crypto spot prices by ticker (BTC, ETH, SOL, …) for AI agents. x402 pay-per-call.
Real-time data feeds for AI agents with USDC micropayments on Base for premium tools.
Curated marketplace of real-world data APIs for AI agents, paid per call in USDC on Solana.
Related MCP Servers
- AlicenseAqualityCmaintenanceProvides AI agents with real-time financial market intelligence including stock quotes, crypto data, technical analysis, and portfolio insights. Enables natural language queries for current prices, technical indicators, asset comparisons, and portfolio analysis.176MIT
- FlicenseNot gradedqualityDmaintenanceMCP server providing real-time crypto price feeds from Pyth Network, Chainlink, and Uniswap v3 10 tools for LLM agents and AI workflows.
- AlicenseAqualityCmaintenanceProvides live cryptocurrency market data from over 100 exchanges, enabling AI agents to fetch prices, order books, funding rates, and more for trading analysis and arbitrage opportunities.132MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to access crypto prices, DeFi yields, Polymarket data, Base chain info, and security scans with pay-per-call via USDC on Base mainnet.MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/itsOmSarraf/pyth-network-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server