oracle-feeds-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.1
Disambiguation5/5
Each tool targets a distinct resource and action: Chainlink discovery, latest price, historical round; Pyth discovery, latest price, historical timestamp; and chain listing. No two tools overlap in purpose.
Naming Consistency5/5
All tool names follow a consistent camelCase verb_noun pattern (list, get, search) with clear network prefixes (Chainlink, Pyth). The naming is uniform and predictable.
Tool Count5/5
7 tools is well-scoped for an oracle feed server, covering both Chainlink and Pyth with discovery, latest, and historical data operations. No redundancy or bloat.
Completeness5/5
The tool surface covers the full price-feed lifecycle for both networks: discovery, latest lookup, and historical retrieval. The only minor gap—Chainlink historical by timestamp—is inherent to Chainlink's API, not an omission.
Average 3.9/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on August 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the staleness flag based on a 1-hour threshold, which is helpful. However, it does not mention return format, error behavior for unsupported chains/pairs, or whether the operation is read-only, leaving notable gaps.
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?
Two sentences, front-loaded with the primary action, and no filler. Every phrase earns its place, including the staleness behavior.
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?
The tool has no output schema, so the description should clarify return values. It only mentions staleness flagging, not the price payload or units. Also, a brief pointer to getChainlinkRoundPrice for historical rounds would improve completeness, but for a simple two-param fetch, it is minimally adequate.
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 already documents both parameters. The description adds an example (ETH/USD on ethereum) but no extra constraints or format details. The baseline 3 is appropriate because the description does not compensate beyond what schema provides.
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 fetches the latest on-chain Chainlink price for a pair on a supported chain, with a concrete example. It is differentiated from Pyth tools by name, but not explicitly distinguished from the sibling getChainlinkRoundPrice, so it loses full marks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for getting the latest price, but provides no explicit guidance on when to use this over getChainlinkRoundPrice or listChainlinkFeeds. It also does not mention any prerequisites or exclusions, leaving the context partially implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that it 'fetches' data, implying a read operation, but does not mention response format, error behavior, rate limits, or validation of feed IDs. This is a significant gap for a tool with no safety annotations.
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 two sentences: the first front-loads the action and parameter options, the second adds useful context about Pyth's catalog. There is no wasted wording, and every sentence earns its place.
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 simple one-parameter tool without an output schema, the description explains the purpose and broader asset coverage. However, it does not describe the return structure (e.g., price value, confidence, timestamp), which is important for a price-fetching tool. This gap makes the description adequate but not fully complete.
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 coverage is 100%, with 'symbol' described as a symbol or 64-hex-char feed ID. The description essentially repeats the schema text, adding no new parameter semantics. The mention of 'raw Pyth feed ID' is already present in the schema, so no additional value is provided.
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 tool fetches the latest price from Pyth Network's Hermes API for a symbol or raw feed ID. It distinguishes itself from siblings by explicitly mentioning Pyth and its broader asset coverage compared to Chainlink, making the tool's specific role unambiguous.
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 when to use this tool: when needing latest prices for assets beyond Chainlink's catalog, noting Pyth's broader coverage. It doesn't explicitly name alternative tools or provide exclusions, but the context is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds useful detail by describing it as a 'real historical lookup' and naming the underlying function getRoundData, which clarifies the semantics. However, it lacks information on return format, potential errors (e.g., invalid roundId), or access limitations.
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, well-structured sentence that front-loads the core purpose and the key differentiator. Every word earns its place; there is no redundancy or fluff.
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 simple read tool with complete schema descriptions, this is adequate but not fully complete. It clearly conveys the tool's scope and when not to use it, but because there is no output schema, it would benefit from mentioning what the returned round data contains (e.g., price, timestamp). The description does not cover error behavior or edge cases, though these may be less critical for this tool type.
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 already covers all three parameters with descriptions (100% coverage). The description only reinforces the role of roundId by tying it to getRoundData(roundId), which adds minimal value beyond the schema. Baseline score of 3 is appropriate.
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 tool 'Fetches a specific historical Chainlink round via getRoundData(roundId)' — a specific verb, resource, and method. It also distinguishes itself from the latest-round sibling by explicitly noting it is 'not a re-fetch of the latest round.'
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 provides clear usage context by stating this is for historical lookups and explicitly excluding the latest-round case. It implies the alternative getChainlinkPrice for latest data but does not name it directly. No other usage prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. The verb 'fetches' implies a read-only operation, but it does not disclose potential errors, return format, or any edge-case behavior. It adds minimal context beyond what the name already implies.
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?
A single, front-loaded sentence with no wasted words. It conveys the essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter historical price fetch, the description is adequate. While no output schema exists, the return type (price) is strongly implied by the tool name and description. The differentiation from siblings is clear via the 'Historical' qualifier in the name.
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 coverage is 100%, so the baseline is 3. The description's mention of 'unix timestamp (seconds)' is redundant with the schema's 'Unix timestamp in seconds', adding little value. It does reinforce the 'as of' relationship, but not enough to exceed the baseline.
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 tool fetches Pyth's price at a specific unix timestamp, using a specific verb ('fetches') and resource. It distinguishes itself from siblings like getPythPrice by explicitly mentioning the historical aspect.
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 context is clear: this is for historical prices at a given timestamp, which inherently contrasts with getPythPrice (current price). However, it does not explicitly name alternatives or exclusions, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It mentions 'live feed catalog' and 'symbol substring', implying a read-only search operation, but it does not describe return format, pagination, rate limits, or any caveats about the live nature of the data. This is adequate but not rich.
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 two sentences with no filler. It front-loads the primary action and provides one practical example, then gives a secondary usage hint. Every word contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter search tool with no output schema, the description covers the essential purpose and the use case. It could be improved by mentioning what the result looks like (e.g., a list of feed symbols), but given the simplicity and sibling context, it is nearly complete.
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 already covers the singular parameter 'query' with the description 'Symbol substring to search for'. The tool description adds examples ('SOL' or 'gold') and the term 'substring', which are helpful but not essential. Since schema coverage is 100%, the description adds only marginal value beyond what's in the schema.
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 verb 'Searches' and the specific resource 'Pyth Network's live feed catalog' with a matching method (symbol substring). It also distinguishes itself from sibling tools by explicitly noting it goes 'beyond this server's curated Chainlink list', making its purpose unambiguous.
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 provides a clear use case: 'Useful for discovering feed coverage beyond this server's curated Chainlink list.' This implies when to use it (for exploring Pyth feeds not in the local list). It doesn't explicitly name alternative tools or state exclusions, but the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It conveys that the tool returns a list of blockchain networks, which implies a read-only operation, but does not describe details like sorting, filtering, or whether the list is exhaustive. For a simple list tool, this is adequate but minimal.
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, concise sentence that front-loads the verb and resource. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema, no annotations), the description is complete enough for an agent to understand what the tool does. It could mention return format or item details, but for a basic chain-listing tool, the provided context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms this with 100% coverage. According to the rubric, 0 params gets a baseline of 4. The description adds no parameter details because none are needed.
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 ('Lists'), the resource ('blockchain networks with curated Chainlink feed coverage'), and the scope ('in this server'). This directly distinguishes it from siblings like listChainlinkFeeds (which lists feeds) and Pyth-related tools, making the purpose unmistakable.
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 provides sufficient context for when to use this tool: when you need to know which blockchain networks have Chainlink feed coverage available. It doesn't explicitly name alternatives or exclusions, but the 'curated Chainlink feed coverage' wording naturally separates it from Pyth alternatives. The intended use is implied clearly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It clearly states the operation is a read-only listing with no side effects, but it does not describe the return format, size, or any edge cases. This is adequate for a simple list tool but lacks deeper behavioral disclosure beyond what the description states.
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?
A single sentence that is front-loaded with the verb and resource, and contains no filler or redundant information. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema list tool, the description is fully sufficient. It states exactly what is listed and the scope ('curated registry'), leaving no ambiguity about the tool's function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters and schema coverage is 100% with no properties. Per the rubric, a baseline of 4 is granted for zero-parameter tools. The description adds no parameter details, but none are needed.
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 uses the specific verb 'Lists' and clearly identifies the resource as 'all supported chains and Chainlink pairs' within 'this server's curated registry'. It distinguishes itself from siblings like getChainlinkPrice (which fetches prices) and listSupportedChains (which lists only chains).
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 provides clear context that this is a discovery tool for available chains and Chainlink pairs, implying use before price queries. It does not explicitly exclude alternatives, but the scope is obvious given the sibling tools. A 4 is appropriate for clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![oracle-feeds-mcp MCP server](https://glama.ai/mcp/servers/rileybuilds/oracle-feeds-mcp/badges/card.svg)](https://glama.ai/mcp/servers/rileybuilds/oracle-feeds-mcp)

Score Badge

Copy to your README.md:

[![oracle-feeds-mcp MCP server](https://glama.ai/mcp/servers/rileybuilds/oracle-feeds-mcp/badges/score.svg)](https://glama.ai/mcp/servers/rileybuilds/oracle-feeds-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/rileybuilds/oracle-feeds-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server