Skip to main content
Glama
itsOmSarraf

Pyth Network MCP Server

by itsOmSarraf

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.

MCP Badge License: MIT Python 3.10+ MCP

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 stocks

    • fx - Foreign exchange pairs

    • metal - 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-mcp

Install Dependencies

Using uv (recommended):

uv sync

Using pip:

pip install mcp httpx

The project requires:

  • mcp>=1.0.0 - Official MCP SDK

  • httpx>=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.py

To test the server with the included client:

python3 pyth_mcp_client.py

Usage

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 for

  • encoding (string, optional): Encoding type for binary data. Options: hex, base64. Default: hex

  • parsed (boolean, optional): If true, include parsed price data. Default: true

  • ignore_invalid_price_ids (boolean, optional): If true, invalid price IDs are ignored. Default: false

  • include_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 seconds

  • ids (list[string], required): List of price feed IDs to get updates for

  • encoding (string, optional): Encoding type for binary data. Options: hex, base64. Default: hex

  • parsed (boolean, optional): If true, include parsed price data. Default: true

  • ignore_invalid_price_ids (boolean, optional): If true, invalid price IDs are ignored. Default: false

  • include_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: hex

  • parsed (boolean, optional): If true, include parsed update data. Default: true

  • include_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 TWAP

  • ids (list[string], required): List of price feed IDs to get TWAP for

  • encoding (string, optional): Encoding type for binary data. Options: hex, base64. Default: hex

  • parsed (boolean, optional): If true, include calculated TWAP in parsed field. Default: true

  • ignore_invalid_price_ids (boolean, optional): If true, invalid price IDs are ignored. Default: false

  • include_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:

  1. Searches for ETH price feeds

  2. Gets latest price

  3. Calculates 5-minute TWAP

  4. 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.py

Finding Price Feed IDs

To find the correct price feed ID for your desired asset:

  1. Use the get_price_feeds tool to search by symbol:

    "Search for Ethereum price feeds"
  2. Or visit the Pyth Network Price Feeds page to browse all available feeds

  3. Common price feed IDs:

    • BTC/USD: e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43

    • ETH/USD: ff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace

    • SOL/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 implementation

Architecture

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

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

Support

For issues related to:

Available Tools

5 tools
get_latest_price_updatesC

Get the latest price updates for specific Pyth Network price feed IDs

ParametersJSON Schema
NameRequiredDescriptionDefault
idsYesList of price feed IDs to get updates for
encodingNoEncoding type for binary data (default: hex)
parsedNoInclude parsed price update (default: true)
ignore_invalid_price_idsNoIgnore invalid price IDs (default: false)
include_binaryNoInclude binary proof data (default: false)

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
queryNoFilter results to price feeds whose symbol contains this string (case insensitive)
asset_typeNoFilter by asset type: crypto, equity, fx, metal, or rates (case insensitive)

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
publish_timeYesUnix timestamp in seconds
idsYesList of price feed IDs to get updates for
encodingNoEncoding type for binary data (default: hex)
parsedNoInclude parsed price update (default: true)
ignore_invalid_price_idsNoIgnore invalid price IDs (default: false)
include_binaryNoInclude binary proof data (default: false)

TDQS

A3.7/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
encodingNoEncoding type for binary data (default: hex)
parsedNoInclude parsed update data (default: true)
include_binaryNoInclude binary proof data (default: false)

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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

ParametersJSON Schema
NameRequiredDescriptionDefault
window_secondsYesTime window in seconds (1-600). Example: 300 for 5-minute TWAP
idsYesList of price feed IDs to get TWAP for
encodingNoEncoding type for binary data (default: hex)
parsedNoInclude calculated TWAP in parsed field (default: true)
ignore_invalid_price_idsNoIgnore invalid price IDs (default: false)
include_binaryNoInclude binary proof data (default: false)

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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

A3.5/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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

ActivityInactive
ResponsivenessSyncing

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

Related MCP Servers

  • A
    license
    A
    quality
    C
    maintenance
    Provides 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.
    17
    6
    MIT
  • F
    license
    Not graded
    quality
    D
    maintenance
    MCP server providing real-time crypto price feeds from Pyth Network, Chainlink, and Uniswap v3 10 tools for LLM agents and AI workflows.
  • A
    license
    A
    quality
    C
    maintenance
    Provides 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.
    13
    2
    MIT
  • A
    license
    Not graded
    quality
    C
    maintenance
    Enables 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

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