Which integrations are available for this server?

Provides tools for querying consolidated Bitcoin pricing, funding-rate skew, ML signals, sentiment snapshots, and natural-language market briefings from the BPE market-data API.

How do I use BPE MCP Server?

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., "@BPE MCP Server what's the current Bitcoin price?" 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.

BPE MCP Server

by bxetech

Overview Schema Related Servers Score Discussions

TypeScript

Remote

BPE MCP Server

Model Context Protocol server for the BPE market-data API. Lets Claude Desktop, Cursor, Goose, and other MCP-enabled agents query consolidated Bitcoin pricing, ML signals, funding-rate skew, and natural-language market briefings — without writing any HTTP boilerplate.

Status: v0.2 — five tools, local stdio transport, no LLM calls inside the briefing endpoint (template-rendered). API key required.

Listed in the official MCP Server Registry as io.github.bxetech/bpe-mcp. Install via npm install -g @bxetech/bpe-mcp or npx -y @bxetech/bpe-mcp.

Why use it

If you're building an agent that touches Bitcoin markets, you have two options today:

Talk to 36 different exchange APIs directly. Each has a different schema, different auth, different rate limits, different reliability. Your agent burns tokens reasoning over inconsistent payloads.
Use one consolidated source. BPE aggregates all 36 venues into a single normalised feed with derived signals (ML predictions, sentiment, funding skew, basis). One auth, one schema, one tool call.

This MCP server is option 2 dressed up as native tools your agent can discover and call.

Related MCP server: mcp-blockstream-info

Tools (v0.2)

Tool	What it does
`get_consolidated_price`	Current BTC price aggregated across the BPE network
`get_market_briefing`	~4 lines (brief) or 6–8 (detailed) natural-language summary — price, funding skew, ML signal, sentiment, anomalies
`get_funding_skew`	Per-venue annualised funding rates + max-spread pair
`get_ml_signal`	Current ML prediction (direction, probability, confidence) at the requested horizon
`get_sentiment_snapshot`	Crypto Fear & Greed index, news sentiment, mempool stress

Install

npm install -g @bxetech/bpe-mcp

Or use npx with no install (recommended for Claude Desktop):

// ~/Library/Application Support/Claude/claude_desktop_config.json
{
  "mcpServers": {
    "bpe": {
      "command": "npx",
      "args": ["-y", "@bxetech/bpe-mcp"],
      "env": {
        "BPE_API_KEY": "bpe_..."
      }
    }
  }
}

Restart Claude Desktop. The five tools appear under the MCP server picker.

Configuration

Env var	Default	Notes
`BPE_API_KEY`	(required)	Get one at https://bxetech.com/contact
`BPE_BASE_URL`	`https://mcp.bxetech.com`	Override for self-hosted / local dev
`BPE_TIMEOUT_MS`	`5000`	Per-request timeout

Local development

git clone https://github.com/bxetech/bpe-mcp
cd bpe-mcp
npm install
npm run build
BPE_API_KEY=... npm run dev

To dogfood in Claude Desktop while iterating, point at the local build:

{
  "mcpServers": {
    "bpe-dev": {
      "command": "node",
      "args": ["/abs/path/to/mcp-server/dist/index.js"],
      "env": {
        "BPE_API_KEY": "...",
        "BPE_BASE_URL": "http://localhost:8082"
      }
    }
  }
}

Roadmap

v0.2 — get_sentiment_snapshot ✅, friendly tier-aware errors ✅, timestamped briefings ✅
v0.3 — get_basis, subscribe_alert (webhook subscription), hosted HTTP transport for non-developer install (Cursor extension, ChatGPT Desktop)
v0.4 — Optional LLM-rendered briefing via Haiku (richer prose, with per-call cost)

See docs/research/AGENT_INTEGRATION_AND_MONETISATION_2026-04-27.md for the broader product / monetisation plan.

License

MIT — see LICENSE.

Available Tools

5 tools

get_consolidated_priceA

Get the current consolidated Bitcoin price aggregated across the BPE exchange network. Returns price in USD, the number of contributing exchanges, and freshness in milliseconds. Use this when an agent or user asks 'what's the BTC price right now?' — it's faster and more authoritative than calling any individual exchange.

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	No	Trading pair. Currently only BTC-USD is supported.	BTC-USD

TDQS

A4/5.0

Behavior3/5

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

Discloses it is a read operation aggregating data, returns specific fields. No annotations exist, so description carries full burden. Could mention rate limits or behavior if network is unavailable, but the information provided is adequate for a simple read tool.

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, each earning its place: first defines purpose and returns, second gives usage guidance. No fluff, front-loaded.

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 (1 param, no output schema, no annotations), the description covers purpose, returns, and usage context adequately. Minor gap: no mention of what 'freshness in milliseconds' implies or if it's a public 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 coverage is 100% with description for the single parameter. The tool description does not add additional meaning beyond the schema (e.g., format or constraints), so baseline 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 it gets the consolidated Bitcoin price aggregated across the BPE network, returns price in USD, contributor count, and freshness. This is distinct from sibling tools which focus on sentiment, market briefing, funding skew, and ML signals.

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?

