aipricepatterns
Server Details
Historical market memory for AI agents using semantic vector search across years of financial market data. Discover similar market regimes, price patterns, and market context for quantitative research and algorithmic trading.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.4/5 across 12 of 12 tools scored. Lowest: 2.8/5.
Each tool has a clearly distinct purpose: pattern search variants differ by input method (historical, sketched, private data), decision tools are separated by context (generic vs. Polymarket), and supporting tools (backtest, regime, track record) cover different aspects. No two tools appear to do the same thing.
Most tools follow a descriptive verb_noun pattern in snake_case, but there is a split between 'get_' prefixed tools (e.g., get_track_record) and directly verb-noun names (e.g., backtest_strategy). This minor inconsistency does not hinder readability.
12 tools cover the server's domain of price pattern analysis and trading decisions without being excessive or sparse. Each tool serves a specific, justified purpose, and the count feels well-scoped for the intended functionality.
The tool set covers core workflows: pattern search (multiple methods), regime detection, backtesting, trade decisions, and track record verification. Minor gaps like a dedicated symbol listing tool are absent but not critical, as symbols are likely parameters.
Available Tools
12 toolsbacktest_strategyBInspect
Perform a full strategy backtest over a historical period (Walk-forward analysis). Use this for testing general rules or long-term performance.
| Name | Required | Description | Default |
|---|---|---|---|
| f | Yes | Forecast horizon | |
| q | Yes | Query length | |
| step | No | Simulation step in bars | |
| topK | No | Number of nearest neighbours | |
| endTs | No | End timestamp for simulation | |
| feePct | No | Per-side fee percentage | |
| symbol | Yes | Ticker symbol | |
| maxBars | No | Maximum recent bars to load for the backtest | |
| minProb | No | Directional probability threshold | |
| startTs | No | Start timestamp for simulation | |
| interval | Yes | Timeframe | |
| token_id | No | Optional Manus access token. Paid tools use tokenized service access, not a monthly subscription: when token_id is omitted the server returns payment_required with a Solana Pay invoice, and after payment you retry with the same token while the server uses Manus token/resolve to recover pending access. | |
| direction | No | Allowed direction: long, short, or both | |
| minAvgSim | No | Minimum average similarity required to trade | |
| onlySignals | No | Return only non-neutral decisions | |
| slippagePct | No | Per-side slippage percentage | |
| includeStats | No | ||
| embeddingMode | No | Pattern embedding mode for ANN retrieval |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for disclosing behavioral traits. It only states the action and scope, without detailing potential side effects, authentication needs (token_id is described in schema but not in description), rate limits, or output behavior. This is insufficient for a complex 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 two sentences, no wasted words, and front-loads the main action. It is appropriately concise and well-structured.
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 18 parameters, no output schema, and no annotations, the description is too sparse. It does not explain return values, how to define a strategy, or how to interpret results. More context is needed for effective use.
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 94%, so the baseline is 3. The description adds no extra meaning beyond what the schema already provides for parameters. It does not explain how parameters interact or provide usage examples.
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 action ('Perform a full strategy backtest') and specifies the scope ('historical period', 'walk-forward analysis'). It distinguishes the tool's purpose from siblings by mentioning 'testing general rules or long-term performance', but does not explicitly differentiate from other backtesting or analysis tools.
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 gives a usage context ('testing general rules or long-term performance') but lacks explicit guidance on when not to use this tool or mention of alternatives among the 11 siblings. The instruction is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
detect_market_regimeCInspect
Classify current market state into one of the known market regimes.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Ticker symbol | |
| interval | Yes | Timeframe | |
| token_id | No | Optional Manus access token. Paid tools use tokenized service access, not a monthly subscription: when token_id is omitted the server returns payment_required with a Solana Pay invoice, and after payment you retry with the same token while the server uses Manus token/resolve to recover pending access. | |
| timestamp | No | Unix timestamp for detection | |
| queryLength | Yes | Length of price vector to analyze |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should fully disclose behavioral traits. It does not mention return format, potential side effects, or limitations. The description is too brief to inform an AI agent about what happens during invocation.
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, which is concise but lacks structure. It does not front-load key information or organize details. It is not verbose, but could be more informative while remaining concise.
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 complexity of the tool (5 parameters, 3 required, no output schema), the description is incomplete. It does not explain what regimes exist, what the output looks like, or how parameters like 'token_id' (for paid access) should be used. The agent lacks sufficient information to use the tool 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 description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it does not explain how parameters like 'queryLength' or 'timestamp' affect the classification. It meets the minimum but adds no value.
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's purpose: classifying current market state into known regimes. It uses a specific verb ('classify') and a clear resource ('market state'), but it does not differentiate from sibling tools like 'get_trading_decision' or 'backtest_strategy'.
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?
No guidance on when to use this tool versus alternatives. There is no mention of when not to use it or what prerequisites are needed. The description lacks context for selecting this tool over similar ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_market_analogsAInspect
Find historical price patterns similar to the current (or specified) market state. Returns a list of past dates when the same pattern occurred, the price outcome after each analog, and aggregate statistics (win rate, median return, percentile range). Use cases: (1) pre-news analysis — filter by timeOfDayUTC to find analogs that happened near a specific event time (e.g., FOMC at 14:00 UTC); (2) regime research — understand historically what happens after this pattern; (3) Polymarket context — combine with get_polymarket_probabilities to validate signal with historical evidence. Returns a plain-English summary suitable for agent reasoning.
| Name | Required | Description | Default |
|---|---|---|---|
| f | No | ||
| q | No | ||
| limit | No | ||
| symbol | Yes | Ticker symbol, e.g. BTCUSDT | |
| context | No | ||
| session | No | ||
| interval | No | Candle interval | 15m |
| token_id | No | Optional Manus access token. Paid tools use tokenized service access, not a monthly subscription: when token_id is omitted the server returns payment_required with a Solana Pay invoice, and after payment you retry with the same token while the server uses Manus token/resolve to recover pending access. | |
| weekdays | No | ||
| timeOfDayUTC | No | ||
| timeRangeUTC | No | ||
| minSimilarity | No | ||
| anchorTimestamp | No | ||
| timeWindowMinutes | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, description discloses that tool returns data and includes a token_id parameter with detailed payment/retry behavior. It does not explicitly state non-destructiveness or rate limits, but the paid-access transparency adds value.
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?
Description is two paragraphs with clear opening sentence. Uses bullet-like enumeration for use cases. Could be more structured but 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 14 parameters, nested objects, and no output schema, the description provides use cases and return summary but lacks parameter details. Adequate but incomplete for complex tool.
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 only 21%, and description only explains timeOfDayUTC and token_id meaningfully. Most parameters (f, q, limit, context, session, etc.) are not described, leaving agents to guess their function.
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 the tool finds historical price patterns similar to current/specified market state and returns specific outputs (dates, outcomes, statistics). This distinguishes it from siblings like pattern_search and detect_market_regime.
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 lists three use cases (pre-news analysis, regime research, Polymarket context) and suggests combining with get_polymarket_probabilities. However, no mention of when not to use or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forecast_private_memory_from_dataCInspect
Create or reuse a private dataset, import candle data, and return a compact forecast card in one call. Ideal for users who want to upload exchange or ML-derived candle history, inspect analogues immediately, and only then decide whether to run RLXBT.
| Name | Required | Description | Default |
|---|---|---|---|
| f | No | ||
| q | No | ||
| name | No | ||
| rows | No | ||
| slug | No | ||
| sort | No | ||
| force | No | ||
| limit | No | ||
| start | No | ||
| cursor | No | ||
| userId | No | ||
| agentId | No | ||
| rawText | No | ||
| anchorTs | No | ||
| interval | No | ||
| token_id | No | Optional Manus access token. Paid tools use tokenized service access, not a monthly subscription: when token_id is omitted the server returns payment_required with a Solana Pay invoice, and after payment you retry with the same token while the server uses Manus token/resolve to recover pending access. | |
| datasetId | No | ||
| description | No | ||
| windowEndTs | No | ||
| embeddingMode | No | ||
| windowStartTs | No | ||
| includeForecast | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors. It mentions creation/reuse of datasets and returning a forecast card, but lacks details on side effects (e.g., overwriting existing data), authentication requirements (token_id hints at payment but not clearly), rate limits, or error conditions. The description is insufficient for safe invocation.
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 two sentences, concise and front-loaded with the action. However, it could be more structured with separate sections for when to use, what it does, and important notes. It earns its length but could be more informative per sentence.
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's complexity (22 parameters, no output schema, no annotations), the description is too high-level. It does not explain return values, dataset lifecycle, or how to leverage the many parameters. A comprehensive description would need to address these gaps.
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 only 5% (one parameter documented). The description adds no explanation for the 22 parameters, which are abundant and complex. It fails to compensate for the low coverage, leaving the agent without guidance on how to set parameters correctly.
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 creates/reuses a dataset, imports candle data, and returns a forecast card. It identifies the target use case (uploading exchange/ML candle history) and mentions inspecting analogues, which helps distinguish from siblings like find_market_analogs, though that sibling's purpose overlaps somewhat.
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 provides a specific usage scenario ('ideal for users who want to upload...and only then decide whether to run RLXBT') but does not explicitly state when NOT to use the tool or list alternative tools for different use cases among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_api_guideAInspect
Returns the full documentation and workflow guide for this MCP server. Call this first to understand all available tools, their use cases, and how to combine them. Includes: tool catalog, recommended workflows for Polymarket research, historical analog analysis, and example calls.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Focus area: 'all' for full guide, or a specific topic | all |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description sufficiently implies a read-only operation by stating it 'returns' documentation. Adds context like 'call this first'.
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 with a bullet list of included content. Front-loaded with main purpose, 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 simple nature of the tool (one optional param, no output schema), the description is fully complete, stating what it returns and when to use it.
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 the parameter description in the schema already explains the enum values. The description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool returns the full documentation and workflow guide for the MCP server, and distinguishes itself from sibling tools by being the introductory guide.
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 says 'Call this first' to understand all tools, their use cases, and how to combine them. While it doesn't specify when not to use it, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_live_polymarket_trade_decisionBInspect
Auto-discover the active BTC Up/Down 15m Polymarket market, combine live Polymarket pricing with pattern memory and intrabar momentum, and return BUY_YES, BUY_NO, or SKIP with entry guardrails.
| Name | Required | Description | Default |
|---|---|---|---|
| nowMs | No | ||
| symbol | No | BTCUSDT | |
| minEdge | No | ||
| interval | No | 15m | |
| token_id | No | Optional Manus access token. Paid tools use tokenized service access, not a monthly subscription: when token_id is omitted the server returns payment_required with a Solana Pay invoice, and after payment you retry with the same token while the server uses Manus token/resolve to recover pending access. | |
| marketWindow | No | current | |
| allowDegradedSearch | No | ||
| minCombinedConfidence | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It mentions auto-discovery, combination of data sources, and return values, but does not disclose side effects, authentication needs (token_id parameter hints at paid access but not in description), or whether the tool is read-only.
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 with no redundancy. It conveys the core purpose efficiently, though it could be slightly restructured for clarity. Still, it earns a high score for conciseness.
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 8 parameters, no output schema, and no annotations, the description is incomplete. It lacks details on output format, error handling, parameter semantics, and authentication, which are necessary for correct invocation.
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 only 13%, and the description does not explain any parameters beyond implying symbol and interval. Key parameters like minEdge, marketWindow, allowDegradedSearch, and minCombinedConfidence are not described, leaving the agent to infer from names only.
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 auto-discovers the active BTC Up/Down 15m Polymarket market, combines live pricing with pattern memory and intrabar momentum, and returns BUY_YES, BUY_NO, or SKIP with entry guardrails. This differentiates it from sibling tools like get_trading_decision by specifying the specific market and unique logic.
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 this tool is for Polymarket BTC Up/Down 15m decisions but does not explicitly state when to use it versus alternatives like get_trading_decision or other sibling tools. No exclusion or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_mcp_compatibility_manifestAInspect
Return the versioned MCP compatibility manifest, including canonical tools, aliases, and JSON argument schemas for remote clients.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full burden. It indicates a read operation returning a manifest, but does not disclose potential caching, authentication requirements, or response size.
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 that is direct and informative with no extraneous information.
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 no parameters and no output schema, the description fully explains what the tool returns, which is sufficient for a simple retrieval tool.
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 tool has no parameters, so the description does not need to add parameter meaning; baseline 4 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?
The description clearly states the tool returns a 'versioned MCP compatibility manifest' and specifies its contents ('canonical tools, aliases, and JSON argument schemas'), distinguishing it from other tools that perform analysis or trading decisions.
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?
No guidance on when to use this tool vs alternatives; it is a simple retrieval tool but lacks any context about prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pattern_metricsBInspect
Retrieve advanced statistical metrics and forecast distributions for a pattern search result.
| Name | Required | Description | Default |
|---|---|---|---|
| f | No | Forecast horizon in bars | |
| q | No | Query length in bars | |
| sort | No | Sort mode for results | |
| limit | No | Maximum number of matches to return | |
| symbol | No | Ticker symbol (e.g., BTCUSDT) | |
| compact | No | Default true: strips per-match value arrays and full forecast paths, returning match metadata, horizon-end price targets, and the calibrated outcome distribution (~4x fewer tokens). Set false for full arrays. | |
| anchorTs | No | Target timestamp to search around | |
| interval | No | Timeframe (e.g., 1h, 15m) | |
| token_id | No | Optional Manus access token. Paid tools use tokenized service access, not a monthly subscription: when token_id is omitted the server returns payment_required with a Solana Pay invoice, and after payment you retry with the same token while the server uses Manus token/resolve to recover pending access. | |
| embeddingMode | No | Pattern embedding mode: priceShape uses normalized closes, featureV1 uses OHLCV/context, neuralV1 uses the experimental ONNX encoder |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It describes a 'retrieve' operation but does not disclose whether it is read-only, whether it modifies data, any required permissions, or the computational cost. The output is vaguely defined as 'metrics and forecast distributions' without specifics.
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, no filler, and directly communicates the core function. It is appropriately front-loaded and efficient.
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?
Despite the detailed schema, the description is too vague about what the tool returns. No output schema exists, so the description should explain the output more concretely. With 10 parameters and no behavioral details, the description is insufficient for an agent to fully understand the tool's context.
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 input schema covers 100% of parameters with descriptions. The tool description adds no additional meaning beyond the schema. Baseline score of 3 is appropriate since the schema already provides adequate parameter semantics.
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 verb 'Retrieve' and specifies the resource 'advanced statistical metrics and forecast distributions' for a 'pattern search result'. It effectively distinguishes from sibling tools like 'pattern_search' which likely returns raw patterns, not metrics.
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?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, sequential dependencies (e.g., after pattern_search), or when to avoid using it. The agent must infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_track_recordAInspect
Public forecast track record: every closed bar the engine logs its own forecast BEFORE the outcome is known, then grades it against reality. Returns direction hit rate, p10-p90 band coverage vs the nominal 80%, mean abs error, the active conformal calibration scale, and recent forecast-vs-actual rows. Use this to verify the engine's calibration before trusting its forecasts.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max recent forecast rows to return (default 40, max 200) | |
| symbol | No | Ticker symbol (default BTCUSDT) | |
| interval | No | Timeframe: 5m, 15m, 1h or 4h (default 1h) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool logs forecasts before outcomes and grades them, and returns specific metrics. It implies read-only behavior without stating it explicitly, and does not mention auth needs or rate limits, but is fairly transparent about the tool's operation.
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 two sentences, each earning its place. The first sentence explains what the tool does and its outputs, the second gives usage guidance. 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?
The description lists the main return values: direction hit rate, band coverage, mean abs error, calibration scale, and recent forecast rows. This is sufficient for a query tool with no output schema, though it omits details like pagination or row structure.
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 baseline is 3. The description adds minimal additional meaning beyond the schema, only linking 'recent forecast rows' to the limit parameter. It does not elaborate on the interval or symbol parameters further.
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's purpose: 'Public forecast track record' that logs forecasts before outcomes and grades them, returning specific metrics. It distinguishes itself from siblings by focusing on verification of calibration, not on trading decisions or pattern detection.
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 says 'Use this to verify the engine's calibration before trusting its forecasts.' This provides clear context for when to use it. However, it does not mention when not to use it or suggest alternative tools, missing some guidance on exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_trading_decisionBInspect
Return a compact trader decision card for a symbol/interval: TRADEABLE, WATCH, or SKIP with direction, confidence, evidence, risk, reasons, and caveats.
| Name | Required | Description | Default |
|---|---|---|---|
| f | No | Forecast horizon in bars | |
| q | No | Query length in bars | |
| sort | No | Sort mode for results | |
| limit | No | Maximum number of matches to return | |
| feePct | No | Per-side fee percentage for the proof backtest | |
| symbol | No | Ticker symbol (e.g., BTCUSDT) | |
| compact | No | Default true: strips per-match value arrays and full forecast paths, returning match metadata, horizon-end price targets, and the calibrated outcome distribution (~4x fewer tokens). Set false for full arrays. | |
| minProb | No | Minimum directional probability required to trade in the proof backtest | |
| anchorTs | No | Target timestamp to search around | |
| interval | No | Timeframe (e.g., 1h, 15m) | |
| token_id | No | Optional Manus access token. Paid tools use tokenized service access, not a monthly subscription: when token_id is omitted the server returns payment_required with a Solana Pay invoice, and after payment you retry with the same token while the server uses Manus token/resolve to recover pending access. | |
| minAvgSim | No | Minimum average similarity required to trade in the proof backtest | |
| slippagePct | No | Per-side slippage percentage for the proof backtest | |
| backtestStep | No | Backtest step in bars | |
| backtestEndTs | No | Optional backtest end timestamp in Unix ms | |
| embeddingMode | No | Pattern embedding mode: priceShape uses normalized closes, featureV1 uses OHLCV/context, neuralV1 uses the experimental ONNX encoder | |
| backtestMaxBars | No | Maximum recent bars to load for the backtest | |
| backtestStartTs | No | Optional backtest start timestamp in Unix ms | |
| includeBacktest | No | When true, include a walk-forward backtest proof block. This is slower than the default decision-only response. | |
| backtestTimeoutMs | No | Optional timeout budget for the backtest request |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the return type but does not mention side effects, idempotency, permissions, or rate limits. The tool likely reads data, but this is not confirmed.
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 efficiently conveys the core purpose and output structure. No wasted words; front-loaded with key information.
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?
Despite having 20 parameters and no output schema, the description lacks details on return format, usage examples, or how parameters interact. It leaves the agent guessing about the response structure and how to interpret the decision card.
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 each parameter has a meaningful description. The tool description does not add further meaning beyond the schema, so the baseline of 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?
Description clearly states the tool returns a compact trader decision card for a symbol/interval, listing possible outcomes (TRADEABLE, WATCH, SKIP) and included fields (direction, confidence, etc.). It distinguishes from sibling tools like backtest_strategy or pattern_search by specifying the output nature.
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 provides no guidance on when to use this tool vs. alternatives like detect_market_regime or find_market_analogs. No explicit context on prerequisites or decision criteria is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pattern_searchCInspect
Search for similar historical price patterns in the RLX database.
| Name | Required | Description | Default |
|---|---|---|---|
| f | No | Forecast horizon in bars | |
| q | No | Query length in bars | |
| sort | No | Sort mode for results | |
| limit | No | Maximum number of matches to return | |
| symbol | No | Ticker symbol (e.g., BTCUSDT) | |
| compact | No | Default true: strips per-match value arrays and full forecast paths, returning match metadata, horizon-end price targets, and the calibrated outcome distribution (~4x fewer tokens). Set false for full arrays. | |
| anchorTs | No | Target timestamp to search around | |
| interval | No | Timeframe (e.g., 1h, 15m) | |
| token_id | No | Optional Manus access token. Paid tools use tokenized service access, not a monthly subscription: when token_id is omitted the server returns payment_required with a Solana Pay invoice, and after payment you retry with the same token while the server uses Manus token/resolve to recover pending access. | |
| embeddingMode | No | Pattern embedding mode: priceShape uses normalized closes, featureV1 uses OHLCV/context, neuralV1 uses the experimental ONNX encoder |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic purpose. No mention of read-only nature, auth requirements, rate limits, or side effects. Schema parameters are described but behavioral traits are missing.
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?
Extremely concise (one sentence, 8 words) but lacks structure or front-loading. It is not wasteful but too short to be fully effective.
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 complexity (10 parameters, no output schema, no annotations), the description is incomplete. It does not explain output, process, or how to distinguish from siblings.
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 baseline is 3. The tool description adds no additional parameter meaning beyond what the schema already provides.
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 states the specific verb 'Search' and resource 'historical price patterns in the RLX database'. It is clear but does not explicitly differentiate from sibling tools like 'find_market_analogs' which may have overlap.
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?
No guidance on when to use this tool versus alternatives such as 'find_market_analogs' or 'detect_market_regime'. No when-not-to-use or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_by_sketchBInspect
Search for historical patterns similar to a custom 'sketched' price trajectory (Sketch-to-Search). Useful when you want to find matches for a hypothetical or hand-drawn pattern.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max matches to return | |
| symbol | No | Reference symbol for scale | BTCUSDT |
| interval | No | Reference interval | 1h |
| token_id | No | Optional Manus access token. Paid tools use tokenized service access, not a monthly subscription: when token_id is omitted the server returns payment_required with a Solana Pay invoice, and after payment you retry with the same token while the server uses Manus token/resolve to recover pending access. | |
| queryValues | Yes | Array of price points representing the sketched pattern (e.g. [10, 11, 10.5, 12]) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It fails to disclose behavioral traits such as how the search works, data source, processing time, or that the tool requires payment (token_id only mentioned in schema). The description is too brief for a non-trivial 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?
Two sentences with no wasted words. The purpose is front-loaded and the description is efficient.
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 tool has no output schema and no annotations, yet the description does not explain the matching algorithm, return format, or limitations like the payment requirement. Important context is missing for a complex tool like sketch-based search.
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 all parameters described. The description adds no extra meaning beyond the schema, so baseline score 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 clearly states the verb 'Search' and the resource 'historical patterns' with the unique modifier 'custom sketched price trajectory'. It distinguishes the tool from sibling tools like pattern_search and find_market_analogs by emphasizing the sketch-based input.
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 says 'Useful when you want to find matches for a hypothetical or hand-drawn pattern', which implies the use case. However, it does not explicitly state when not to use it or compare to alternatives like pattern_search, leaving the agent to infer usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!