MCP server providing tools for the Pyth Network Hermes API, enabling access to real-time market data including price feeds, updates, and time-weighted average prices (TWAP)
The server provides 5 well-structured tools for Pyth Network price data access. Tool names follow verb_noun convention (get_*) and are clear about their intent. All tools have descriptions (90-150 chars, within acceptable range). Input schemas are present and properly typed with enums for constrained options. However, there are notable gaps: output schemas are not documented, error handling is basic (returns generic error objects), and parameters lack some constraints. The FastMCP implementation shows good httpx error handling, but response field naming and chaining support could be improved.
Get the latest price updates for specific Pyth Network price feed IDs
Search and filter Pyth Network price feeds by symbol or asset type
Get historical Pyth Network price updates at or after a specific timestamp
Get the most recent publisher stake caps data from Pyth Network
Get the latest time-weighted average price (TWAP) from Pyth Network with a custom time window
Output schemas not documented. LLMs cannot plan downstream calls or extract specific fields from price updates, binary proofs, or parsed data structures.
Error responses are generic dict objects with 'error' key containing plain text. No recovery guidance or error classification (retryable vs fatal). Errors like 'HTTP error occurred: <str(e)>' provide no actionable direction for agents.
Parameters 'encoding', 'parsed', 'ignore_invalid_price_ids', 'include_binary' are repeated across 4 tools. Could benefit from batch/filtering tools or shared configuration to reduce redundancy.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Parameter descriptions lack detail on expected data structure and format. E.g., 'ids' parameter does not specify what a price feed ID looks like (hex string? uuid? length constraints?). 'publish_time' says 'Unix timestamp in seconds' but does not clarify the acceptable range or precision.
get_twap_latest has window_seconds constrained to 1-600, but the description does not explain what happens if the window is too small (insufficient data) or too large (default to max?). No guidance on how TWAP is calculated or what 'parsed' means in the response.