How do I use Orisha Data MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Orisha Data MCP show me the free preview for BTC-USD" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Orisha Data MCP

Official

by OrishaAI

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Orisha Data MCP

Client-side MCP wrapper for the public Orisha Data x402 endpoints.

Orisha Data provides machine-readable market-data endpoints over HTTPS with x402 payment support. This wrapper lets an MCP-capable client inspect free previews and discovery documents before making paid x402 calls.

Public Endpoints

Base URL: https://orisha-data.com

Tool	Public endpoint	Price	Notes
`orisha_docs`	`GET /docs`	Free	Machine-readable service docs.
`orisha_x402_discovery`	`GET /.well-known/x402`	Free	x402 resource discovery.
`orisha_signing_keys`	`GET /.well-known/orisha-signing-key.json`	Free	Public response-signing key set.
`orisha_c1_preview`	`GET /c1/preview/:pair`	Free	Unsigned sample for the C1 price endpoint.
`orisha_d1_preview`	`GET /d1/preview`	Free	Unsigned redacted D1 structure and freshness preview.
`orisha_c1_price`	`GET /c1/price/:pair`	$0.01	Paid x402 crypto/FX price response.
`orisha_d1_levels`	`GET /d1/levels`	$0.07	Paid x402 CME micro futures structural levels response.

D1 coverage window: Monday-Friday, 09:30-16:10 America/New_York. During active market windows, D1 may refuse overly stale data before payment instead of charging for unusable data.

Related MCP server: x402-api

Install

git clone https://github.com/OrishaAI/orisha-data-mcp.git
cd orisha-data-mcp
npm install

Run the free live smoke check:

npm run smoke

Run the MCP server over stdio:

npm run start

MCP Client Configuration

Example client configuration:

{
  "mcpServers": {
    "orisha-data": {
      "command": "node",
      "args": ["/absolute/path/to/orisha-data-mcp/src/server.mjs"],
      "env": {
        "ORISHA_DATA_BUYER_PRIVATE_KEY": "0xYOUR_BUYER_PRIVATE_KEY_PLACEHOLDER"
      }
    }
  }
}

The placeholder key above is intentionally not real. Use a buyer wallet only when you intend to call paid tools.

Free Evaluation Flow

An evaluating agent can try the service without payment:

Call orisha_docs to read the public service documentation.
Call orisha_x402_discovery to inspect the paid resource list.
Call orisha_c1_preview with BTC-USD, ETH-USD, or SOL-USD.
Call orisha_d1_preview to inspect D1 freshness and redacted structure.
Call orisha_signing_keys to fetch the public key set used for paid response verification.

Equivalent direct HTTPS checks:

curl -s https://orisha-data.com/docs
curl -s https://orisha-data.com/.well-known/x402
curl -s https://orisha-data.com/c1/preview/BTC-USD
curl -s https://orisha-data.com/d1/preview
curl -s https://orisha-data.com/.well-known/orisha-signing-key.json

Paid Usage

Paid tools require a buyer wallet private key in the MCP client process:

ORISHA_DATA_BUYER_PRIVATE_KEY=0xYOUR_BUYER_PRIVATE_KEY_PLACEHOLDER npm run start

Available paid tools:

orisha_c1_price: calls the C1 paid price endpoint for a requested pair.
orisha_d1_levels: calls the D1 paid levels endpoint.

Responses from paid tools may include _signature. Verify those signatures using the key set at /.well-known/orisha-signing-key.json.

Response Signing

The public signing key set is available at:

https://orisha-data.com/.well-known/orisha-signing-key.json

The key set currently contains orisha-response-ed25519-v1. Treat the endpoint as a key set from day one so future rotations can add keys without changing client assumptions.

Safety

This package is client-side only.
Free tools do not require a buyer key.
Paid tools require a buyer key and may spend USDC through x402.
Do not put production buyer keys in examples, screenshots, issues, or logs.

Available Tools

7 tools

orisha_c1_previewC1 PreviewB

Free unsigned sample response for the C1 crypto/FX price endpoint.

ParametersJSON Schema

Name	Required	Description	Default
`pair`	No	Trading pair such as BTC-USD, ETH-USD, or SOL-USD.	BTC-USD

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must cover behavior. It hints at no authentication ('unsigned') and no cost ('free'), but does not disclose whether data is static or dynamic, any limitations, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise (one sentence) with no fluff, but omits useful context such as response format or typical use cases, so it's not maximally informative.

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 no output schema and no annotations, the description is too sparse. It does not explain what the sample response contains, how it relates to the real endpoint, or any other contextual details needed for proper tool selection.

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 sole parameter 'pair' is fully described in the input schema with examples (BTC-USD, etc.). The tool description adds no further meaning beyond what the schema provides, so baseline score of 3 applies.

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 it provides a free unsigned sample response for the C1 crypto/FX price endpoint, distinguishing it from sibling tools like orisha_c1_price which presumably provides signed real data.

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 use for testing/demo ('free unsigned sample'), but does not explicitly state when to use this versus orisha_c1_price or other siblings, providing only indirect guidance.

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

