pyth-hermes-mcp

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It successfully communicates the deprecated status (critical behavioral trait) and mentions it retrieves Pyth prices, but fails to disclose other behavioral details like rate limits, caching behavior, error handling for invalid IDs, or whether the data is real-time.

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 suffers from significant redundancy, repeating the deprecation notice twice with identical markdown formatting ('**Deprecated...**'). The '[DISCOVERY]' prefix appears to be metadata noise. While the core functional description is concise (two sentences), the wasteful repetition and tags hurt the structure.

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 output schema, the description minimally hints at return values by mentioning 'Pyth price', but does not describe the response structure. For a deprecated tool with well-documented inputs, this is adequate but incomplete—missing details on the price update object structure or the difference between binary and verbose modes beyond the parameter names.

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, documenting all three parameters (ids[], binary, verbose) including array notation and boolean purposes. The description mentions 'a collection of price feed ids' which aligns with the ids[] parameter but adds no semantic detail beyond what the schema already provides, warranting the baseline score of 3.

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 'Get[s] the latest price updates by price feed id' and retrieves 'the latest Pyth price for each price feed', specifying the action, resource, and domain (Pyth). However, it lacks explicit differentiation from the similarly-named sibling 'latest_price_updates', other than the deprecated status.

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 the tool is deprecated and specifies the replacement path ('use /v2/updates/price/latest instead'), providing clear guidance on when not to use this tool and what alternative to use. It lacks additional guidance on prerequisites or specific use-case scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It compensates by detailing the complete nested return structure (binary and parsed fields), but lacks operational context such as authentication requirements, rate limits, error handling behavior, or what constitutes an 'invalid price ID'.

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 opens with redundant repetition ('Get... — Get...'). The return value is presented as an unreadable inline JSON blob rather than structured prose, making it difficult to parse. Every sentence exists for a reason, but the formatting and repetition significantly degrade clarity.

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 an output schema, the description manually includes the return structure, which provides necessary completeness. However, for a 4-parameter tool with nested return objects and no annotations, the description should additionally cover error scenarios, authentication, or side effects to be fully complete.

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%, providing detailed descriptions for all four parameters including the query string format for 'ids[]'. The description mentions 'collection of price feed ids' but does not add semantic meaning beyond what the schema already provides, warranting the baseline score.

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 'the latest Pyth price for each price feed' given a collection of IDs, using specific verbs and resources. However, it does not differentiate from the sibling tool 'latest_price_feeds', leaving ambiguity about which 'latest' tool to use.

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 siblings like 'timestamp_price_updates' (historical) or 'latest_price_feeds'. There are no stated prerequisites, exclusions, or conditions that would help an agent select this tool correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It defines the return structure (binary vs parsed formats) inline, but omits safety characteristics (read-only status), error conditions, or rate limiting information.

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 compact at two sentences, front-loading the purpose and appending the return type structure. The embedded return-type JSON is dense but necessary given the absence of a structured output_schema.

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 getter with two optional parameters, the description is adequate. It compensates for the missing output_schema by documenting the return structure inline. However, it lacks safety assertions (e.g., confirming idempotency) that would complete the picture for a stateless read operation.

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?

Input schema has 100% description coverage, establishing a baseline of 3. The main description adds no parameter-specific details (e.g., valid encoding values, syntax), relying entirely on the schema descriptions which adequately document the two optional parameters.

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'), recency ('most recent'), and specific resource ('publisher stake caps update data'). While it does not explicitly differentiate from price-feed siblings, the distinct resource name makes the scope clear.

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 siblings like latest_price_feeds or latest_price_updates. There are no prerequisites, filtering recommendations, or alternative suggestions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure; it successfully communicates the deprecated status and the conceptual return value (set of IDs), but lacks details about response format, authentication requirements, or rate limiting that would be necessary for full transparency. The deprecation warning is the primary behavioral trait disclosed.

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?

