This server provides token-compact crypto market analysis for AI agents, turning a ticker + timeframe into structured, interpreted market intelligence without dumping raw OHLCV data into context.
patternfetch_brief — Get a full market-state brief for any crypto pair and timeframe, including compact candle representation, detected chart/candlestick patterns with confidence scores, support/resistance levels, trend/regime analysis, interpreted indicators (RSI/EMA state), and a one-line natural language summary.
patternfetch_delta — Poll a market efficiently by fetching only what changed since the last brief (trend flips, new patterns, RSI-state changes), minimizing token usage; returns changed=false when nothing material has shifted.
patternfetch_analogs — Find historical price windows that resemble the current setup and return the full distribution of outcomes (win-rate, median, min, max, sample size) over a configurable forward horizon.
patternfetch_capabilities — List all supported assets, timeframes, endpoints, and usage limits.
Create API Keys — Generate a self-serve API key with a small amount of free credit.
⚠️ All outputs are impersonal market data for informational purposes only — not investment advice.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@patternfetch get a brief for BTC/USDT on 4h timeframe"
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.
patternfetch is a market-data API for AI agents covering US stocks, ETFs and crypto spot. One
call with a ticker and a timeframe returns a token-compact market-state report: compact candles,
detected chart and candlestick patterns, support and resistance levels, market regime, and
interpreted indicators (RSI, EMA). Every detected pattern carries its backtested historical hit rate
and its lift against the pattern-free baseline of the same market, so an agent can tell a
pattern that carries information from one that does not. Six tools — brief, multi, delta,
analogs, scan, capabilities — reachable over REST and MCP, with one-click OAuth, credit
billing via Stripe or x402 USDC on Base, a keyless demo endpoint, and $3 starter credit on signup.
Impersonal market data, not investment advice.
Why it's smaller: for BTC/USDT 4h (120 candles), a raw OHLCV dump is ~3,260 tokens of just numbers the model still has to analyze; patternfetch's interpreted analysis is ~1,323 tokens, already decided. Reproduce it (no account needed).
Coverage: US stocks and ETFs (split- and dividend-adjusted, delayed/EOD, via Yahoo), crypto spot (realtime, via Binance).
Timeframes: 1m, 5m, 15m, 30m, 1h, 4h, 1d, 1w.
Access: REST at patternfetch.com/v1/*, MCP at patternfetch.com/mcp (Streamable HTTP),
plus a local stdio bridge (patternfetch-mcp).
A detector that only reports double_top, confidence 0.92 tells an agent nothing about whether that
pattern has ever meant anything. patternfetch attaches an evidence block to each detected pattern:
{
"name": "double_top",
"confidence": 0.92,
"evidence": {
"scope": "US stocks & ETFs",
"tf": "1d",
"band": "0.75-1.00",
"horizon": 10,
"n": 7508,
"hitRate": 0.431,
"ci95": 0.011,
"lift": {
"baseline": 0.419979,
"baselineN": 46038,
"lift": 0.011021,
"ci95": 0.012075,
"informative": false,
"reading": "indistinguishable-from-baseline"
}
}
}hitRate is the realizable gross directional base rate: the fraction of non-overlapping historical
occurrences of that pattern, in that timeframe and confidence band, whose close-to-close return over
the next horizon bars went the expected direction. The forward window starts at detection, so
there is no lookahead. No stops, fees or slippage are modelled.
lift compares that hit rate against the baseline of the same market with no pattern present. Many
patterns come back indistinguishable-from-baseline — that is the honest result, and reporting it
is the point. An agent can filter on informative instead of trusting a geometric confidence score.
Calibration. Across 105 audited categories, 3 fall outside their confidence interval — fewer than the ~5.3 that chance alone predicts across 105 comparisons. For US stocks it is 0 of 60. Method and full tables: patternfetch.com/pattern-base-rates-study. The measurement is reproducible with the open-source honest-signals tool.
Related MCP server: coin-mcp
No key required — the demo endpoint is public:
curl -X POST https://patternfetch.com/v1/demo \
-H 'content-type: application/json' \
-d '{"ticker":"AAPL","timeframe":"1d"}'With a key (self-serve, $3 starter credit):
curl -X POST https://patternfetch.com/v1/keys -d '{"email":"you@example.com"}'
curl -X POST https://patternfetch.com/v1/brief \
-H 'authorization: Bearer pf_...' \
-H 'content-type: application/json' \
-d '{"ticker":"BTC/USDT","timeframe":"4h"}'JavaScript client:
npm install patternfetchimport { Patternfetch } from 'patternfetch';
const { key } = await new Patternfetch().createKey('you@example.com');
const pf = new Patternfetch({ apiKey: key });
const brief = await pf.brief({ ticker: 'AAPL', timeframe: '1d' });
console.log(brief.analysis.nl);
// "AAPL: uptrend (strong), +0.14% last 1d, RSI 71.66 (overbought),
// bearish_engulfing (conf 1, hist 41% over 10b, lift -0.7pp vs 42% base (within noise))."
for (const p of brief.analysis.patterns) {
if (p.evidence?.lift.informative) console.log(p.name, p.evidence.hitRate, p.evidence.lift.lift);
}Six tools, the same set over MCP (patternfetch_*) and REST (POST /v1/*).
Tool | What it returns | When an agent calls it |
| Market-state report for one ticker + timeframe: compact candles, patterns with base rate and lift, support/resistance, regime, RSI/EMA, one-line summary. | The default. It needs the current technical picture of one market without dumping raw OHLCV into context. |
| One brief per timeframe (default | It wants to know whether a setup is confirmed or contradicted across horizons, without three separate |
| Only what changed since the last brief for that ticker + timeframe — trend flips, new patterns, RSI-state changes. Returns | It polls the same market repeatedly. Call |
| Historical windows whose shape resembles current price action, with the full distribution of what followed: win rate, median, mean, min, max and n over a fixed forward horizon. | It wants the historical outcome spread for a setup rather than a point estimate. Not a prediction, not a strategy backtest. |
| Screener over a curated universe of liquid US large-caps, core and sector ETFs and major crypto pairs. Filter by asset class, regime, pattern and minimum base rate; rows return ranked by base rate with 95% CI. Precomputed daily. | It needs to find candidates across the market rather than analyse a ticker it already named. Feed the shortlist into |
| Supported assets, timeframes, endpoints, limits and pricing. No input. | First, before relying on any assumption about coverage. |
Method | Endpoint |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
patternfetch is a remote MCP server (Streamable HTTP) at https://patternfetch.com/mcp.
Tools: patternfetch_brief, patternfetch_multi, patternfetch_delta, patternfetch_analogs,
patternfetch_scan, patternfetch_capabilities.
Discovery (initialize, tools/list) is free — no key. Only tools/call needs auth.
One-click OAuth (nothing to paste) — in Claude Code, Claude Desktop, Cursor or Smithery, add the URL and authorize once; a free-tier key is minted for you:
claude mcp add --transport http patternfetch https://patternfetch.com/mcpIn claude.ai: Customize → Connectors → Add custom connector → https://patternfetch.com/mcp → Authorize.
Or with a Bearer key — add to your MCP config:
{
"mcpServers": {
"patternfetch": {
"url": "https://patternfetch.com/mcp",
"headers": { "Authorization": "Bearer pf_..." }
}
}
}Get a free key (small starter credit) at https://patternfetch.com/v1/keys.
Prefer a local stdio server (Claude Desktop, sandboxes, no inbound HTTP)? This package
ships patternfetch-mcp, a zero-dependency stdio↔HTTP bridge that exposes the same tools
and forwards calls to patternfetch.com:
{
"mcpServers": {
"patternfetch": {
"command": "npx",
"args": ["-y", "patternfetch-mcp"],
"env": { "PATTERNFETCH_API_KEY": "pf_..." }
}
}
}tools/list works with no key and falls back to the embedded snapshot
(mcp-tools.json) when the remote is unreachable, so introspection always
succeeds. Tool calls use PATTERNFETCH_API_KEY, OAuth or x402. Override the endpoint with
PATTERNFETCH_MCP_URL.
Refresh the snapshot from the live server:
curl -s -X POST https://patternfetch.com/mcp \
-H 'content-type: application/json' \
-H 'accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'$3 starter credit on signup, at least $0.50 of it usable immediately without a card. After that, pay per call from credit, topped up via Stripe or x402 USDC on Base. Studio plan: $19/month including $25 of usage.
Call | Price |
| $0.010 |
| $0.025 |
| $0.008 ($0.001 when nothing changed) |
| $0.005 |
| $0.050 |
| $0.020 |
Live figures: GET /v1/platforms.
patternfetch provides impersonal market data and algorithmic signals for informational purposes only. NOT investment, financial, legal or tax advice, and not a recommendation to buy, sell or hold any security or crypto-asset. Outputs are not personalized to you. Base rates are gross directional frequencies without stops, fees or slippage; past performance and historical analogs do not guarantee future results. Markets are volatile — you may lose all capital. Do your own research. See patternfetch.com/disclaimer, /methodology and /terms.
Find historical windows whose shape resembles the current price action and return the FULL distribution of what followed (win-rate, median, min, max, n) over a fixed forward horizon. WHEN: an agent wants historical context for a setup. NOT a prediction, NOT a backtest of a strategy; past distribution does not guarantee future results. Impersonal data, not advice.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| timeframe | Yes | ||
| window | No | ||
| horizon | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses the behavioral nature: it returns historical distribution data, explicitly states it is not a prediction or advice, and notes past performance does not guarantee future results. This is transparent for a read-only analytical tool.
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 extremely concise: three sentences, no redundant text. The key action and output are front-loaded, and every sentence contributes essential information (purpose, usage guidelines, limitations).
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?
The description adequately explains the return value (FULL distribution with specific metrics) but fails to explain all input parameters, especially ticker and timeframe. Given that there is no output schema and schema coverage is 0%, the description should provide more parameter context to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only indirectly hints at 'window' and 'horizon' without explaining their meaning or format. The required parameters 'ticker' and 'timeframe' are not mentioned at all, leaving their semantics entirely to the schema which lacks descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds historical windows resembling current price action and returns a distribution of forward outcomes. It uses specific verbs and lists exact return fields (win-rate, median, min, max, n), and distinguishes itself from siblings by explicitly stating it is not a prediction or backtest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use ('agent wants historical context for a setup') and what not to use ('NOT a prediction, NOT a backtest'). It provides clear context for appropriate usage, though it does not directly reference sibling tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a token-compact market-state brief for a crypto ticker + timeframe. Returns compact candles, detected chart/candlestick patterns with geometric confidence, support/resistance levels, trend/regime, and interpreted indicators (RSI/EMA state) plus a one-line summary. WHEN: an agent needs the current technical picture of a market without dumping raw OHLCV into context (saves tokens, avoids numeric hallucination). WHEN NOT: you need order execution, portfolio advice, or non-crypto assets. Example: {"ticker":"BTC/USDT","timeframe":"4h"}. Output is impersonal market data, NOT investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| timeframe | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that output is 'impersonal market data, NOT investment advice,' which is critical for safe use. It also notes token-saving and hallucination avoidance. It does not detail rate limits, required permissions, or data freshness, but these are acceptable gaps for a read-like tool.
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 well-structured with a clear opening statement, a bullet-like list of outputs, and usage sections. It is informative without being verbose. Minor redundancy (e.g., 'token-compact' and 'saves tokens') could be trimmed, but overall it earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no output schema, and no annotations, the description provides a solid overview of the tool's purpose, return content, and usage boundaries. It lacks details on error handling, pagination, or data latency, but covers essentials well for a tool of moderate complexity.
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 schema has 0% parameter descriptions, so the description must compensate. It explains 'ticker' and 'timeframe' via example and context ('crypto ticker + timeframe'), but the optional 'limit' parameter is not mentioned at all. Partial coverage; more detail on parameter format or defaults would improve clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a 'token-compact market-state brief' with specific outputs (candles, patterns, support/resistance, etc.). It identifies the resource (crypto ticker + timeframe) and the action (get). However, it does not explicitly differentiate from sibling tools like 'patternfetch_analogs' or 'patternfetch_delta', missing a chance to clarify unique positioning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides 'WHEN' and 'WHEN NOT' guidance, specifying ideal use (saving tokens, avoiding hallucination) and contraindications (order execution, portfolio advice, non-crypto). It also includes a concrete example, making it extremely clear for an agent when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List supported assets, timeframes, endpoints, and limits for patternfetch.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It says 'list', implying a read-only operation, but doesn't explicitly disclose behavioral traits like auth needs or rate limits. For a simple listing tool, this is minimally adequate.
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?
Single sentence, front-loaded with key information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description sufficiently explains what the tool returns for its intended use case.
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% with 0 parameters, baseline score 4. Description adds no parameter info because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists supported assets, timeframes, endpoints, and limits for patternfetch. The verb 'list' and specific resource differentiate it from sibling tools like patternfetch_analogs or patternfetch_delta.
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 implies use for retrieving capabilities but provides no explicit guidance on when to use this tool versus alternatives or 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.
Get only what CHANGED since your last brief for a ticker+timeframe (trend flips, new patterns, RSI-state changes). WHEN: an agent polls the same market repeatedly and wants minimal tokens. Returns changed=false when nothing material changed. Impersonal data, not advice.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| timeframe | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses key behaviors: returns changed=false when nothing changed, provides impersonal data not advice, and focuses on minimal tokens. Implies statefulness (requires previous brief) without fully detailing prerequisites or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a WHEN clause; front-loaded with purpose, efficient with no fluff. Every sentence adds value: what, when, result on no change, disclaimer.
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?
Adequate for a delta tool: explains purpose, usage, return flag, and uses sibling names for context. Could be more explicit about state dependency and output format, but given 3 param inputs and no output schema, it covers essential aspects.
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 0%, so description must compensate. It explains ticker and timeframe as 'ticker+timeframe' but omits the optional 'limit' parameter. Adds meaning to required params but not complete coverage.
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?
Description clearly states verb 'Get only what CHANGED' and resource 'since your last brief for a ticker+timeframe', listing specific change types like trend flips and RSI-state changes. It distinguishes from sibling tools (e.g., patternfetch_brief, patternfetch_analogs) by focusing on delta updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when an agent polls the same market repeatedly and wants minimal tokens'. Implies not for first-time queries, and sibling names provide context for alternatives, but no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0patternfetch_analogspatternfetch_briefpatternfetch_capabilitiespatternfetch_deltaEach tool has a distinct purpose: patternfetch_analogs provides historical pattern matching, patternfetch_brief gives a current market summary, patternfetch_capabilities lists supported features, and patternfetch_delta reports changes since the last brief. No two tools overlap in functionality.
All tool names follow the pattern 'patternfetch_' followed by a descriptive noun (analogs, brief, capabilities, delta). The naming is uniformly lowercase with underscores, making it predictable and easy to understand.
With only 4 tools, the server is tightly scoped to its domain of pattern analysis. This number is appropriate given the focused nature of the server, providing essential functionality without unnecessary complexity.
The tools cover the full lifecycle of pattern analysis: understanding capabilities, getting a current brief, detecting changes, and retrieving historical analogs. There are no obvious gaps for the intended use case of market analysis.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Unlock the power of real-time cryptocurrency data with our Crypto Price Insights MCP server.
Crypto market intelligence, token rug-checks, and wallet verification in one MCP server.
MCP server with quote and live cryptocurrency price tools, local and cloud-deployed transports.
Real-time market events, sentiment, and technical analysis as MCP tools, backed by real data.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MarvinRey7879/patternfetch-client'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