orisha_c1_priceC1 Paid PriceC

Paid x402 call to the C1 crypto/FX price endpoint.

ParametersJSON Schema

Name	Required	Description	Default
`pair`	No	Trading pair such as BTC-USD, ETH-USD, or SOL-USD.	BTC-USD

TDQS

C2.9/5.0

Behavior2/5

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

The term 'Paid' implies cost but no details on cost structure, authentication, rate limits, or whether the call is destructive. No annotations exist to supplement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence, no wasted words. Could be more informative but is appropriately brief.

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?

No output schema, no return value description, and the 'x402' protocol is unexplained. Lacks essential context for a paid endpoint.

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 covers 100% of the single parameter 'pair' with examples. The description adds no extra meaning beyond the schema.

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 indicates it is a paid call to a price endpoint, and the title 'C1 Paid Price' reinforces this. It distinguishes from a preview sibling but lacks specificity about the exact data returned.

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?

No guidance on when to use this tool versus alternatives like orisha_c1_preview, nor any mention of prerequisites or cost implications.

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

orisha_d1_levelsD1 Paid LevelsB

Paid x402 call to the D1 CME micro futures structural levels endpoint.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3/5.0

Behavior2/5

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

The description only notes it is a paid call, lacking behavioral details such as authentication needs, rate limits, or side effects. No annotations exist to compensate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that efficiently conveys the core purpose, though it could be slightly expanded for clarity.

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?

The description omits any explanation of the output or the significance of the 'levels' data, leaving an agent without sufficient context for effective use.

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?

With zero parameters, the schema fully covers inputs. The description does not add parameter info, but none is needed; baseline of 4 is appropriate.

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 identifies the resource (D1 CME micro futures structural levels) and the paid nature (Paid x402 call), but does not explain what the tool returns or explicitly differentiate it from the preview sibling.

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?

No guidance on when to use this tool versus siblings like orisha_d1_preview; no prerequisites or usage context provided.

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

orisha_d1_previewD1 PreviewB

Free unsigned D1 structure and freshness preview with redacted level sample.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions 'free unsigned' and 'redacted level sample,' which suggest some constraints, but it does not clarify whether the tool is read-only, idempotent, requires authentication, or what happens on repeat calls. The behavioral traits are underspecified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, concise and front-loaded with the key action ('preview') and object ('D1 structure and freshness'). It is efficient but could be slightly more structured, though it 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?

Given the tool's simplicity (no parameters, no output schema, no annotations), the description is minimally adequate. However, it leaves terms like 'D1 structure,' 'freshness,' and 'redacted level sample' undefined, which might confuse some agents. Sibling tools offer context, but not enough for complete understanding.

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 input schema is empty (0 parameters), so schema coverage is 100% by default. According to the guidelines, this yields a baseline of 4. The description does not need to add parameter information, and it does not detract from clarity.

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 provides a 'free unsigned D1 structure and freshness preview with redacted level sample.' It uses specific verbs and resources ('preview', 'D1 structure', 'freshness'), and the context of sibling tools (orisha_c1_preview, orisha_d1_levels) helps distinguish it from similar tools.

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 does not provide any guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or context-based recommendations. The sibling tool names hint at differentiation but are not explicitly addressed.

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

orisha_docsOrisha Data DocsA

Fetch the free machine-readable Orisha Data documentation.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/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 full burden. It only states the action (fetch) and nature (free, machine-readable), but lacks details on authentication, rate limits, or behavior such as caching or error 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 and contains no unnecessary words. It efficiently communicates the tool's purpose.

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 description is adequate for a parameterless tool, but it does not specify the output format (e.g., file type, structure) or how the documentation is delivered, which would be helpful without an output schema.

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, so schema coverage is trivial. The description adds meaning by specifying the documentation is 'free machine-readable Orisha Data', which goes beyond the empty 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 tool fetches 'free machine-readable Orisha Data documentation'. The verb 'Fetch' and resource 'documentation' are specific, and it distinguishes from sibling tools that deal with previews, prices, levels, and signing keys.

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?

No explicit guidance on when to use this tool versus alternatives. However, the tool's purpose (fetching documentation) is distinct from siblings, so the context implies when to use it, but no exclusions or prerequisites are mentioned.

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

orisha_signing_keysOrisha Signing KeysB

Fetch the public response-signing key set.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior1/5

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

No annotations provided; description only says 'Fetch', implying read-only but fails to disclose any behavioral traits like authentication needs or rate limits.

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?

