Fetch current Pyth price, confidence interval, EMA, exponent, publish time, and staleness for a symbol or feed ID, with optional cache and stale-data controls.
Get the latest Pyth price, confidence interval, EMA price, exponent, publish time, and staleness for one symbol or feed id.
| Name | Required | Description | Default |
|---|---|---|---|
| feed | Yes | ||
| cache_ttl | No | ||
| allow_stale | No | ||
| force_refresh | No |
Changes observed during successful MCP inspections.
v0.1.3Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It lists return values but says nothing about caching behavior, staleness policy, permission needs, rate limits, or what the boolean control parameters actually change.
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?
A single dense sentence that front-loads the primary return fields and ends with the scoping constraint. No wasted text.
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?
With no output schema, no annotations, and four undocumented parameters, the description should explain return shape and at least the caching/staleness controls. It covers the return values but leaves the behavioral and parameter semantics materially incomplete.
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 0%. The description adds useful meaning for 'feed' (symbol or feed id), but it leaves cache_ttl, allow_stale, and force_refresh completely unexplained even though their behavior affects how fresh or cached the returned price is.
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?
States a specific verb ('Get'), a specific resource ('latest Pyth price'), and enumerates the returned data fields. The 'one symbol or feed id' scope also cleanly distinguishes it from the plural sibling pyth_get_prices.
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 phrase 'for one symbol or feed id' implies single-feed usage versus the plural pyth_get_prices sibling, but no alternative is named explicitly and there are no when-to-use or when-not-to-use rules. The guidance is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.