Provides explicit when-to-use guidance: 'when an agent or user asks what's the BTC price right now?' and contrasts with individual exchange calls as slower/less authoritative. Does not list exclusions but sufficiently narrows usage.

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

get_funding_skewA

Get current perpetual-futures funding rates across major venues, plus the max-spread pair. Annualised. Useful for assessing perp-perp arbitrage conditions, basis trades, and overall positioning skew — high spread = stretched positioning on one side. Returns a sorted table.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior3/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 discloses the return format as a 'sorted table' and mentions annualised rates. However, it omits details like data freshness, sources, or error handling, which would be helpful for a read-only tool.

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 concise: two sentences front-loaded with purpose and usage context, with a brief note on return format. Every sentence adds value without redundancy.

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?

With no output schema, the description's mention of a 'sorted table' is vague. It lacks specifics on columns, which venues are considered 'major', or whether the data is real-time. For a tool with no parameters, more detail about the output would improve completeness.

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 has zero parameters, so the description does not need to add parameter info. The tool is parameterless, and the description's mention of 'across major venues' implies no filtering, which is consistent.

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 retrieves perpetual-futures funding rates across major venues, including the max-spread pair, and notes they are annualised. This distinguishes it from sibling tools like get_sentiment_snapshot or get_consolidated_price.

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 explicit use cases: assessing perp-perp arbitrage conditions, basis trades, and overall positioning skew, with a hint that high spread indicates stretched positioning. It does not explicitly state when not to use, but the context is clear.

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

get_market_briefingA

Get a concise natural-language summary of the current Bitcoin market state. Synthesises consolidated price, funding-rate skew across major perpetual venues, current ML prediction, and sentiment indicators. 'brief' mode returns roughly 4 lines (price, funding skew, ML signal, sentiment); 'detailed' adds per-venue funding breakdown and ML sub-model details — typically 6-8 lines. This is the most token-efficient way for an agent to get the 'what's happening right now' picture — replaces 4-5 raw data calls plus the reasoning to summarise them.

ParametersJSON Schema

Name	Required	Description	Default
`verbosity`	No	'brief' returns a 5-line headline summary; 'detailed' adds per-venue and multi-horizon breakdowns.	brief

TDQS

A4.6/5.0

Behavior4/5

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

No annotations exist, so the description carries full burden. It explains the tool's behavior: returns a natural-language summary with two verbosity levels and typical line counts. It does not discuss data freshness, latency, or error handling, but the behavior is straightforward and well-described.

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 concise (4 sentences) and front-loaded with the core purpose. Every sentence adds value, clearly explaining the tool's function and modes without redundancy.

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 (one optional parameter) and lack of output schema, the description covers the main aspects: data sources, modes, output length. It could mention error cases or data freshness, but is complete enough 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?

Schema description covers 100% of the parameter, but the tool description adds meaning by detailing what each verbosity value yields ('brief returns roughly 4 lines...', 'detailed adds per-venue breakdown...'). This enriches the schema's enum descriptions.

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's purpose: 'Get a concise natural-language summary of the current Bitcoin market state.' It specifies the data sources it synthesizes and distinguishes between two modes (brief and detailed). The sibling tools are individual raw data calls, so this tool is well-differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises when to use this tool: 'the most token-efficient way for an agent to get the "what's happening right now" picture — replaces 4-5 raw data calls plus the reasoning to summarise them.' This provides clear guidance against alternatives.

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

get_ml_signalA

Get the current ML prediction for a specified time horizon. Returns direction (up/down/flat), confidence (0-1), and detected market regime (low/medium/high volatility). The model is a calibrated gradient-boosted classifier trained on a broad feature set including order book imbalance, cross-exchange spreads, sentiment, derivatives, and momentum.

ParametersJSON Schema

Name	Required	Description	Default
`horizon`	No	Prediction horizon. Shorter horizons are more reactive; longer horizons are more stable. Available horizons may evolve over time — the tool will report which horizons are currently served if a requested one is unavailable.	30s

TDQS

A4/5.0

Behavior4/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 details the model type, feature set, and return fields (direction, confidence, regime), and notes horizon evolution behavior. It does not mention auth or rate limits, but for a read-only prediction tool this is adequate.

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, no wasted words. Front-loaded with the primary action, then model details. Efficient and clear.

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?

With one parameter, no output schema, and no annotations, the description sufficiently covers what the tool returns and the model context. It is complete enough for an agent to invoke correctly, though an explanation of output structure could slightly improve.

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% for the single parameter 'horizon', explaining its behavior and fallback. The tool description adds no extra meaning beyond the schema, so baseline 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 'Get the current ML prediction for a specified time horizon', with a specific verb and resource. It is distinct from sibling tools like get_sentiment_snapshot or get_consolidated_price.

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 ML signals but does not explicitly state when to use this tool versus alternatives. No exclusions or when-not guidance are provided.

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

