A
licenseA
qualityA
maintenancePre-computed financial market intelligence for AI agents. Stocks, crypto, and ETFs.
9
167
5
MIT
patternfetch
Server Details
US stocks, ETFs, crypto → compact brief: patterns, S/R, regime + base rates vs baseline. Not advice.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- MarvinRey7879/patternfetch-client
- GitHub Stars
- 0
- Server Listing
- patternfetch
Available Tools
6 toolspatternfetch_analogsHistorical Analogs DistributionARead-onlyIdempotentInspect
Find earlier windows IN THE SAME SERIES 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. Parameters: window = how many recent bars form the shape being matched (default 32); horizon = how many bars forward each match is measured over (default 20). WHEN: an agent wants the historical spread of outcomes after a similar-looking setup, including how wide and how uncertain that spread is. WHEN NOT: you want the current technical picture (use brief), you want to find candidates across the market (use scan), or you need one expected value — this deliberately returns a distribution, not a point estimate. NOT a prediction, NOT a backtest of a strategy; past distribution does not guarantee future results. Example: {"ticker":"ETH/USDT","timeframe":"1d"}. Impersonal data, not advice.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| market | No | Optional asset-class override. Omit and it is inferred from the ticker: a "BASE/QUOTE" pair is crypto, a plain symbol is a US stock/ETF. | |
| ticker | Yes | Symbol to analyse. US stock or ETF like "AAPL" / "SPY", or a crypto spot pair like "BTC/USDT". Always spell crypto as a pair: a bare "BTC" or "ETH" is a real US-listed ETF, NOT the coin, and it will return that ETF's prices without failing. Affected responses carry a "notice" field. | |
| window | No | Number of recent bars forming the shape matched against history. Default 32. | |
| horizon | No | Number of bars forward over which the outcome after each match is measured. Default 20. | |
| timeframe | Yes | Bar size. One of 1m, 5m, 15m, 30m, 1h, 4h, 1d, 1w. Coverage differs per asset class — see the capabilities tool. |
TDQS
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds behavioral context: 'NOT a prediction, NOT a backtest', 'past distribution does not guarantee future results', and clarifies it returns a distribution, not a point estimate. These go beyond annotations and set proper expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (parameters, when/when not, examples, caveats). Every sentence serves a purpose, and it is concise given the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, the description covers the function, parameter details, usage context, and important caveats. It is fully self-contained and leaves no ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description still adds value by explaining default values for window and horizon, detailing how market is inferred from ticker, and warning about ticker behavior (crypto vs ETF). This provides meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: find historical windows matching current price action and return a full distribution of outcomes. It specifies the resource ('same series'), action ('find and return distribution'), and distinguishes from siblings by emphasizing 'FULL distribution' and 'IN THE SAME SERIES'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('want the historical spread of outcomes') and when not ('want current technical picture' → use brief; 'find candidates across market' → use scan; 'need one expected value'). Provides clear alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
patternfetch_briefMarket-State BriefARead-onlyIdempotentInspect
Get a token-compact market-state brief for a stock, ETF, or crypto ticker + timeframe. Returns compact candles, detected chart/candlestick patterns with geometric confidence AND a backtested historical base rate (how often that pattern+timeframe+confidence-band actually resolved its way), support/resistance levels, trend/regime, and interpreted indicators (RSI/EMA state) plus a one-line summary. Covers US stocks/ETFs (split & dividend adjusted, delayed/EOD) and crypto spot (realtime). 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 or portfolio advice. Examples: {"ticker":"AAPL","timeframe":"1d"}, {"ticker":"BTC/USDT","timeframe":"4h"}. Output is impersonal market data, NOT investment advice.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many recent bars to analyse: integer >= 20, capped at 1000, default 200. Fewer bars = fewer tokens. | |
| market | No | Optional asset-class override. Omit and it is inferred from the ticker: a "BASE/QUOTE" pair is crypto, a plain symbol is a US stock/ETF. | |
| ticker | Yes | Symbol to analyse. US stock or ETF like "AAPL" / "SPY", or a crypto spot pair like "BTC/USDT". Always spell crypto as a pair: a bare "BTC" or "ETH" is a real US-listed ETF, NOT the coin, and it will return that ETF's prices without failing. Affected responses carry a "notice" field. | |
| timeframe | Yes | Bar size. One of 1m, 5m, 15m, 30m, 1h, 4h, 1d, 1w. Coverage differs per asset class — see the capabilities tool. |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds crucial context: coverage of US stocks/ETFs (split/dividend adjusted, delayed/EOD) and crypto spot (realtime), plus ticker ambiguity warning. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with clear sections and examples, but slightly lengthy. Every sentence provides value; formatting improves readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description thoroughly explains what the tool returns (patterns with confidence, backtested base rates, support/resistance, trend/regime, indicators, one-line summary). It covers asset class differences and token-saving rationale, making it complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds significant meaning beyond the schema: for ticker (crypto pair vs stock ETF, notice field), timeframe (coverage differs per asset class, see capabilities tool), market (optional override), limit (fewer bars = fewer tokens).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a token-compact market-state brief for a stock, ETF, or crypto ticker + timeframe.' It lists specific outputs (candles, patterns, support/resistance, etc.) and distinguishes from siblings by focusing on a single ticker with compact summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'WHEN' and 'WHEN NOT' conditions are provided: use when needing technical picture without raw data, avoid for order execution or portfolio advice. Examples for ticker and timeframe are given, aiding correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
patternfetch_capabilitiesServer CapabilitiesARead-onlyIdempotentInspect
Return patternfetch's own capability matrix: which asset classes are covered (US stocks, ETFs, crypto spot), the data source and delay for each, the supported timeframes, the endpoint list, the per-call prices and tier limits, and the product version. Takes no arguments and returns the same static self-description on every call — it contains NO market data (no quotes, candles, patterns or base rates). WHEN: once at the start of a session, to learn which asset classes and timeframes are supported before calling brief/multi/delta/analogs/scan, instead of guessing and getting a validation error. WHEN NOT: you already know the ticker and timeframe are supported (go straight to brief), or you want actual market data (this returns none).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only, idempotent, non-destructive behavior. The description adds significant context: it takes no arguments, returns static self-description on every call, and explicitly states it contains no market data. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear listing of what is returned and separate WHEN/WHEN NOT sections. It is slightly verbose but every sentence adds value, and critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema and rich annotations, the description is fully complete. It explains the return content, use cases, and what the tool does not provide, ensuring the agent can use it correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description confirms 'Takes no arguments', which is sufficient. No additional parameter details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Return' and clearly defines the resource 'patternfetch's own capability matrix'. It enumerates exactly what the matrix contains (asset classes, data sources, timeframes, etc.) and explicitly distinguishes it from sibling tools by stating it contains NO market data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit WHEN and WHEN NOT sections: use it at session start to learn supported features, and avoid it if you already know the ticker/timeframe support or need actual market data. This effectively guides the agent on when to call this tool versus its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
patternfetch_deltaWhat Changed Since Last BriefARead-onlyInspect
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 — call brief once, then delta on each later poll. WHEN NOT: first look at a market (use brief). Returns changed=false when nothing material changed. Example: {"ticker":"BTC/USDT","timeframe":"4h"}. Impersonal data, not advice.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many recent bars to analyse: integer >= 20, capped at 1000, default 200. Fewer bars = fewer tokens. | |
| market | No | Optional asset-class override. Omit and it is inferred from the ticker: a "BASE/QUOTE" pair is crypto, a plain symbol is a US stock/ETF. | |
| ticker | Yes | Symbol to analyse. US stock or ETF like "AAPL" / "SPY", or a crypto spot pair like "BTC/USDT". Always spell crypto as a pair: a bare "BTC" or "ETH" is a real US-listed ETF, NOT the coin, and it will return that ETF's prices without failing. Affected responses carry a "notice" field. | |
| timeframe | Yes | Bar size. One of 1m, 5m, 15m, 30m, 1h, 4h, 1d, 1w. Coverage differs per asset class — see the capabilities tool. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context beyond annotations: it specifies that the tool returns changed=false when nothing material changed, and states 'Impersonal data, not advice,' reinforcing the read-only nature. This aligns with readOnlyHint=true and no destructive side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise: one sentence for purpose, then WHEN/WHEN NOT, return value note, example, and final disclaimer. Every sentence earns its place, well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and no output schema, the description covers the key behavioral aspects: what changes are detected, return value indication, and usage context. Could be slightly more detailed on output structure, but sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so schema already documents parameters. Description adds minor value (e.g., 'Fewer bars = fewer tokens' for limit, example for ticker/timeframe) but does not significantly enhance understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool gets only what changed since the last brief for a ticker+timeframe, listing specific change types (trend flips, new patterns, RSI-state changes). It explicitly distinguishes from sibling patternfetch_brief by stating when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit WHEN (agent polls same market repeatedly and wants minimal tokens) and WHEN NOT (first look at a market, use brief) conditions. Includes an example JSON and notes that return value indicates if anything changed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
patternfetch_multiMulti-Timeframe BriefARead-onlyIdempotentInspect
Get a multi-timeframe market-state view for one stock, ETF, or crypto ticker in a single call: a token-compact brief for each requested timeframe (default 1h, 4h, 1d) PLUS a cross-timeframe alignment read — whether the trends across timeframes agree or diverge, with the split spelled out (e.g. "1h up / 4h up / 1d down"). WHEN: an agent wants to know if a setup is confirmed across horizons or conflicting between them, without making 3 separate brief calls. WHEN NOT: you only care about one timeframe (use brief). The alignment/divergence is impersonal DESCRIPTIVE data, not a signal to act on. Example: {"ticker":"BTC/USDT","timeframes":["1h","4h","1d"]}. Not investment advice.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many recent bars to analyse: integer >= 20, capped at 1000, default 200. Fewer bars = fewer tokens. | |
| market | No | Optional asset-class override. Omit and it is inferred from the ticker: a "BASE/QUOTE" pair is crypto, a plain symbol is a US stock/ETF. | |
| ticker | Yes | Symbol to analyse. US stock or ETF like "AAPL" / "SPY", or a crypto spot pair like "BTC/USDT". Always spell crypto as a pair: a bare "BTC" or "ETH" is a real US-listed ETF, NOT the coin, and it will return that ETF's prices without failing. Affected responses carry a "notice" field. | |
| timeframes | No | Bar sizes to compare, at most 4, e.g. ["1h","4h","1d"]. Defaults to ["1h","4h","1d"] when omitted. |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that the alignment/divergence is 'impersonal DESCRIPTIVE data, not a signal to act on' and includes 'Not investment advice.' This provides additional behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (WHEN, WHEN NOT) and includes an example. While it is a bit lengthy, every sentence serves a purpose. Minor redundancy could be trimmed, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and moderate complexity, the description is thorough. It explains the return content (briefs per timeframe plus alignment read), provides defaults, constraints (max 4 timeframes), and handles edge cases (crypto vs ETF). This enables an agent to use the tool correctly without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%. The description adds valuable information beyond the schema: it clarifies that bare crypto symbols like 'BTC' are treated as US-listed ETFs and that a 'notice' field is included in such cases. It also specifies default timeframes and that at most 4 timeframes are allowed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'multi-timeframe market-state view'. It specifies that the result includes a brief for each requested timeframe and a cross-timeframe alignment read. It distinguishes itself from siblings by noting that it avoids making three separate brief calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly includes WHEN and WHEN NOT sections. WHEN states: 'an agent wants to know if a setup is confirmed across horizons or conflicting between them, without making 3 separate brief calls.' WHEN NOT states: 'you only care about one timeframe (use brief).' This provides clear guidance and names the alternative sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
patternfetch_scanPattern & Regime ScreenerARead-onlyIdempotentInspect
Scan US stocks, ETFs, and crypto for tickers currently in a given regime or showing a chart/candlestick pattern, RANKED by the honest backtested base rate + 95% CI — discovery, NOT lookup. This is the screener: instead of asking about one ticker you already know, ask "which tickers right now are in an uptrend / printing a double_bottom, and which of those has the strongest historical base rate?" and get a ranked shortlist back. Precomputed daily over a curated universe (liquid US large-caps + core/sector ETFs + major crypto pairs) so it is fast and cheap. Filters (all optional): assetClass ("stock"|"crypto"|"all"), regime ("up"|"down"|"range"), pattern (e.g. "double_bottom","double_top","head_and_shoulders","bullish_engulfing","bearish_engulfing","hammer"), minLift (-1..1 in rate points, e.g. 0.02 = keep only patterns beating their OWN pattern-free baseline by >= 2pp; 0 = at or above baseline), minBaseRate (0..1, drop tickers whose top pattern base rate is below this), tf, limit. PREFER minLift over minBaseRate: a raw base rate is not comparable across bullish and bearish rows, so minBaseRate:0.55 mostly returns bullish patterns in a rising universe before any of them carries information, whereas minLift returns the ones that measurably add something. Rows with no baseline in the evidence table are excluded by any minLift (absence of a lift is not a lift of 0). Each row: {sym, tf, assetClass, regime, pattern, baseRate, ci95, n, scope, confidence, asOf} PLUS the drift-free comparison {baseline, lift, liftCi95, liftReading} — baseline is the direction-matched rate with no pattern present, lift is baseRate minus that baseline, and liftReading says whether the difference is distinguishable from zero at all ("above-baseline" | "below-baseline" | "indistinguishable-from-baseline"). Read lift, not baseRate, when comparing a bullish row against a bearish one: in a rising universe a bullish pattern starts ahead before it carries any information. Ranked by baseRate desc, then confidence desc, then narrower CI, then fresher asOf. WHEN: an agent wants to FIND candidates across the market, not analyze a named one (then call brief on the shortlist). WHEN NOT: you already have a specific ticker (use brief). Example: {"assetClass":"all","regime":"up","minLift":0.02,"limit":20}. Impersonal historical data, not investment advice; base rates are gross directional frequencies and do not guarantee future results.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tf | No | Only return signals precomputed on this bar size. Omit to consider every precomputed timeframe. | |
| limit | No | Maximum rows to return: integer in [1,500], default 50. | |
| regime | No | Only return tickers currently in this regime. Omit for any. | |
| minLift | No | Number in [-1,1], in rate points (0.02 = 2pp). Drop tickers whose top pattern does not beat its OWN pattern-free baseline by at least this much. This is the drift-free filter and the one to reach for: minBaseRate:0.55 mostly selects bullish patterns in a rising market, whereas minLift:0.02 selects patterns that actually add something. minLift:0 means "at or above baseline". Negative values are allowed. Rows whose evidence carries no baseline are always excluded — absence of a lift is not a lift of 0. | |
| pattern | No | Only return tickers whose top pattern is this one, e.g. "double_bottom", "double_top", "head_and_shoulders", "bullish_engulfing", "bearish_engulfing", "hammer". | |
| assetClass | No | Restrict the scanned universe. Default "all". | |
| minBaseRate | No | Number in [0,1]. Drop tickers whose top pattern base rate is below this threshold. CAUTION: a raw base rate is NOT comparable across bullish and bearish rows — in a rising universe a bullish pattern clears a high threshold on drift alone, before it carries any information. Prefer minLift for an unbiased shortlist. |
TDQS
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safe, idempotent read operation. The description goes beyond by stating it is precomputed daily over a curated universe, fast and cheap, and provides impersonal historical data not investment advice. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bolded terms, clear sections, and efficient use of sentences. Every sentence provides unique value, and the example input helps understanding. Length is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description thoroughly explains the output fields (sym, tf, baseRate, ci95, etc.) and their interpretation, including the drift-free comparison fields. Context signals (0 required params, 7 optional) are well addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value for each parameter, especially minLift and minBaseRate, explaining their interpretation, caveats, and preference. It clarifies the ranking order and output field meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans US stocks, ETFs, and crypto for tickers in a given regime or showing a pattern, ranked by backtested base rate. It explicitly distinguishes from siblings like brief (for known tickers) and provides a concrete example query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'WHEN' and 'WHEN NOT' sections, directing agents to use brief for known tickers and to prefer minLift over minBaseRate. It also explains when minBaseRate is misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
4 tool updates
- Changed
patternfetch_analogs1 field changed- changed
Input schema / properties / ticker / descriptionPrevious value: -"Symbol to analyse. US stock or ETF like \"AAPL\" / \"SPY\", or a crypto spot pair like \"BTC/USDT\"."New value: +"Symbol to analyse. US stock or ETF like \"AAPL\" / \"SPY\", or a crypto spot pair like \"BTC/USDT\". Always spell crypto as a pair: a bare \"BTC\" or \"ETH\" is a real US-listed ETF, NOT the coin, and it will return that ETF's prices without failing. Affected responses carry a \"notice\" field."
- Changed
patternfetch_brief1 field changed- changed
Input schema / properties / ticker / descriptionPrevious value: -"Symbol to analyse. US stock or ETF like \"AAPL\" / \"SPY\", or a crypto spot pair like \"BTC/USDT\"."New value: +"Symbol to analyse. US stock or ETF like \"AAPL\" / \"SPY\", or a crypto spot pair like \"BTC/USDT\". Always spell crypto as a pair: a bare \"BTC\" or \"ETH\" is a real US-listed ETF, NOT the coin, and it will return that ETF's prices without failing. Affected responses carry a \"notice\" field."
- Changed
patternfetch_delta1 field changed- changed
Input schema / properties / ticker / descriptionPrevious value: -"Symbol to analyse. US stock or ETF like \"AAPL\" / \"SPY\", or a crypto spot pair like \"BTC/USDT\"."New value: +"Symbol to analyse. US stock or ETF like \"AAPL\" / \"SPY\", or a crypto spot pair like \"BTC/USDT\". Always spell crypto as a pair: a bare \"BTC\" or \"ETH\" is a real US-listed ETF, NOT the coin, and it will return that ETF's prices without failing. Affected responses carry a \"notice\" field."
- Changed
patternfetch_multi1 field changed- changed
Input schema / properties / ticker / descriptionPrevious value: -"Symbol to analyse. US stock or ETF like \"AAPL\" / \"SPY\", or a crypto spot pair like \"BTC/USDT\"."New value: +"Symbol to analyse. US stock or ETF like \"AAPL\" / \"SPY\", or a crypto spot pair like \"BTC/USDT\". Always spell crypto as a pair: a bare \"BTC\" or \"ETH\" is a real US-listed ETF, NOT the coin, and it will return that ETF's prices without failing. Affected responses carry a \"notice\" field."
1 tool update
- Changed
patternfetch_scan4 fields changed- changed
Input schema / properties / minBaseRate / descriptionPrevious value: -"Number in [0,1]. Drop tickers whose top pattern base rate is below this threshold."New value: +"Number in [0,1]. Drop tickers whose top pattern base rate is below this threshold. CAUTION: a raw base rate is NOT comparable across bullish and bearish rows — in a rising universe a bullish pattern clears a high threshold on drift alone, before it carries any information. Prefer minLift for an unbiased shortlist." - added
Input schema / properties / minBaseRate / maximumAdded value: +1 - added
Input schema / properties / minBaseRate / minimumAdded value: +0 - added
Input schema / properties / minLiftAdded value: +{ + "description": "Number in [-1,1], in rate points (0.02 = 2pp). Drop tickers whose top pattern does not beat its OWN pattern-free baseline by at least this much. This is the drift-free filter and the one to reach for: minBaseRate:0.55 mostly selects bullish patterns in a rising market, whereas minLift:0.02 selects patterns that actually add something. minLift:0 means \"at or above baseline\". Negative values are allowed. Rows whose evidence carries no baseline are always excluded — absence of a lift is not a lift of 0.", + "maximum": 1, + "minimum": -1, + "type": "number" +}
5 tool updates
- Changed
patternfetch_analogs5 fields changed- added
Input schema / properties / horizon / descriptionAdded value: +"Number of bars forward over which the outcome after each match is measured. Default 20." - added
Input schema / properties / market / descriptionAdded value: +"Optional asset-class override. Omit and it is inferred from the ticker: a \"BASE/QUOTE\" pair is crypto, a plain symbol is a US stock/ETF." - added
Input schema / properties / ticker / descriptionAdded value: +"Symbol to analyse. US stock or ETF like \"AAPL\" / \"SPY\", or a crypto spot pair like \"BTC/USDT\"." - added
Input schema / properties / timeframe / descriptionAdded value: +"Bar size. One of 1m, 5m, 15m, 30m, 1h, 4h, 1d, 1w. Coverage differs per asset class — see the capabilities tool." - added
Input schema / properties / window / descriptionAdded value: +"Number of recent bars forming the shape matched against history. Default 32."
- Changed
patternfetch_brief4 fields changed- added
Input schema / properties / limit / descriptionAdded value: +"How many recent bars to analyse: integer >= 20, capped at 1000, default 200. Fewer bars = fewer tokens." - added
Input schema / properties / market / descriptionAdded value: +"Optional asset-class override. Omit and it is inferred from the ticker: a \"BASE/QUOTE\" pair is crypto, a plain symbol is a US stock/ETF." - added
Input schema / properties / ticker / descriptionAdded value: +"Symbol to analyse. US stock or ETF like \"AAPL\" / \"SPY\", or a crypto spot pair like \"BTC/USDT\"." - added
Input schema / properties / timeframe / descriptionAdded value: +"Bar size. One of 1m, 5m, 15m, 30m, 1h, 4h, 1d, 1w. Coverage differs per asset class — see the capabilities tool."
- Changed
patternfetch_delta4 fields changed- added
Input schema / properties / limit / descriptionAdded value: +"How many recent bars to analyse: integer >= 20, capped at 1000, default 200. Fewer bars = fewer tokens." - added
Input schema / properties / market / descriptionAdded value: +"Optional asset-class override. Omit and it is inferred from the ticker: a \"BASE/QUOTE\" pair is crypto, a plain symbol is a US stock/ETF." - added
Input schema / properties / ticker / descriptionAdded value: +"Symbol to analyse. US stock or ETF like \"AAPL\" / \"SPY\", or a crypto spot pair like \"BTC/USDT\"." - added
Input schema / properties / timeframe / descriptionAdded value: +"Bar size. One of 1m, 5m, 15m, 30m, 1h, 4h, 1d, 1w. Coverage differs per asset class — see the capabilities tool."
- Changed
patternfetch_multi4 fields changed- added
Input schema / properties / limit / descriptionAdded value: +"How many recent bars to analyse: integer >= 20, capped at 1000, default 200. Fewer bars = fewer tokens." - added
Input schema / properties / market / descriptionAdded value: +"Optional asset-class override. Omit and it is inferred from the ticker: a \"BASE/QUOTE\" pair is crypto, a plain symbol is a US stock/ETF." - added
Input schema / properties / ticker / descriptionAdded value: +"Symbol to analyse. US stock or ETF like \"AAPL\" / \"SPY\", or a crypto spot pair like \"BTC/USDT\"." - added
Input schema / properties / timeframes / descriptionAdded value: +"Bar sizes to compare, at most 4, e.g. [\"1h\",\"4h\",\"1d\"]. Defaults to [\"1h\",\"4h\",\"1d\"] when omitted."
- Changed
patternfetch_scan6 fields changed- added
Input schema / properties / assetClass / descriptionAdded value: +"Restrict the scanned universe. Default \"all\"." - added
Input schema / properties / limit / descriptionAdded value: +"Maximum rows to return: integer in [1,500], default 50." - added
Input schema / properties / minBaseRate / descriptionAdded value: +"Number in [0,1]. Drop tickers whose top pattern base rate is below this threshold." - added
Input schema / properties / pattern / descriptionAdded value: +"Only return tickers whose top pattern is this one, e.g. \"double_bottom\", \"double_top\", \"head_and_shoulders\", \"bullish_engulfing\", \"bearish_engulfing\", \"hammer\"." - added
Input schema / properties / regime / descriptionAdded value: +"Only return tickers currently in this regime. Omit for any." - added
Input schema / properties / tf / descriptionAdded value: +"Only return signals precomputed on this bar size. Omit to consider every precomputed timeframe."
1 tool update
- Added
patternfetch_scan
4 tool updates
- Changed
patternfetch_analogs1 field changed- added
Input schema / properties / marketAdded value: +{ + "enum": [ + "crypto", + "stock" + ], + "type": "string" +}
- Changed
patternfetch_brief1 field changed- added
Input schema / properties / marketAdded value: +{ + "enum": [ + "crypto", + "stock" + ], + "type": "string" +}
- Changed
patternfetch_delta1 field changed- added
Input schema / properties / marketAdded value: +{ + "enum": [ + "crypto", + "stock" + ], + "type": "string" +}
- Changed
patternfetch_multi1 field changed- added
Input schema / properties / marketAdded value: +{ + "enum": [ + "crypto", + "stock" + ], + "type": "string" +}
1 tool update
- Added
patternfetch_multi
4 tool updates
- First observed
patternfetch_analogs - First observed
patternfetch_brief - First observed
patternfetch_capabilities - First observed
patternfetch_delta
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Signals, technicals, regime and news for 1,000+ US/TR symbols. Data only, not investment advice.
Stock market trading signals: regime, ranked buy list, stock + sector reads. Free tier + x402 live.
Pre-reasoned Bitcoin & macro financial briefings for AI agents. Trend signals, regimes, 17 contexts.
Crypto market intelligence: regime detection, funding rates, liquidations, prices, signals.
Related MCP Servers
- AlicenseAqualityCmaintenancePre-reasoned Bitcoin and macro market briefings with trend signals, confidence scores, and regime classification. 17 briefings covering BTC, Fed balance sheet, M2, Treasury yields, and cross-asset correlations.51075MIT
- AlicenseCqualityCmaintenanceHistorical stock pattern intelligence for AI agents. Search 24M pre-computed chart pattern embeddings across 15K stocks and 10 years. 19 tools: pattern similarity search, forward returns, regime analysis, anomaly detection, sector rotation, earnings reactions, correlation shifts, scenario analysis, and more. Returns what happened historically when charts looked like this — compliance-safe2220MIT
- AlicenseAqualityCmaintenanceNarrative & signal intelligence for AI agents: crypto/AI/macro convergence & divergence.21MIT
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A4.7/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose: analogs for historical patterns, brief for current state, capabilities for metadata, delta for changes, multi for multi-timeframe, scan for screening. No overlap in functionality.
Naming Consistency5/5
All tools follow a consistent 'patternfetch_<noun>' pattern using snake_case, making it predictable. No mixed conventions or ambiguous verbs.
Tool Count5/5
6 tools is well-scoped for a technical analysis server. Each tool earns its place, covering key operations without being excessive or insufficient.
Completeness4/5
The tool set covers core workflows: current state, multi-timeframe, scanning, historical analogs, and polling for changes. Minor gaps (e.g., no raw data endpoint) are acceptable given the server's focus on processed insights.