Single sentence, no wasted words, front-loaded with the action and resource.

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?

No output schema; description does not explain what the response contains (e.g., format of key set), leaving the agent uninformed about the tool's output.

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?

No parameters; schema coverage is 100% trivially. Baseline of 4 applies, but description adds no extra context about the returned key set.

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?

Description clearly states verb 'Fetch' and specific resource 'public response-signing key set', distinguishing it from sibling tools like orisha_c1_preview.

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?

No guidance on when to use this tool versus alternatives; missing context such as prerequisites or typical use cases.

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

orisha_x402_discoveryOrisha x402 DiscoveryB

Fetch the free x402 discovery document.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavior. It only states 'Fetch', implying a read-only operation, but omits any info about side effects, rate limits, or document size. Minimal transparency.

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?

One short, front-loaded sentence. No wasted words. Perfectly concise.

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 is simple with zero parameters and no output schema, so the description is minimally adequate. However, lacking context on what the document is used for or how it relates to sibling tools leaves room for improvement.

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?

No parameters exist, so schema coverage is 100% trivially. The description adds no parameter meaning, but none is needed. Baseline 4 is appropriate.

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 uses the specific verb 'Fetch' and identifies the resource as 'free x402 discovery document', which is clear and distinct from sibling tools. However, it does not explain what 'x402' or 'discovery document' means, leaving some ambiguity.

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?

No guidance on when to use this tool versus its siblings (e.g., orisha_docs, orisha_signing_keys). The agent receives no context about prerequisites or scenarios.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv0.1.0Jul 16, 2026
- First observedorisha_c1_preview
- First observedorisha_c1_price
- First observedorisha_d1_levels
- First observedorisha_d1_preview
- First observedorisha_docs
- First observedorisha_signing_keys
- First observedorisha_x402_discovery

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation4/5

Tools are mostly distinct, but the preview and paid pairs for C1 and D1 endpoints could cause confusion if an agent doesn't read descriptions carefully. The informational tools (docs, signing keys, x402 discovery) are clearly distinct.

Naming Consistency5/5

All tools follow a consistent 'orisha_{service}_{type}' pattern in snake_case, making it easy to predict tool names.

Tool Count5/5

With 7 tools, the server is well-scoped for its domain, providing necessary preview, paid, and informational tools without bloat.

Completeness4/5

Core operations are covered, but missing a tool for listing available symbols or metadata could limit functionality.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Market Data B
com.timzinin.api
33 pay-per-call market and news data tools over MCP with free discovery and x402 payments.
Finance Cryptocurrency
362
HYPERneobroker.com A
com.hyperneobroker.mcp
Live prices, perps, prediction markets and a paper trading desk over one MCP.
Finance Cryptocurrency
61
Cryptohopper Market DataOAuth
com.cryptohopper
Real-time crypto market data: candles, tickers, orderbooks across 13+ exchanges via MCP.
Cryptocurrency Finance
2
Concierge Intel B
xyz.conc-exe
Pay-per-call DeFi and macro intel for AI agents. x402 USDC tools via streamable HTTP /api/mcp.
Finance Blockchain
2

Related MCP Servers

market-data-mcp
SmashToes
-
license
Not graded
quality
Not graded
maintenance
Real-time financial market data MCP server. Stocks, crypto, technicals, sentiment, FDA calendar. No API keys required.
Updated 7 months ago (2026-02-15 04:09 UTC)
-
x402-api
Blockchain Cryptocurrency Finance
fernsugi
A
license
A
quality
D
maintenance
MCP server for pay-per-call DeFi and crypto data via x402 micropayments on Base. 8 endpoints: token prices, TVL, funding rates, token security, gas tracker, whale monitoring, wallet profiling, and yield scanning.
Updated 6 months ago (2026-03-12 10:45 UTC)
8
51
MIT
headless-oracle
Finance Blockchain Autonomous Agents
LembaGang
A
license
Not graded
quality
C
maintenance
Cryptographically signed market state verification for autonomous financial agents. Ed25519 receipts, fail-closed safety, 28 global exchanges (equities, derivatives, 24/7 crypto). MCP-native, x402-payable, SMA Protocol conformant.
Updated 20 days ago (2026-08-17 21:07 UTC)
MIT
carbon-cashmere-mcp
Cryptocurrency Finance AI & Machine Learning
CarbonCashmere
A
license
Not graded
quality
D
maintenance
Crypto intelligence MCP: 104 tools for market data, ML signals, on-chain analytics, derivatives, and Bittensor subnets. Pay-per-call via x402 USDC on Base/Solana/Algorand/Stellar or $9.99/mo API key.
Updated 4 months ago (2026-05-17 11:18 UTC)
MIT

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/OrishaAI/orisha-data-mcp'

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