get_sentiment_snapshotA

Get current Bitcoin market sentiment indicators. Returns Crypto Fear & Greed index (0-100, with label), FinBERT news sentiment (-1 most bearish to +1 most bullish, scored from CoinDesk + Cointelegraph headlines), Google Trends search interest (0-100, baseline 50), and a composite score (-1 to +1) blending all three. Useful for contextualising price action, detecting positioning extremes that may precede reversals, and as a coarse macro filter for shorter-horizon ML signals. Individual indicators are omitted when their upstream collector hasn't run yet.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/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 behavioral traits such as the ranges of each indicator and that individual indicators may be omitted if upstream collectors haven't run. This adds value beyond the empty schema.

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 concise (~4 sentences), front-loaded with the purpose, and every sentence adds value. No redundancy or unnecessary details.

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 tool with no parameters, no output schema, and no annotations, the description is sufficiently complete. It explains all return components, their ranges, sources, and a behavioral note about missing indicators.

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 has zero parameters and 100% schema description coverage, so the baseline is 4. The description adds no parameter information because none exist.

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 'Get' and the resource 'current Bitcoin market sentiment indicators', listing specific indicators and distinguishing it from sibling tools (price, briefing, funding, ML signal). It is not a tautology and provides a precise purpose.

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 mentions use cases such as 'contextualising price action', 'detecting positioning extremes', and 'as a coarse macro filter for shorter-horizon ML signals', providing clear context. However, it does not explicitly contrast with sibling tools or state when not to use it.

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.

5 tool updatesv0.2.1Jul 28, 2026
- First observedget_consolidated_price
- First observedget_funding_skew
- First observedget_market_briefing
- First observedget_ml_signal
- First observedget_sentiment_snapshot

Install Server

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

TDQS

A4.3/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: price, sentiment, funding, ML prediction, and a synthesized briefing. There is no overlap, as each addresses a different aspect of market data.

Naming Consistency5/5

All tools follow a consistent get_<noun> pattern in snake_case, making it easy to infer their function from the name.

Tool Count5/5

With 5 tools, the server is well-scoped for providing key Bitcoin market insights without being overwhelming or too sparse.

Completeness4/5

The set covers price, sentiment, funding, ML signals, and a summary, but lacks direct access to order book or historical data, which are minor gaps for some analysis tasks.

Maintenance

ActivityInactive

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

SatoshiAPI — Bitcoin Intelligence via Lightning A
io.satoshiapi
Bitcoin intelligence API. Pay per call via L402 Lightning (10-200 sats). No accounts needed.
Blockchain Cryptocurrency Finance
2
CryptoQuantOAuth
com.cryptoquant
Query cryptocurrency on-chain data, OHLCV prices, market data, and Research & QuickTake insights.
Cryptocurrency Blockchain
2
Stelar Signals B
io.github.StelarDigital
Crypto market signals and portfolio telemetry. 6 tools pay-per-call in USDC, no API key.
Cryptocurrency Finance
121
Bitview
io.github.bitcoinresearchkit
Read-only Bitcoin blockchain, mempool, mining, market, and on-chain analytics; no API key.
Blockchain Cryptocurrency
1165

Related MCP Servers

Backtesting Arena
Cryptocurrency Finance Research & Data
Schoasch
A
license
Not graded
quality
A
maintenance
Daily Bitcoin/crypto cycle scoring, on-chain indicators, strategy insights, on-demand backtests. Bearer + x402 pay-per-call
Updated 12 days ago (2026-08-25 12:45 UTC)
MIT
mcp-blockstream-info
Blockchain Cryptocurrency
pipeworx-io
A
license
Not graded
quality
C
maintenance
Enables querying Bitcoin blockchain data including blocks, transactions, addresses, mempool, and fee estimates via the Blockstream.info Esplora API.
Updated 11 days ago (2026-08-26 16:44 UTC)
20
MIT
crypto-intel-mcp
Cryptocurrency Finance
cstamigo-droid
A
license
A
quality
B
maintenance
Provides crypto market intelligence including price quotes, momentum analysis, trending coins, and a composite scored verdict, using the free CoinGecko API.
Updated 2 months ago (2026-07-12 21:14 UTC)
4
MIT
Wicked API - Agent First API
Cryptocurrency Finance Blockchain
choaticpixels
A
license
B
quality
C
maintenance
Real-time crypto, stock, and prediction-market data for agents — prices, indicators, funding rates, DeFi TVL, macro calendar, and an AI momentum score. Configure one Base wallet key and it just works. No signup, no dashboard, no subscription.
Updated 2 months ago (2026-07-15 00:06 UTC)
22
11
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/bxetech/bpe-mcp'

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