While the description efficiently communicates the core purpose and deprecation status, it suffers from redundant repetition of the deprecation notice ('**Deprecated...** — **Deprecated...**') and prefix tags that reduce clarity; however, it remains relatively brief and front-loaded with critical status 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 tool's deprecated status, lack of parameters, and absence of an output schema, the description adequately covers the essential information needed for an agent to understand its purpose and current obsolescence, though it could be improved by describing the expected return structure since no output schema exists to document it.

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 zero input parameters and 100% schema description coverage (trivially satisfied by the empty object schema), the description appropriately requires no additional parameter explanation, meeting the baseline expectation for such simple tools.

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 identifies the action 'Get the set of price feed IDs' and the resource being fetched, distinguishing it from sibling tools that retrieve actual price data or metadata rather than just identifiers. The '[DISCOVERY]' tag and deprecation notice further clarify its specific role as a legacy discovery endpoint.

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 by directing users to '/v2/price_feeds instead' and marking the tool as deprecated, clearly indicating when not to use this tool and what alternative to prefer. This satisfies the requirement for explicit when/when-not guidance with named alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries full burden. It mentions fetching data but lacks disclosure about pagination, rate limits, authentication requirements, or what happens with large result sets. 'Fetches all' implies comprehensiveness but doesn't clarify performance implications.

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?

Significant redundancy: the sentence 'Get the set of price feeds' appears verbatim twice at the start. The dash/em-dash usage suggests concatenated text. The content could be compressed to two sentences without losing 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?

No output schema exists, yet the description fails to explain what data structure or fields are returned (e.g., feed IDs, symbols, metadata fields). For a retrieval tool with no annotations, the description should compensate by describing the return payload, which it doesn't.

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, the schema fully documents both parameters (query and asset_type). The description merely restates that filtering is possible without adding syntax details, examples, or semantic context beyond the schema definitions. Baseline 3 is appropriate.

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 it fetches price feeds from the Pyth network (clear verb+resource), but fails to distinguish what 'metadata' means compared to sibling tools like 'latest_price_feeds' or 'price_feed_ids'. The repetition of 'Get the set of price feeds' wastes space without adding clarity.

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 like 'latest_price_feeds' or 'price_feed_ids'. The description only mentions the filtering capability without explaining selection criteria or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and succeeds in disclosing key behavioral traits: the automatic connection closure after 24 hours for resource management and the requirement for reconnection logic. It also includes a partial output schema structure in the Returns section, revealing the shape of binary and parsed data fields that would otherwise be unknown.

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 suffers from structural defects: the opening phrase is duplicated verbatim, and the Returns JSON blob appears truncated (missing closing braces). While the middle section containing the 24-hour timeout warning is valuable and concise, the repetition and apparent truncation waste space and create parsing confusion.

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 streaming tool with six parameters and no structured output schema, the description adequately covers the connection lifecycle and provides partial output structure. However, it lacks error handling documentation (what happens if ids are invalid and ignore_invalid_price_ids is false?) and does not clarify the streaming contract (initial snapshot vs. delta updates).

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, documenting all six parameters including the required ids[] array and optional filters like benchmarks_only. Since the schema comprehensively documents inputs, the baseline score applies. The description adds no additional parameter semantics beyond the Returns hint about parsed vs binary output formats, which corresponds to the 'parsed' parameter.

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 identifies the tool as an 'SSE route handler for streaming price updates,' specifying both the protocol (Server-Sent Events) and the resource (price updates). This distinguishes it from request-response siblings like latest_price_feeds. However, the opening sentence is unnecessarily repeated, slightly undermining professionalism.

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 critical operational guidance about the 24-hour connection timeout and the necessity for client-side reconnection logic. However, it fails to specify when to choose this streaming approach versus polling alternatives like latest_price_updates or latest_price_feeds, leaving the selection criteria ambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations are provided, the description carries the full burden. It compensates well for the lack of output schema by documenting the complete return structure (binary and parsed formats). However, it omits other behavioral traits like rate limits, caching, or the specific semantic that it returns the first update >= timestamp rather than all updates.

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 opens with exact duplication of the same sentence, indicating poor editing or concatenation errors. While the Returns section is informationally dense, the front-loaded repetition wastes context window space and reduces clarity.

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 output schema, the inclusion of the return type structure is necessary and helpful. However, the description leaves gaps regarding the tool's specific value proposition (timestamp-based historical lookup) and operational constraints. Adequate but not comprehensive.

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, the structured definitions already explain all five parameters clearly (including the query string example for `ids[]`). The description adds no additional parameter semantics beyond what the schema provides, meeting the baseline expectation.

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 repeats itself wastefully ('Get the latest price updates by price feed id. — Get the latest price updates...'). More critically, it uses the term 'latest' which conflicts with the tool's actual behavior: the required `publish_time` parameter finds the first update at or after a specific timestamp, not the absolute latest price. It fails to differentiate from siblings like `latest_price_updates`.

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 provided on when to use this timestamp-based query versus the sibling `latest_price_updates` or `latest_price_feeds`. Does not explain that this tool is specifically for historical/timestamp-bound queries rather than real-time latest prices.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.