PreReason-mcp
This MCP server gives AI agents pre-reasoned Bitcoin, macro, and cross-asset market intelligence, plus tools to discover briefings/metrics and obtain an API key.
List all market briefings with tier requirements and filter by free/basic/pro.
List all metrics (e.g., BTC price, hash rate, Fed balance sheet, M2, Treasury yields, net liquidity) with search and category filters.
Check API health, version, and available endpoints.
Request a free API key from inside the session via a human-approved claim link.
Poll claim or access status to see if data access is pending, approved, delivered, denied, or expired.
Fetch pre-reasoned market briefings (tier-gated) covering Bitcoin, macro, FX, commodities, equities, bonds, crypto, and cross-asset signals; output as markdown or JSON, with optional historical date and entity ticker.
Fetch a single metric with signal interpretation, trend direction (7d/30d/90d), confidence score, momentum, and percentile ranking.
Browse catalogue tools without authentication; get_context and get_metric require an API key.
Provides tools to access pre-reasoned market briefings and metrics for Bitcoin, including trend signals, regime classification, on-chain data such as hash rate and difficulty, and momentum analysis.
@prereason/mcp
Prereason first. Then answer.
Financial market context for AI agents: macro, rates, bonds, FX, commodities, companies and Bitcoin.
Docs · Briefings · Company briefings · Pricing · Get a key
Ask your AI where Treasury yields are. On its own, it reaches for a search result or a raw series and works out the rest by itself. When it prereasons, one get_context call brings back the context already worked out: the 30 year yield at 5.67% on 2026-10-07, the highest reading on the US Treasury's daily par yield curve since July 2001.
Why prereason?
Context, not raw numbers. Each briefing arrives with the reading done: the trend over several windows, where a value sits in its own history, a company's rank among its peers and, where read, its own guidance.
Every figure dated, every source named. Your agent can say when a number is from and where it came from.
One call, a whole briefing. A briefing gathers the series a question needs, so the turns go to the answer rather than to lookups.
The markets in one place. Rates and Treasuries, the Fed, FX, commodities, macro, listed companies in the USA, Japan, Korea and India, and Bitcoin.
It describes; it never advises. Briefings say what the data shows. They never say what to buy, sell or hold.
Quick to set up. One block of config for Claude, Cursor, Codex or VS Code, through the npm bridge or the remote server. The catalogue tools need no key; for the rest, the session gives you one link to approve in your browser, and the key arrives in the running session.
Related MCP server: signaldaemon-mcp
What it covers
PreReason gives an AI agent market context it can reason with, in place of raw numbers. One call returns a briefing with the analysis already in it: a signal line, trend direction over several windows, confidence scores, percentile ranks and correlations, and in the deeper briefings a regime label and a plain language narrative. The briefings cover macro, bonds, FX, commodities, Bitcoin, Ethereum and cross asset correlations. Company briefings cover listed companies in the USA, Japan, Korea and India, one company per call. The catalogue holds 32 live briefings and 270 individual metrics, among them Treasury yields, the latest FOMC statement, Treasury auctions, who holds US Treasuries, the Fed balance sheet, M2, net liquidity, the dollar, US crude and gas inventories, gold, silver, copper and wheat, oil, mining and agribusiness companies beside their commodity, AI compute and power demand, Bitcoin price and momentum, Bitcoin network and miner health, spot Bitcoin ETF flows and corporate Bitcoin treasuries. It is served over MCP (a remote server and an npm bridge) and over REST, as Markdown or JSON. The catalogue tools need no key, and an agent can get a free key from inside the session: it shows one link, a person approves it, and the key arrives.
Quick Start
Option 1: Claude Desktop, no key needed
Requires Node.js 18+, and nothing else: the bridge has no dependencies.
Add this to claude_desktop_config.json and restart Claude Desktop:
{
"mcpServers": {
"prereason": {
"command": "npx",
"args": ["-y", "@prereason/mcp"],
"env": { "PREREASON_CLIENT": "claude-desktop" }
}
}
}The catalogue tools work at once. The first time a briefing needs a key, the bridge asks for access: ask Claude for any briefing and the answer starts with Approve at https://www.prereason.com/claim/PR-XXXX-XXXX. Open the link, sign in or create a free account, click Approve. The key arrives in the bridge on its own, is saved to ~/.prereason/credentials.json, and the next call works. Nothing is created in your account until you click Approve. If your account already holds as many API keys as it allows, the answer says so instead of looping: revoke a key under Settings on prereason.com and restart Claude, or set PREREASON_API_KEY to a key you already have.
Config file location:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.jsonLinux:
~/.config/Claude/claude_desktop_config.json
Already have a key? Add it to the env block as "PREREASON_API_KEY": "pr_live_..." and the bridge never asks.
Option 2: Direct HTTP with an API key (Claude Code, Cursor, Windsurf, Codex, Gemini CLI, VS Code, scripts)
Clients that hold their own config can call the endpoint directly, with the key as a header:
# Claude Code
claude mcp add --transport http prereason https://api.prereason.com/api/mcp --header "Authorization: Bearer YOUR_API_KEY"{
"mcpServers": {
"prereason": {
"type": "http",
"url": "https://api.prereason.com/api/mcp",
"headers": { "Authorization": "Bearer YOUR_API_KEY" }
}
}
}Windsurf uses serverUrl instead of url; Gemini CLI uses httpUrl; Codex uses url plus bearer_token_env_var in config.toml. No key yet? Point the client at the endpoint without a header to browse the catalogue, then create a key on the website (below) and add the header.
Option 3: Claude.ai and Claude Desktop custom connector
Add PreReason as a custom connector, choose "No sign-in", and where the Request headers section is available add Authorization with the value Bearer YOUR_API_KEY (the word Bearer and the space are part of the value). Sign in support for connectors is being re-tested and is not offered until it is verified.
Get an API Key
Three ways, all free. The hosted server never hands out a key inside a session and never asks for one.
Through this bridge. Run it with no key set: it asks PreReason for access on your behalf and shows one approve_url, in its log and in front of any answer that needs a key. Open it, sign in or create your account, click Approve, and the bridge saves the key, attached to your account and named Agent: <client_name>.
From code, for an agent with no browser. POST https://api.prereason.com/api/agent/claims (no auth), show the human the approve_url, then poll GET https://api.prereason.com/api/agent/claims/{claim_code} with Authorization: Bearer <claim_token> until status is approved. Docs: prereason.com/docs#agent-access.
On the website. Sign up at prereason.com/signup, then Dashboard > Settings > API Keys. Keys start with pr_live_.
6 MCP Tools
Tool | Auth | Description |
| Open | List all 32 pre-reasoned market briefings with tier requirements; with |
| Open | List every available metric across the bitcoin, macro, calculated and eth categories |
| Open | API health check, version, account tier |
| Required | Fetch a pre-reasoned market briefing (markdown or JSON); for a company briefing, |
| Required | Fetch a single metric with trend/signal/percentile |
| Required (Basic and above) | What changed since your last call: change events after a cursor, no values |
32 Market Briefings
Free (6 briefings)
Briefing | Description |
| Minimal fast context: BTC + Net Liquidity + correlation |
| BTC + liquidity + hash ribbon + difficulty + momentum |
| Fed balance, M2, treasury yields, dollar strength, net liquidity |
| BTC correlation matrix vs macro indicators |
| Price, 24h change, Bitcoin dominance |
| Epoch pace and difficulty adjustment forecast |
Basic - $19.99/mo (13 briefings)
Briefing | Description |
| 200D MA support/resistance with 7d/30d/90d momentum and percentile rankings |
| Liquidity indicators with momentum analysis |
| Hash rate, difficulty, transactions, active addresses |
| Breadth across SPY, QQQ and IWM, with Bitcoin's correlation to each |
| Hashprice thermometer with miner stress scoring |
| Spot BTC ETF net daily flows, aggregate AUM, and per-issuer breakdown |
| Treasury auction demand: who bought at the latest auction of each note and bond maturity, against that maturity's own prior 12 auctions, with the auctions announced and scheduled next |
| Who holds US Treasuries, in short: foreign investors' net purchases (Treasury's TIC), primary dealers' 13 week change in positions (the New York Fed) and speculators' 10 year note futures position (the CFTC), each against its own history, with the 10 year yield and three bond funds |
| Where Ether stands: its price and global 24 hour volume from CoinGecko, its distance from the 200 day average, Lido's stETH APR, the CFTC's CME Ether positioning and OKX's funding rate |
| The gold fund (GLD) and gold's own monthly price from the World Bank, with the 10 year real rate, the dollar fund, the CFTC's COMEX gold positioning and the miners' fund, each with its measured relationship to GLD |
| The silver fund (SLV) and silver's own monthly price from the World Bank, with the CFTC's COMEX silver positioning and the gold, dollar, copper and silver miners' funds and the 10 year real rate, each with its measured relationship to SLV |
| A copper futures fund (CPER) and copper's own monthly price from the World Bank, with the CFTC's COMEX copper positioning and the dollar and gold funds, each with its measured relationship to CPER |
| A wheat futures fund (WEAT) and US soft red winter wheat's own monthly price from the World Bank, with the CFTC's CBOT wheat positioning, the dollar fund and the WTI spot price, each with its measured relationship to WEAT |
Pro - $49.99/mo (13 briefings)
Briefing | Description |
| Full Bitcoin analysis: macro overlay, momentum, percentiles, correlations and narrative |
| Multi-factor attribution for BTC price movements |
| Regime classification (expansion, contraction, transition) with USDT dominance |
| EUR/USD, USD/CNY and dollar strength, with net liquidity and Bitcoin correlations |
| Production cost model with gas input pressure |
| Corporate Bitcoin treasury intelligence from SEC filings |
| Treasury par yield curve at every maturity, 1M to 30Y, breakeven inflation, 5y5y forward, Germany 10Y |
| AI compute and power chain: US grid demand against a year earlier, miners' AI hosting agreements from SEC filings, hosting against mining per megawatt |
| US oil and gas stocks against the five year norm from EIA's weekly reports, with WTI, Brent and Henry Hub spot prices, the Brent to WTI spread and WTI realised volatility |
| Who holds US Treasuries: foreign investors, primary dealers and speculators, each against its own history, with the Fed's own Treasury holdings, debt held by the public, the largest foreign holders, what would change each reading and the next reports |
| Crude oil beside its covered USA producers: the energy basket's state, WTI and Brent spot prices from EIA, then each integrated major, producer and refiner and two oil field service companies, with its share price, its 1, 3 and 12 month changes beside WTI and the measured 90 day correlation with WTI |
| The gold fund (GLD, a share price, not the gold price) and gold's own monthly price from the World Bank beside the covered USA gold and silver miners and royalty and streaming companies, each with its share price, its 1, 3 and 12 month changes beside GLD and the measured 90 day correlation with GLD |
| The wheat futures fund (WEAT, not the wheat price) and US soft red winter wheat's own monthly price from the World Bank beside the covered USA grain merchandisers and processors, seed and crop nutrient companies, farm equipment makers and farmland REITs, each with its share price, its 1, 3 and 12 month changes beside WEAT and the measured 90 day correlation with WEAT |
Company Briefings
equities.company reads one listed company per call, composed from its own reports (filings with its home market's regulator; for India, the results statement it publishes on its own website), each figure dated and sourced: USA companies on Basic and above, Japanese, Korean and Indian companies on Pro and above. It describes; it never says what to do.
Name the company with
entity: a USA ticker or CIK (NVDA), a Japanese securities code (7203), a Korean stock code (005930) or an Indian company's ISIN (INE018A01030).Not sure of the code? Call
list_briefingswithsearch, for example"Toyota earnings": the answer lists the matching covered companies, each with theentityto pass.Read one part with
block, one of the 11 below, or leave it out for the whole briefing. A part counts one call; the whole briefing counts one for each part it carries. Parts are served for today only.
get_context(briefing="equities.company", entity="7203")
get_context(briefing="equities.company", entity="NVDA", block="valuation")Part ( | What it holds |
| Who the company is, the indexes that hold it with their dates, and a line on its peers |
| Its recent filings |
| Flagged conditions, each with its severity |
| The company's own stated expectations next to what it reported (USA companies only) |
| Income statement, balance sheet and cash flow history, with growth and the company's own history |
| Business, product and geography splits (USA and Japan) |
| The close, market capitalisation, price to earnings, book and sales, enterprise value multiples and free cash flow yield, each with its value a year ago and its own history (closes from StockAnalysis.com) |
| Debt, liquidity and maturities |
| Earnings quality and liquidity, including the accrual ratio, cash conversion, current, quick and cash ratios, working capital, asset turnover, and days sales, inventory and payables outstanding |
| Returns and cash generation, including free cash flow, its margin and per share, EBITDA, return on equity, assets and invested capital, the payout ratio and the effective tax rate |
| Filed news |
Example Prompts
Once connected, try prompts like:
"Give me the Bitcoin quick check"
"Show me the macro snapshot"
"What does the BTC context briefing say about market conditions?"
"Get the bitcoin price metric with trend analysis"
"What's the hash ribbon signal right now?"
"List available briefings"
Troubleshooting
"Server disconnected" error
Ensure Node.js 18+ is installed:
node --versionCheck your API key starts with
pr_live_Fully quit Claude Desktop (system tray > Quit) and reopen
Tools not appearing
Restart Claude Desktop after editing config
Verify JSON syntax:
node -e "JSON.parse(require('fs').readFileSync('path/to/config','utf8'))"
Windows: "'C:\Program' is not recognized"
If you still see this error, ensure you're using the env block (not --header args) as shown in Quick Start above. If the issue persists, install globally and use node:
Run:
npm install -g @prereason/mcpUse this config (replace
YOUR_USERwith your Windows username):
{
"mcpServers": {
"prereason": {
"command": "node",
"args": [
"C:\\Users\\YOUR_USER\\AppData\\Roaming\\npm\\node_modules\\@prereason\\mcp\\bin\\cli.js"
],
"env": {
"PREREASON_API_KEY": "YOUR_API_KEY"
}
}
}
}Auth errors on get_context / get_metric
list_briefings,list_metrics, andget_healthwork without a keyget_contextandget_metricrequire a valid API key, andget_changesa key on the Basic or Pro planGet a free key at prereason.com/signup
Other MCP Clients
If your client supports remote HTTP servers, use Quick Start Option 2 above. The stdio bridge package is only needed for clients that require stdio transport (e.g. Claude Desktop).
CLI Usage
# No key: the bridge asks for access and prints one link to approve
npx @prereason/mcp
# Ask for access now, save the key, exit (useful before a first run)
npx @prereason/mcp --login
# Forget the saved key
npx @prereason/mcp --logout
# Use a key from the environment (never asks)
PREREASON_API_KEY=pr_live_... npx @prereason/mcp
# Name the app the bridge runs in, so your dashboard names the connection
PREREASON_CLIENT=claude-desktop npx @prereason/mcp
# --header (backward compatible), a custom credentials file, a custom endpoint
npx @prereason/mcp --header "Authorization:Bearer YOUR_API_KEY"
npx @prereason/mcp --credentials-file /path/to/credentials.json
PREREASON_URL=https://custom.endpoint/mcp npx @prereason/mcp
npx @prereason/mcp --helpKey precedence: PREREASON_API_KEY, then --header, then the credentials file (~/.prereason/credentials.json, or PREREASON_CREDENTIALS_FILE, or --credentials-file), then the claim flow. The file holds the key and which claim issued it, never a claim token. On macOS and Linux the directory is created 0700 and the file 0600; Windows has no mode bits, so the file relies on your profile directory's permissions like every other credential store there.
Claude Desktop extension (.mcpb)
mcpb/manifest.json describes the same bridge as a single click Claude Desktop extension, key optional. To build the bundle: npm install --omit=dev, then npx @anthropic-ai/mcpb pack . from the package directory, and install the resulting .mcpb by double clicking it. Submission to the Claude directory goes through the desktop extension form and is a publisher decision.
No dependencies
The bridge ships its own transports and installs nothing. npm ls on it is one line, npx @prereason/mcp fetches one 23 KB tarball and starts, and the code a security review has to read is the code in this repository.
It used to depend on @modelcontextprotocol/sdk for two classes, a stdio transport and a Streamable HTTP client. That pulled in 91 packages and 25 MB on disk, nearly all of it the SDK server half: Express, Hono, CORS, a rate limiter, an OAuth client and a schema validator, none of which a relay ever calls. lib/stdio.js and lib/streamable-http.js replace the two classes the bridge used, keep their framing and their callbacks, and are covered by the suite under test/.
Links
Privacy Policy
See prereason.com/privacy for data handling practices.
License
MIT
Available Tools
6 toolsget_changesGet ChangesARead-onlyInspect
What changed since your last call: the change events PreReason records. A live briefing's state label changing, a tracked release becoming known, and, for the companies you name, figures stored for a newer period, an event driven situation turning on, and filed news. Each event says what changed, when it happened, when PreReason knew it and where to read it next (the briefing or metric to fetch with get_context or get_metric); it carries no value. Pass the next_cursor of your previous call to read only what is new; without one, the last 24 hours. Needs an API key on an account with basic access or above.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Events one call returns, 1 to 100. Default 50. | |
| types | No | The event types to read. Every type when left out. | |
| cursor | No | The next_cursor of your previous call. Left out, the read starts from the last day of events. | |
| companies | No | Companies whose events to read: a US ticker or CIK (NVDA), a Japanese securities code (7203), a Korean stock code (005930) or an Indian company's ISIN (INE018A01030). At most 200. A company's events reach only a call that names it. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the read-only/safe profile, and the description adds real beyond-schema context: an API key on an account with basic access or above is required, events carry no value (so a follow-up fetch is needed), events are scoped so a company's events only reach a call that names it, and the default window is 24 hours.
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?
Front-loaded with the core purpose in the first clause, and the cursor/auth guidance lands at the end where it is actionable. The middle enumeration of event types partly restates the schema enum, which adds some length but also semantic meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-shape burden and does so: each event says what changed, when it happened, when PreReason knew it, and where to read next. Auth requirements and the company-scoping caveat round out what an agent needs to call it correctly.
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 coverage is 100%, so the baseline is 3, but the description meaningfully elaborates cursor semantics ('Pass the next_cursor of your previous call') and the non-obvious companies scoping rule ('a company's events reach only a call that names it') that the schema description does not fully convey.
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?
Opens with a specific verb and scope: 'What changed since your last call: the change events PreReason records.' It enumerates the concrete event categories and distinguishes itself from get_context/get_metric by framing them as the place to read detail rather than the change feed.
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?
Gives clear operating conditions: pass the previous next_cursor to read only what is new, otherwise the last 24 hours, and name companies to receive their events. It routes detail lookups to get_context/get_metric but does not state explicit when-not-to-use conditions versus those siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_contextGet Market BriefingARead-onlyInspect
Get a pre-reasoned market briefing with trend signals and confidence scores, plus regime classification and a rule based note on what moved with the price in the briefings that carry them, for the requested domain (macro, rates, bonds, FX, commodities, a listed company, cross-asset or Bitcoin; the same families as the server instructions). Includes crypto, macro financial data, and cross-asset correlations (equity indices, volatility, the dollar and Treasury yields as BTC relationship signals). Output is written to be read directly by reasoning agents, not parsed for individual values. Briefings are tier-gated: Free (btc.quick-check, btc.context, macro.snapshot, cross.correlations, btc.pulse, btc.grid-stress), Basic (btc.momentum, macro.liquidity, macro.auctions, btc.on-chain, cross.breadth, btc.miner-survival, btc.etf-flows, commodities.gold, commodities.silver, commodities.copper, commodities.wheat, eth.context, bonds.context, equities.company), Pro (cross.ai-compute, macro.rates, btc.full, btc.factors, cross.regime, fx.liquidity, btc.energy, btc.treasury, commodities.energy-basket, commodities.oil-producers, commodities.gold-miners, commodities.grains-agribusiness, bonds.full). Requires API key authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Historical date in YYYY-MM-DD format (tier-gated: Free=30d; Basic=3y, Bitcoin briefings from Jan 2025; Pro=all) | |
| entity | No | The company for a per company briefing: a US ticker or CIK (NVDA), a Japanese securities code (7203), a Korean stock code (005930) or an Indian company's ISIN (INE018A01030), with briefing=equities.company | |
| format | No | Response format: markdown (human-readable, default) or json (structured data) | markdown |
| briefing | Yes | Briefing ID to fetch |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/non-destructive/no open-world, so the safety profile is covered. The description adds genuinely new behavioral facts: API-key authentication is required, access is tier-gated with an explicit Free/Basic/Pro mapping, and the payload is prose written for an LLM rather than structured values.
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 purpose is front-loaded in the opening clause, but the first sentence sprawls across nested clauses and the second half is a long inline dump of tier names that would read better as a table. The tier information earns its place, but the packaging is dense and hard to scan.
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 single-get tool with no output schema, the definition covers authentication, tier limits and the nature of the returned content, and the schema carries per-date tier windows. The main gap is that nothing explains how an agent is expected to obtain or validate a briefing ID before calling.
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%, so briefing, date, entity and format are all documented in the schema itself. The description's domain families (macro, rates, bonds, FX, commodities, company, cross-asset, Bitcoin) loosely mirror the briefing enum but add no syntax or constraint detail beyond it, so the 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 opening clause gives a specific verb and resource — fetching a pre-reasoned market briefing containing trend signals, confidence scores, regime classification and a rule-based note — and enumerates the domains it covers. It is clearly a retrieval tool distinct from get_metric/get_changes, though it never explicitly names a sibling to differentiate itself.
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?
It usefully states that output is meant to be read directly by reasoning agents rather than parsed for individual values, and the tier list tells the agent which briefings are reachable on a given plan. However, it never says how to discover valid briefing IDs (e.g. via list_briefings) or when a sibling like get_metric would be the better call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_healthHealth CheckARead-onlyInspect
Check API health status, version, and available endpoints. No authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| verbose | No | Include detailed endpoint descriptions and data coverage info. Defaults to false. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only and non-destructive behavior. The description adds a meaningful behavioral trait beyond that: it explicitly states authentication is not required, and it signals that the tool returns status, version, and endpoint information, which is valuable given the lack of an output schema.
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 a single sentence that front-loads the action and resource, then closes with the auth requirement. Every word carries information; there is no filler.
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 one-optional-parameter health-check tool with read-only annotations, the description covers purpose, auth expectations, and the nature of the response (status, version, endpoints). It is complete enough to invoke correctly without an output schema, though a bit more detail about the response format would be nice.
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 single 'verbose' parameter is fully documented in the input schema with a clear description and default value. The tool description adds no parameter-level detail, but at 100% schema coverage the baseline of 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 names a concrete verb-resource pair ('Check API health status') and enumerates what is returned (version, endpoints). This clearly distinguishes it from sibling tools like check_access or get_metric, which target different resources.
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 does not explicitly state when to prefer this tool over siblings or when not to use it. The 'No authentication required' note gives invocation context but no exclusion guidance, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_metricGet Metric AnalysisARead-onlyInspect
Get a single metric with pre-reasoned signal interpretation, trend analysis (7d/30d/90d), confidence score with factor breakdown, momentum, and percentile ranking. Available metrics: bitcoin-price, bitcoin-market-cap, bitcoin-volume-24h, bitcoin-change-24h, bitcoin-dominance, bitcoin-hash-rate, bitcoin-difficulty, bitcoin-tx-count, bitcoin-tx-volume, bitcoin-active-addresses, fed-balance, m2-supply, treasury-10y, rrp, eur-usd, cny-usd, yield-curve, tga, treasury-3mo, treasury-2y, treasury-5y, treasury-30y, treasury-1mo, treasury-1-5mo, treasury-2mo, treasury-4mo, treasury-6mo, treasury-1y, treasury-3y, treasury-7y, treasury-20y, breakeven-5y, breakeven-10y, real-yield-20y, real-yield-30y, breakeven-20y, breakeven-30y, t5yifr, t10y3m-spread, auction-bid-to-cover-10y, auction-bid-to-cover-30y, indirect-bidder-pct, dealer-takedown-pct, next-treasury-auction-days, fed-funds-rate, ecb-deposit-rate, boj-policy-rate, fed-ecb-spread, fed-boj-spread, carry-trade-returns-proxy, carry-trade-velocity-1d, iwm-spy-credit-spread, spy-vxx-correlation-30d, regime-stability-flag, jpy-usd, oil-brent, oil-wti, real-rate-10y, gld-gdx-ratio, copper-gold-ratio, slv-sil-ratio, gdxj-gdx-ratio, gold-silver-ratio, brent-wti-spread, oil-wti-realized-vol-30d, etf-gld-1h-velocity, etf-cper-1h-velocity, etf-uup-velocity-1h, crude-oil-stocks, natgas-storage, oil-inventory-zscore, natgas-storage-zscore, ecb-boj-spread, etf-gld-volume, etf-uso-volume, etf-uup-volume, etf-gld-volume-zscore-30d, etf-uso-volume-zscore-30d, etf-uup-volume-zscore-30d, net-liquidity, hash-ribbon, etf-spy, etf-qqq, etf-iwm, etf-vxx, etf-uup, etf-gld, etf-gdx, etf-gdxj, etf-slv, etf-sil, etf-cper, etf-weat, etf-tlt, etf-ibit, usdt-market-cap, usdt-dominance, btc-price-200d-ma, btc-price-200d-distance, btc-etf-net-flow, btc-etf-cumulative-flow, btc-etf-aum, btc-etf-ibit-flow, btc-etf-fbtc-flow, btc-etf-gbtc-flow, btc-etf-other-flow, btc-etf-ibit-aum, btc-etf-fbtc-aum, btc-etf-bitb-aum, btc-etf-arkb-aum, btc-etf-btco-aum, btc-etf-ezbc-aum, btc-etf-brrr-aum, btc-etf-hodl-aum, btc-etf-btcw-aum, btc-etf-gbtc-aum, btc-etf-btc-aum, bitcoin-price-1h-change-pct, raw-hashprice-tick, on-chain-velocity-30d, bitcoin-volume-zscore-30d, btc-perp-oi-contracts, btc-perp-positioning-regime, btc-perp-funding-zscore-30d, btc-realized-vol-7d, btc-realized-vol-30d, btc-realized-vol-90d, cot-spx-noncomm-net, cot-spx-noncomm-net-percentile-26w, cot-spx-noncomm-net-percentile-52w, cot-spx-noncomm-net-percentile-156w, cot-gold-noncomm-net, cot-gold-noncomm-net-percentile-26w, cot-gold-noncomm-net-percentile-52w, cot-gold-noncomm-net-percentile-156w, cot-crude-noncomm-net, cot-crude-noncomm-net-percentile-26w, cot-crude-noncomm-net-percentile-52w, cot-crude-noncomm-net-percentile-156w, cot-jpy-noncomm-net, cot-jpy-noncomm-net-percentile-26w, cot-jpy-noncomm-net-percentile-52w, cot-jpy-noncomm-net-percentile-156w, cot-eur-noncomm-net, cot-eur-noncomm-net-percentile-26w, cot-eur-noncomm-net-percentile-52w, cot-eur-noncomm-net-percentile-156w, cot-treasury10y-noncomm-net, cot-treasury10y-noncomm-net-percentile-26w, cot-treasury10y-noncomm-net-percentile-52w, cot-treasury10y-noncomm-net-percentile-156w, cot-copper-noncomm-net, cot-copper-noncomm-net-percentile-26w, cot-copper-noncomm-net-percentile-52w, cot-copper-noncomm-net-percentile-156w, cot-silver-noncomm-net, cot-silver-noncomm-net-percentile-26w, cot-silver-noncomm-net-percentile-52w, cot-silver-noncomm-net-percentile-156w, cot-wheat-noncomm-net, cot-wheat-noncomm-net-percentile-26w, cot-wheat-noncomm-net-percentile-52w, cot-wheat-noncomm-net-percentile-156w, cot-btc-cme-dealer-net, cot-btc-cme-asset-manager-net, cot-btc-cme-leveraged-funds-net, cot-btc-cme-other-reportable-net, cot-btc-cme-nonreportable-net, cot-btc-cme-open-interest, cot-eth-cme-dealer-net, cot-eth-cme-asset-manager-net, cot-eth-cme-leveraged-funds-net, cot-eth-cme-other-reportable-net, cot-eth-cme-nonreportable-net, cot-eth-cme-open-interest, nyfed-sofr, nyfed-sofr-p1, nyfed-sofr-p25, nyfed-sofr-p75, nyfed-sofr-p99, nyfed-sofr-volume, nyfed-bgcr, nyfed-bgcr-p1, nyfed-bgcr-p25, nyfed-bgcr-p75, nyfed-bgcr-p99, nyfed-bgcr-volume, nyfed-tgcr, nyfed-tgcr-p1, nyfed-tgcr-p25, nyfed-tgcr-p75, nyfed-tgcr-p99, nyfed-tgcr-volume, nyfed-effr, nyfed-effr-p1, nyfed-effr-p25, nyfed-effr-p75, nyfed-effr-p99, nyfed-effr-volume, nyfed-obfr, nyfed-obfr-p1, nyfed-obfr-p25, nyfed-obfr-p75, nyfed-obfr-p99, nyfed-obfr-volume, tic-treasury-holdings-total, tic-treasury-holdings-foreign-official, tic-treasury-holdings-japan, tic-treasury-holdings-united-kingdom, tic-treasury-holdings-china, tic-treasury-holdings-belgium, tic-treasury-holdings-cayman-islands, tic-treasury-holdings-luxembourg, tic-treasury-holdings-canada, tic-treasury-holdings-ireland, tic-treasury-holdings-france, tic-treasury-holdings-taiwan, tic-net-foreign-purchases-long-term, tic-net-foreign-purchases-treasuries, tic-net-foreign-purchases-agency-bonds, tic-net-foreign-purchases-corporate-bonds, tic-net-foreign-purchases-equities, tic-net-foreign-official-purchases-treasuries, korea-exports-20d, korea-chip-exports-20d, boc-policy-rate, rba-cash-rate, rbnz-cash-rate, snb-policy-rate, riksbank-policy-rate, norges-bank-policy-rate, pboc-loan-prime-rate, bok-base-rate, rbi-repo-rate, boe-bank-rate, us-core-cpi, u6-unemployment-rate, labor-force-participation-rate, average-hourly-earnings, wb-gold-usd-oz, wb-silver-usd-oz, wb-copper-usd-mt, wb-wheat-srw-usd-mt, bank-reserves, nyfed-soma-total, us-debt-total, ecb-balance, eu-m3, germany-10y, france-10y, italy-10y, spain-10y, portugal-10y, greece-10y, belgium-10y, france-germany-10y-spread, italy-germany-10y-spread, spain-germany-10y-spread, portugal-germany-10y-spread, greece-germany-10y-spread, belgium-germany-10y-spread, japan-30y, japan-40y, etf-hyg, etf-lqd, ethereum-volume-24h, ethereum-volume-zscore-30d, eth-staking-apr, ethereum-price, eth-200d-distance. Requires API key authentication. Returns analyzed context (signal, trend direction, momentum, percentile among every stored daily close), not raw values. The signal is bullish, bearish or neutral on crypto series, and above-trend, below-trend or at-trend on every other metric, where the value sits against its trend, so a high yield reads above-trend. Use when you need to understand what a metric means for decision-making, not just its number. A free key reads the 17 metrics in the bitcoin category in full, and the latest reading of the other 253. A basic key reads 236 in full, and the latest reading of the 34 that only pro briefings use. The pro tier reads every metric in full.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Response format: markdown (default) or json | markdown |
| metric | Yes | Metric name to fetch |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only/non-destructive/closed-world profile, and the description adds substantial extra context: API key authentication is required, tier limits determine which metrics are readable in full vs. latest-only, and it clarifies the non-obvious return semantics that the signal label is bullish/bearish/neutral only on crypto series but above/below/at-trend elsewhere.
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 front-loaded purpose sentence is strong, but the description then dumps ~250 metric names that are already enumerated in the schema enum, adding no information and dominating the text. That bulk does not earn its place and bloats an otherwise useful definition.
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, so the description carries the return-value burden and does so well, spelling out what each analyzed field represents and the two signal-labeling schemes. Auth requirements and tier gating are also disclosed, leaving nothing an agent needs to invoke it correctly.
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 coverage is 100% and both parameters are enum-backed, so the schema already documents valid metric names and the format option. The description restates the full metric list rather than adding syntax or semantics, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get a single metric') and immediately enumerates the analyzed outputs (signal interpretation, trend, confidence, momentum, percentile). The contrast with 'not raw values' makes it distinguishable from primitive fetchers like list_metrics at a glance.
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?
Provides an explicit when-to-use: 'Use when you need to understand what a metric means for decision-making, not just its number.' It does not name the sibling alternatives (get_changes, get_context, list_metrics) or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_briefingsList BriefingsARead-onlyInspect
List all available pre-reasoned market briefings with tier requirements. Returns 33 LIVE briefings across Free (6), Basic (14), and Pro (13) tiers. The company briefing (equities.company) is one listed company per call, for the US on Basic and above, for Japan on Pro and above, for Korea on Pro and above, and for India on Pro and above (133 Indian company briefings counted on 2026-10-07). Covers Bitcoin, macro, FX, and cross-asset financial data categories. No authentication required.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | Filter briefings by subscription tier (free, basic, or pro). Returns all tiers if omitted. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint=false), and the description adds meaningful context beyond that: the 'No authentication required' access condition, the exact tier population (6/14/13), and per-region/company-briefing tier gating. This is well above the annotation-only baseline, though it omits pagination or return-shape behavior.
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 purpose is front-loaded, but the middle is cluttered with a country-by-country availability list and an oddly specific dated figure ('133 Indian company briefings counted on 2026-10-07') that reads as noise and will go stale. The tier counts are useful; the region matrix is disproportionately verbose for a listing tool.
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 read-only, single-optional-parameter list tool with no output schema, the description covers purpose, access requirements, tier segmentation, and data categories. It is complete enough to invoke correctly, missing only filter-usage phrasing and any note on result ordering or volume.
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 coverage is 100%, so the tier enum is already documented and the baseline is 3. The description goes further by explaining what each tier actually contains and its regional availability, giving the agent real semantic grounding for the enum values rather than just the accepted strings.
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 leads with a specific verb and resource ('List all available pre-reasoned market briefings') and adds real substance about what a briefing is. Siblings (get_metric, list_metrics, get_changes, get_context, get_health) are naturally distinct, though the description never names or contrasts with them, so it stops short of explicit differentiation.
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?
There is no explicit when-to-use or when-not-to-use guidance and no alternatives are named. The 'No authentication required' clause is a useful access note but not a usage decision aid, leaving the agent to infer intent from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_metricsList MetricsARead-onlyInspect
List all available individual metrics (270 metrics across bitcoin, calculated, eth, macro categories). Includes the Fed balance sheet, M2 supply, Treasury yields, net liquidity, the dollar, cross-asset indices (SPY, QQQ, VXX, UUP) and Bitcoin price and hash rate. Optionally filter by category or search term. No authentication required. A free key reads the 17 metrics in the bitcoin category in full, and the latest reading of the other 253. A basic key reads 236 in full, and the latest reading of the 34 that only pro briefings use. The pro tier reads every metric in full.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Search term to filter metrics by name or description | |
| category | No | Filter by metric category: bitcoin, calculated, eth, macro |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/safe semantics, so the description earns credit for adding non-obvious behavioral context: no auth required plus a detailed tier model explaining that free/basic/pro keys return partial versus full data. That tier behavior materially affects what an agent receives and is not derivable from annotations.
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 purpose and access-tier information are front-loaded and useful, but the middle sentence cataloguing example metric families (Fed balance sheet, SPY, hash rate, etc.) is largely decorative padding that doesn't help an agent invoke the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully frames what the tool returns, including the crucial caveat that key tier determines whether metrics come back in full or only as a latest reading. The absence of any routing to get_metric is the only notable gap.
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% for both parameters, including the enum values, so the description's mention of filtering by category or search term adds nothing beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List all available individual metrics') and immediately quantifies scope (270 metrics across four named categories), which cleanly separates it from the singular sibling get_metric.
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?
It notes that filtering by category or search term is optional, which implies usage, but never states when to choose this over get_metric or get_changes, nor any exclusion. Usage is inferable rather than stated.
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.
6 tool updates
v0.5.2- Removed
check_access - Added
get_changes - Changed
get_context3 fields changed- changed
Input schema / properties / briefing / enumPrevious value: -[ - "btc.quick-check", - "btc.context", - "macro.snapshot", - "cross.correlations", - "btc.pulse", - "btc.grid-stress", - "btc.momentum", - "macro.liquidity", - "macro.auctions", - "macro.calendar", - "cross.delta", - "cross.industrial-regime", - "cross.full", - "cross.inflation-regime", - "macro.rates", - "btc.on-chain", - "cross.breadth", - "btc.miner-survival", - "btc.full", - "btc.factors", - "cross.regime", - "fx.liquidity", - "btc.energy", - "btc.treasury", - "btc.etf-flows", - "commodities.overview", - "commodities.gold", - "commodities.oil", - "commodities.silver", - "commodities.copper", - "commodities.wheat", - "commodities.energy-basket", - "commodities.inflation-hedge", - "commodities.momentum", - "fx.overview", - "fx.usd", - "fx.eur", - "fx.jpy", - "fx.policy-divergence", - "fx.momentum", - "commodities.full", - "eth.overview", - "eth.context", - "eth.staking", - "eth.network-activity", - "eth.l2-flows", - "crypto.dominance", - "crypto.composite", - "eth.momentum", - "eth.factors", - "eth.full", - "crypto.stablecoin-flows", - "crypto.alt-cycle", - "crypto.full", - "bonds.context", - "bonds.full", - "fx.japan-deep", - "crypto.positioning", - "macro.global-liquidity", - "equities.spy-context", - "equities.qqq-context", - "equities.iwm-context", - "equities.dia-context", - "equities.factors", - "equities.sectors", - "equities.breadth", - "equities.momentum", - "equities.sector-rotation", - "equities.industry-rotation", - "equities.factor-rotation", - "equities.vol-regime", - "equities.full", - "equities.company" -]New value: +[ + "btc.quick-check", + "btc.context", + "macro.snapshot", + "cross.correlations", + "btc.pulse", + "btc.grid-stress", + "btc.momentum", + "macro.liquidity", + "macro.auctions", + "macro.calendar", + "cross.delta", + "cross.industrial-regime", + "cross.full", + "cross.inflation-regime", + "cross.ai-compute", + "macro.rates", + "btc.on-chain", + "cross.breadth", + "btc.miner-survival", + "btc.full", + "btc.factors", + "cross.regime", + "fx.liquidity", + "btc.energy", + "btc.treasury", + "btc.etf-flows", + "commodities.overview", + "commodities.gold", + "commodities.oil", + "commodities.silver", + "commodities.copper", + "commodities.wheat", + "commodities.energy-basket", + "commodities.oil-producers", + "commodities.gold-miners", + "commodities.grains-agribusiness", + "commodities.inflation-hedge", + "fx.overview", + "fx.usd", + "fx.eur", + "fx.jpy", + "fx.policy-divergence", + "fx.momentum", + "commodities.full", + "eth.overview", + "eth.context", + "eth.staking", + "eth.network-activity", + "eth.l2-flows", + "crypto.dominance", + "crypto.composite", + "eth.momentum", + "eth.factors", + "eth.full", + "crypto.stablecoin-flows", + "crypto.alt-cycle", + "crypto.full", + "bonds.context", + "bonds.full", + "fx.japan-deep", + "crypto.positioning", + "macro.global-liquidity", + "equities.spy-context", + "equities.qqq-context", + "equities.iwm-context", + "equities.dia-context", + "equities.factors", + "equities.sectors", + "equities.breadth", + "equities.momentum", + "equities.sector-rotation", + "equities.industry-rotation", + "equities.factor-rotation", + "equities.vol-regime", + "equities.full", + "equities.company" +] - changed
Input schema / properties / date / descriptionPrevious value: -"Historical date in YYYY-MM-DD format (tier-gated: Free=30d, Basic=from Jan 2025, Pro=all)"New value: +"Historical date in YYYY-MM-DD format (tier-gated: Free=30d; Basic=3y, Bitcoin briefings from Jan 2025; Pro=all)" - changed
Input schema / properties / entity / descriptionPrevious value: -"Ticker or code for a parameterised entity briefing: NVDA, 7203, or a CIK, with briefing=equities.company"New value: +"The company for a per company briefing: a US ticker or CIK (NVDA), a Japanese securities code (7203), a Korean stock code (005930) or an Indian company's ISIN (INE018A01030), with briefing=equities.company"
- Changed
get_metric1 field changed- changed
Input schema / properties / metric / enumPrevious value: -[ - "bitcoin-price", - "bitcoin-market-cap", - "bitcoin-volume-24h", - "bitcoin-change-24h", - "bitcoin-dominance", - "bitcoin-hash-rate", - "bitcoin-difficulty", - "bitcoin-tx-count", - "bitcoin-tx-volume", - "bitcoin-active-addresses", - "fed-balance", - "m2-supply", - "treasury-10y", - "rrp", - "eur-usd", - "cny-usd", - "yield-curve", - "tga", - "treasury-3mo", - "treasury-2y", - "treasury-5y", - "treasury-30y", - "breakeven-5y", - "breakeven-10y", - "t5yifr", - "mortgage-30y", - "t10y3m-spread", - "auction-bid-to-cover-10y", - "auction-bid-to-cover-30y", - "indirect-bidder-pct", - "dealer-takedown-pct", - "next-treasury-auction-days", - "fed-funds-rate", - "ecb-deposit-rate", - "boj-policy-rate", - "fed-ecb-spread", - "fed-boj-spread", - "carry-trade-returns-proxy", - "carry-trade-velocity-1d", - "mortgage-treasury-spread", - "iwm-spy-credit-spread", - "spy-vxx-correlation-30d", - "regime-stability-flag", - "jpy-usd", - "oil-brent", - "oil-wti", - "ovx", - "real-rate-10y", - "gld-gdx-ratio", - "copper-gold-ratio", - "slv-sil-ratio", - "gdxj-gdx-ratio", - "gold-silver-ratio", - "brent-wti-spread", - "etf-gld-1h-velocity", - "etf-cper-1h-velocity", - "etf-uso-1h-velocity", - "etf-uup-velocity-1h", - "crude-oil-stocks", - "natgas-storage", - "oil-inventory-zscore", - "natgas-storage-zscore", - "ecb-boj-spread", - "etf-gld-volume", - "etf-uso-volume", - "etf-uup-volume", - "etf-gld-volume-zscore-30d", - "etf-uso-volume-zscore-30d", - "etf-uup-volume-zscore-30d", - "net-liquidity", - "hash-ribbon", - "mvrv-proxy", - "etf-spy", - "etf-qqq", - "etf-iwm", - "etf-vxx", - "etf-uup", - "etf-gld", - "etf-gdx", - "etf-gdxj", - "etf-slv", - "etf-sil", - "etf-uso", - "etf-ung", - "etf-cper", - "etf-weat", - "etf-tlt", - "etf-ibit", - "etf-fxe", - "etf-fxy", - "usdt-market-cap", - "usdt-dominance", - "btc-price-200d-ma", - "btc-price-200d-distance", - "btc-etf-net-flow", - "btc-etf-cumulative-flow", - "btc-etf-aum", - "btc-etf-ibit-flow", - "btc-etf-fbtc-flow", - "btc-etf-gbtc-flow", - "btc-etf-other-flow", - "btc-etf-ibit-aum", - "btc-etf-fbtc-aum", - "btc-etf-bitb-aum", - "btc-etf-arkb-aum", - "btc-etf-btco-aum", - "btc-etf-ezbc-aum", - "btc-etf-brrr-aum", - "btc-etf-hodl-aum", - "btc-etf-btcw-aum", - "btc-etf-gbtc-aum", - "btc-etf-btc-aum", - "bitcoin-price-1h-change-pct", - "raw-hashprice-tick", - "on-chain-velocity-30d", - "bitcoin-volume-zscore-30d", - "btc-perp-oi-contracts", - "btc-perp-positioning-regime", - "btc-perp-funding-zscore-30d" -]New value: +[ + "bitcoin-price", + "bitcoin-market-cap", + "bitcoin-volume-24h", + "bitcoin-change-24h", + "bitcoin-dominance", + "bitcoin-hash-rate", + "bitcoin-difficulty", + "bitcoin-tx-count", + "bitcoin-tx-volume", + "bitcoin-active-addresses", + "fed-balance", + "m2-supply", + "treasury-10y", + "rrp", + "eur-usd", + "cny-usd", + "yield-curve", + "tga", + "treasury-3mo", + "treasury-2y", + "treasury-5y", + "treasury-30y", + "treasury-1mo", + "treasury-1-5mo", + "treasury-2mo", + "treasury-4mo", + "treasury-6mo", + "treasury-1y", + "treasury-3y", + "treasury-7y", + "treasury-20y", + "breakeven-5y", + "breakeven-10y", + "real-yield-20y", + "real-yield-30y", + "breakeven-20y", + "breakeven-30y", + "t5yifr", + "t10y3m-spread", + "auction-bid-to-cover-10y", + "auction-bid-to-cover-30y", + "indirect-bidder-pct", + "dealer-takedown-pct", + "next-treasury-auction-days", + "fed-funds-rate", + "ecb-deposit-rate", + "boj-policy-rate", + "fed-ecb-spread", + "fed-boj-spread", + "carry-trade-returns-proxy", + "carry-trade-velocity-1d", + "iwm-spy-credit-spread", + "spy-vxx-correlation-30d", + "regime-stability-flag", + "jpy-usd", + "oil-brent", + "oil-wti", + "real-rate-10y", + "gld-gdx-ratio", + "copper-gold-ratio", + "slv-sil-ratio", + "gdxj-gdx-ratio", + "gold-silver-ratio", + "brent-wti-spread", + "oil-wti-realized-vol-30d", + "etf-gld-1h-velocity", + "etf-cper-1h-velocity", + "etf-uup-velocity-1h", + "crude-oil-stocks", + "natgas-storage", + "oil-inventory-zscore", + "natgas-storage-zscore", + "ecb-boj-spread", + "etf-gld-volume", + "etf-uso-volume", + "etf-uup-volume", + "etf-gld-volume-zscore-30d", + "etf-uso-volume-zscore-30d", + "etf-uup-volume-zscore-30d", + "net-liquidity", + "hash-ribbon", + "etf-spy", + "etf-qqq", + "etf-iwm", + "etf-vxx", + "etf-uup", + "etf-gld", + "etf-gdx", + "etf-gdxj", + "etf-slv", + "etf-sil", + "etf-cper", + "etf-weat", + "etf-tlt", + "etf-ibit", + "usdt-market-cap", + "usdt-dominance", + "btc-price-200d-ma", + "btc-price-200d-distance", + "btc-etf-net-flow", + "btc-etf-cumulative-flow", + "btc-etf-aum", + "btc-etf-ibit-flow", + "btc-etf-fbtc-flow", + "btc-etf-gbtc-flow", + "btc-etf-other-flow", + "btc-etf-ibit-aum", + "btc-etf-fbtc-aum", + "btc-etf-bitb-aum", + "btc-etf-arkb-aum", + "btc-etf-btco-aum", + "btc-etf-ezbc-aum", + "btc-etf-brrr-aum", + "btc-etf-hodl-aum", + "btc-etf-btcw-aum", + "btc-etf-gbtc-aum", + "btc-etf-btc-aum", + "bitcoin-price-1h-change-pct", + "raw-hashprice-tick", + "on-chain-velocity-30d", + "bitcoin-volume-zscore-30d", + "btc-perp-oi-contracts", + "btc-perp-positioning-regime", + "btc-perp-funding-zscore-30d", + "btc-realized-vol-7d", + "btc-realized-vol-30d", + "btc-realized-vol-90d", + "cot-spx-noncomm-net", + "cot-spx-noncomm-net-percentile-26w", + "cot-spx-noncomm-net-percentile-52w", + "cot-spx-noncomm-net-percentile-156w", + "cot-gold-noncomm-net", + "cot-gold-noncomm-net-percentile-26w", + "cot-gold-noncomm-net-percentile-52w", + "cot-gold-noncomm-net-percentile-156w", + "cot-crude-noncomm-net", + "cot-crude-noncomm-net-percentile-26w", + "cot-crude-noncomm-net-percentile-52w", + "cot-crude-noncomm-net-percentile-156w", + "cot-jpy-noncomm-net", + "cot-jpy-noncomm-net-percentile-26w", + "cot-jpy-noncomm-net-percentile-52w", + "cot-jpy-noncomm-net-percentile-156w", + "cot-eur-noncomm-net", + "cot-eur-noncomm-net-percentile-26w", + "cot-eur-noncomm-net-percentile-52w", + "cot-eur-noncomm-net-percentile-156w", + "cot-treasury10y-noncomm-net", + "cot-treasury10y-noncomm-net-percentile-26w", + "cot-treasury10y-noncomm-net-percentile-52w", + "cot-treasury10y-noncomm-net-percentile-156w", + "cot-copper-noncomm-net", + "cot-copper-noncomm-net-percentile-26w", + "cot-copper-noncomm-net-percentile-52w", + "cot-copper-noncomm-net-percentile-156w", + "cot-silver-noncomm-net", + "cot-silver-noncomm-net-percentile-26w", + "cot-silver-noncomm-net-percentile-52w", + "cot-silver-noncomm-net-percentile-156w", + "cot-wheat-noncomm-net", + "cot-wheat-noncomm-net-percentile-26w", + "cot-wheat-noncomm-net-percentile-52w", + "cot-wheat-noncomm-net-percentile-156w", + "cot-btc-cme-dealer-net", + "cot-btc-cme-asset-manager-net", + "cot-btc-cme-leveraged-funds-net", + "cot-btc-cme-other-reportable-net", + "cot-btc-cme-nonreportable-net", + "cot-btc-cme-open-interest", + "cot-eth-cme-dealer-net", + "cot-eth-cme-asset-manager-net", + "cot-eth-cme-leveraged-funds-net", + "cot-eth-cme-other-reportable-net", + "cot-eth-cme-nonreportable-net", + "cot-eth-cme-open-interest", + "nyfed-sofr", + "nyfed-sofr-p1", + "nyfed-sofr-p25", + "nyfed-sofr-p75", + "nyfed-sofr-p99", + "nyfed-sofr-volume", + "nyfed-bgcr", + "nyfed-bgcr-p1", + "nyfed-bgcr-p25", + "nyfed-bgcr-p75", + "nyfed-bgcr-p99", + "nyfed-bgcr-volume", + "nyfed-tgcr", + "nyfed-tgcr-p1", + "nyfed-tgcr-p25", + "nyfed-tgcr-p75", + "nyfed-tgcr-p99", + "nyfed-tgcr-volume", + "nyfed-effr", + "nyfed-effr-p1", + "nyfed-effr-p25", + "nyfed-effr-p75", + "nyfed-effr-p99", + "nyfed-effr-volume", + "nyfed-obfr", + "nyfed-obfr-p1", + "nyfed-obfr-p25", + "nyfed-obfr-p75", + "nyfed-obfr-p99", + "nyfed-obfr-volume", + "tic-treasury-holdings-total", + "tic-treasury-holdings-foreign-official", + "tic-treasury-holdings-japan", + "tic-treasury-holdings-united-kingdom", + "tic-treasury-holdings-china", + "tic-treasury-holdings-belgium", + "tic-treasury-holdings-cayman-islands", + "tic-treasury-holdings-luxembourg", + "tic-treasury-holdings-canada", + "tic-treasury-holdings-ireland", + "tic-treasury-holdings-france", + "tic-treasury-holdings-taiwan", + "tic-net-foreign-purchases-long-term", + "tic-net-foreign-purchases-treasuries", + "tic-net-foreign-purchases-agency-bonds", + "tic-net-foreign-purchases-corporate-bonds", + "tic-net-foreign-purchases-equities", + "tic-net-foreign-official-purchases-treasuries", + "korea-exports-20d", + "korea-chip-exports-20d", + "boc-policy-rate", + "rba-cash-rate", + "rbnz-cash-rate", + "snb-policy-rate", + "riksbank-policy-rate", + "norges-bank-policy-rate", + "pboc-loan-prime-rate", + "bok-base-rate", + "rbi-repo-rate", + "boe-bank-rate", + "us-core-cpi", + "u6-unemployment-rate", + "labor-force-participation-rate", + "average-hourly-earnings", + "wb-gold-usd-oz", + "wb-silver-usd-oz", + "wb-copper-usd-mt", + "wb-wheat-srw-usd-mt", + "bank-reserves", + "nyfed-soma-total", + "us-debt-total", + "ecb-balance", + "eu-m3", + "germany-10y", + "france-10y", + "italy-10y", + "spain-10y", + "portugal-10y", + "greece-10y", + "belgium-10y", + "france-germany-10y-spread", + "italy-germany-10y-spread", + "spain-germany-10y-spread", + "portugal-germany-10y-spread", + "greece-germany-10y-spread", + "belgium-germany-10y-spread", + "japan-30y", + "japan-40y", + "etf-hyg", + "etf-lqd", + "ethereum-volume-24h", + "ethereum-volume-zscore-30d", + "eth-staking-apr", + "ethereum-price", + "eth-200d-distance" +]
- Changed
list_metrics2 fields changed- changed
Input schema / properties / category / descriptionPrevious value: -"Filter by metric category: bitcoin, calculated, macro"New value: +"Filter by metric category: bitcoin, calculated, eth, macro" - changed
Input schema / properties / category / enumPrevious value: -[ - "bitcoin", - "calculated", - "macro" -]New value: +[ + "bitcoin", + "calculated", + "eth", + "macro" +]
- Removed
request_access
6 tool updates
v0.5.0- Added
check_access - Changed
get_context2 fields changed- changed
Input schema / properties / briefing / enumPrevious value: -[ - "btc.quick-check", - "btc.context", - "macro.snapshot", - "cross.correlations", - "btc.pulse", - "btc.grid-stress", - "btc.momentum", - "macro.liquidity", - "macro.auctions", - "cross.delta", - "cross.industrial-regime", - "cross.full", - "cross.inflation-regime", - "macro.rates", - "btc.on-chain", - "cross.breadth", - "btc.miner-survival", - "btc.full", - "btc.factors", - "cross.regime", - "fx.liquidity", - "btc.energy", - "btc.treasury", - "btc.etf-flows" -]New value: +[ + "btc.quick-check", + "btc.context", + "macro.snapshot", + "cross.correlations", + "btc.pulse", + "btc.grid-stress", + "btc.momentum", + "macro.liquidity", + "macro.auctions", + "macro.calendar", + "cross.delta", + "cross.industrial-regime", + "cross.full", + "cross.inflation-regime", + "macro.rates", + "btc.on-chain", + "cross.breadth", + "btc.miner-survival", + "btc.full", + "btc.factors", + "cross.regime", + "fx.liquidity", + "btc.energy", + "btc.treasury", + "btc.etf-flows", + "commodities.overview", + "commodities.gold", + "commodities.oil", + "commodities.silver", + "commodities.copper", + "commodities.wheat", + "commodities.energy-basket", + "commodities.inflation-hedge", + "commodities.momentum", + "fx.overview", + "fx.usd", + "fx.eur", + "fx.jpy", + "fx.policy-divergence", + "fx.momentum", + "commodities.full", + "eth.overview", + "eth.context", + "eth.staking", + "eth.network-activity", + "eth.l2-flows", + "crypto.dominance", + "crypto.composite", + "eth.momentum", + "eth.factors", + "eth.full", + "crypto.stablecoin-flows", + "crypto.alt-cycle", + "crypto.full", + "bonds.context", + "bonds.full", + "fx.japan-deep", + "crypto.positioning", + "macro.global-liquidity", + "equities.spy-context", + "equities.qqq-context", + "equities.iwm-context", + "equities.dia-context", + "equities.factors", + "equities.sectors", + "equities.breadth", + "equities.momentum", + "equities.sector-rotation", + "equities.industry-rotation", + "equities.factor-rotation", + "equities.vol-regime", + "equities.full", + "equities.company" +] - added
Input schema / properties / entityAdded value: +{ + "description": "Ticker or code for a parameterised entity briefing: NVDA, 7203, or a CIK, with briefing=equities.company", + "pattern": "^[A-Za-z0-9.-]{1,12}$", + "type": "string" +}
- Changed
get_health1 field changed- changed
Input schema / properties / verbose / descriptionPrevious value: -"Include detailed endpoint descriptions, pricing tiers, and data coverage info. Defaults to false."New value: +"Include detailed endpoint descriptions and data coverage info. Defaults to false."
- Changed
get_metric1 field changed- changed
Input schema / properties / metric / enumPrevious value: -[ - "bitcoin-price", - "bitcoin-market-cap", - "bitcoin-volume-24h", - "bitcoin-change-24h", - "bitcoin-dominance", - "bitcoin-hash-rate", - "bitcoin-difficulty", - "bitcoin-tx-count", - "bitcoin-tx-volume", - "bitcoin-active-addresses", - "fed-balance", - "m2-supply", - "treasury-10y", - "rrp", - "eur-usd", - "cny-usd", - "yield-curve", - "tga", - "treasury-3mo", - "treasury-2y", - "treasury-5y", - "treasury-30y", - "breakeven-5y", - "breakeven-10y", - "t5yifr", - "mortgage-30y", - "t10y3m-spread", - "auction-bid-to-cover-10y", - "auction-bid-to-cover-30y", - "indirect-bidder-pct", - "dealer-takedown-pct", - "next-treasury-auction-days", - "fed-funds-rate", - "ecb-deposit-rate", - "boj-policy-rate", - "fed-ecb-spread", - "fed-boj-spread", - "carry-trade-returns-proxy", - "carry-trade-velocity-1d", - "mortgage-treasury-spread", - "iwm-spy-credit-spread", - "spy-vxx-correlation-30d", - "regime-stability-flag", - "net-liquidity", - "hash-ribbon", - "mvrv-proxy", - "etf-spy", - "etf-qqq", - "etf-iwm", - "etf-vxx", - "etf-uup", - "usdt-market-cap", - "usdt-dominance", - "btc-price-200d-ma", - "btc-price-200d-distance", - "btc-etf-net-flow", - "btc-etf-cumulative-flow", - "btc-etf-aum", - "btc-etf-ibit-flow", - "btc-etf-fbtc-flow", - "btc-etf-gbtc-flow", - "btc-etf-other-flow", - "btc-etf-ibit-aum", - "btc-etf-fbtc-aum", - "btc-etf-bitb-aum", - "btc-etf-arkb-aum", - "btc-etf-btco-aum", - "btc-etf-ezbc-aum", - "btc-etf-brrr-aum", - "btc-etf-hodl-aum", - "btc-etf-btcw-aum", - "btc-etf-gbtc-aum", - "btc-etf-btc-aum", - "bitcoin-price-1h-change-pct", - "raw-hashprice-tick", - "on-chain-velocity-30d", - "bitcoin-volume-zscore-30d" -]New value: +[ + "bitcoin-price", + "bitcoin-market-cap", + "bitcoin-volume-24h", + "bitcoin-change-24h", + "bitcoin-dominance", + "bitcoin-hash-rate", + "bitcoin-difficulty", + "bitcoin-tx-count", + "bitcoin-tx-volume", + "bitcoin-active-addresses", + "fed-balance", + "m2-supply", + "treasury-10y", + "rrp", + "eur-usd", + "cny-usd", + "yield-curve", + "tga", + "treasury-3mo", + "treasury-2y", + "treasury-5y", + "treasury-30y", + "breakeven-5y", + "breakeven-10y", + "t5yifr", + "mortgage-30y", + "t10y3m-spread", + "auction-bid-to-cover-10y", + "auction-bid-to-cover-30y", + "indirect-bidder-pct", + "dealer-takedown-pct", + "next-treasury-auction-days", + "fed-funds-rate", + "ecb-deposit-rate", + "boj-policy-rate", + "fed-ecb-spread", + "fed-boj-spread", + "carry-trade-returns-proxy", + "carry-trade-velocity-1d", + "mortgage-treasury-spread", + "iwm-spy-credit-spread", + "spy-vxx-correlation-30d", + "regime-stability-flag", + "jpy-usd", + "oil-brent", + "oil-wti", + "ovx", + "real-rate-10y", + "gld-gdx-ratio", + "copper-gold-ratio", + "slv-sil-ratio", + "gdxj-gdx-ratio", + "gold-silver-ratio", + "brent-wti-spread", + "etf-gld-1h-velocity", + "etf-cper-1h-velocity", + "etf-uso-1h-velocity", + "etf-uup-velocity-1h", + "crude-oil-stocks", + "natgas-storage", + "oil-inventory-zscore", + "natgas-storage-zscore", + "ecb-boj-spread", + "etf-gld-volume", + "etf-uso-volume", + "etf-uup-volume", + "etf-gld-volume-zscore-30d", + "etf-uso-volume-zscore-30d", + "etf-uup-volume-zscore-30d", + "net-liquidity", + "hash-ribbon", + "mvrv-proxy", + "etf-spy", + "etf-qqq", + "etf-iwm", + "etf-vxx", + "etf-uup", + "etf-gld", + "etf-gdx", + "etf-gdxj", + "etf-slv", + "etf-sil", + "etf-uso", + "etf-ung", + "etf-cper", + "etf-weat", + "etf-tlt", + "etf-ibit", + "etf-fxe", + "etf-fxy", + "usdt-market-cap", + "usdt-dominance", + "btc-price-200d-ma", + "btc-price-200d-distance", + "btc-etf-net-flow", + "btc-etf-cumulative-flow", + "btc-etf-aum", + "btc-etf-ibit-flow", + "btc-etf-fbtc-flow", + "btc-etf-gbtc-flow", + "btc-etf-other-flow", + "btc-etf-ibit-aum", + "btc-etf-fbtc-aum", + "btc-etf-bitb-aum", + "btc-etf-arkb-aum", + "btc-etf-btco-aum", + "btc-etf-ezbc-aum", + "btc-etf-brrr-aum", + "btc-etf-hodl-aum", + "btc-etf-btcw-aum", + "btc-etf-gbtc-aum", + "btc-etf-btc-aum", + "bitcoin-price-1h-change-pct", + "raw-hashprice-tick", + "on-chain-velocity-30d", + "bitcoin-volume-zscore-30d", + "btc-perp-oi-contracts", + "btc-perp-positioning-regime", + "btc-perp-funding-zscore-30d" +]
- Changed
list_metrics2 fields changed- changed
Input schema / properties / category / descriptionPrevious value: -"Filter by metric category"New value: +"Filter by metric category: bitcoin, calculated, macro" - changed
Input schema / properties / category / enumPrevious value: -[ - "bitcoin", - "macro", - "calculated", - "treasury", - "eth", - "eth-onchain", - "equities", - "commodities", - "fx", - "bonds", - "crypto" -]New value: +[ + "bitcoin", + "calculated", + "macro" +]
- Added
request_access
5 tool updates
v0.1.8- Added
get_context - Added
get_health - Added
get_metric - Added
list_briefings - Added
list_metrics
5 tool updates
v0.2.1- Removed
get_context - Removed
get_health - Removed
get_metric - Removed
list_briefings - Removed
list_metrics
5 tool updates
v0.2.0- First observed
get_context - First observed
get_health - First observed
get_metric - First observed
list_briefings - First observed
list_metrics
TDQS
Scored across 6 tools
The set follows a clean list/get split across two resources (briefings and metrics), plus health and change-feed tools, so most selections are clear. However, get_context and get_metric both advertise 'trend signals, confidence scores, and regime' language, which creates some risk that an agent picks the wrong one when it wants a single series versus a full briefing.
All six tools use a consistent verb_noun snake_case pattern (get_health, list_briefings, list_metrics, get_context, get_metric, get_changes). The list_*/get_* pairing is predictable and readable across the surface.
Six tools is well-scoped for this server: the 270 metrics and 33 briefings are addressed via parameters (metric id, domain, category filters) rather than one tool per entity, which is the right design. Nothing appears redundant or missing at the tool-count level.
The surface covers the domain lifecycle well: discover briefings/metrics, fetch them, and track deltas via get_changes, plus a health check. A minor gap is that list_briefings has no documented category/search filter (list_metrics does), so narrowing to a specific briefing relies on the agent scanning the full list.
Maintenance
Related MCP Connectors
Signed BTC and macro market intelligence for autonomous research, risk, and trading agents.
Live macro data for AI agents: regime, conditions, liquidity, with input provenance. No signup.
Crypto market intelligence: regime detection, funding rates, liquidations, prices, signals.
Narrative & signal intelligence for AI agents: crypto/AI/macro convergence & divergence.
Related MCP Servers
- AlicenseAqualityAmaintenancePre-computed financial market intelligence for AI agents. Stocks, crypto, and ETFs.978 npm5MIT
- AlicenseAqualityDmaintenanceNarrative & signal intelligence for AI agents: crypto/AI/macro convergence & divergence.21MIT
- AlicenseNot gradedqualityBmaintenanceClassifies BTC market into 5 regimes (Risk-On, Range-Bound, Risk-Off, Capitulation, Euphoria) with target exposure and posture, enabling risk management decisions.MIT

BRS Signals MCP Serverofficial
AlicenseNot gradedqualityBmaintenanceProvides real-time Bitcoin market regime detection by fusing on-chain, derivatives, and absence sensors into a convergence score, enabling AI agents to make informed trading decisions.1MIT