aipricepatterns

Query Market Memory

query_market_memory

Read-onlyIdempotent

Ask candle memory what happened after an event, and how that compares with ordinary windows. The question can be in any language: map it onto one event (move: close-to-close percent over N bars; excursion: a fall or rise inside N bars, recovered or not, which is what a trader usually means by 'fell 5%'; volume_spike; compression: a tight range; new_extreme: a new N-bar high or low; timestamps: dates the user names; level: a break or a test of support or resistance the engine finds itself without lookahead, a swing high or low, the previous day's or week's high or low, or a round number, where result.level counts how often the level failed within failWithinBars), optional context (UTC session or hours, weekday or weekend, volatility regime, above or below a moving average, event volume, distance from the high) and horizonBars. Convert days to bars for the interval yourself (30 days on 4h is 180 bars). Returns counts, outcome and baseline with 95% intervals, a split by era (or session, regime, trend), shape groups when groupBy is shape, dated episodes with chart links, a picture without words, and verdict flags. Answer in the user's language. Translate the rule, tags and legend; keep numbers as returned. Quote the event count, the baseline count and both outcomes side by side. Show picture.terminal in a code block unchanged, then the legend in the user's language. Say every verdict flag in words. Quote NO_TRADE verbatim. Never name a side or a size. Do not compute a statistic the result does not contain. Ask the engine instead.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "event": "<event>"
    },
    "name": "query_market_memory"
  }
}

Input Schema

Name	Required	Description	Default
`to`	No	UTC date, inclusive.
`draw`	No	median: the median form of all events. episodes: small charts of the first listed events.	median
`from`	No	UTC date, inclusive. Default: all stored history.
`event`	Yes
`symbol`	No		BTCUSDT
`context`	No
`groupBy`	No	shape clusters the events by the form of the bars before them, 2 to 4 groups, each with its own outcome.	none
`splitBy`	No	Second table: the same outcome split by this. era is on by default so a result that only held in one period shows.	era
`episodes`	No	How many individual events to list with dates and links.
`interval`	No		1h
`horizonBars`	No	Bars after the event whose path is reported.
`episodeOrder`	No		recent
`lookbackBars`	No	Baseline for volume and range ratios.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint, openWorldHint), so the description is not needed for that. It nevertheless discloses useful behavior beyond the schema: results carry counts, outcome, baseline with 95% intervals, an era split by default ('so a result that only held in one period shows'), dated episodes with links, an ASCII picture, and verdict flags including a literal NO_TRADE. The caveats that levels are found 'without lookahead' and that the engine 'has no calendar' are genuinely valuable behavioral disclosures.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core description is a single sprawling sentence whose parenthetical enumerations of event types and level subtypes nest two levels deep, making it hard to scan. Roughly half the text is agent output-rendering instruction (language handling, quoting NO_TRADE verbatim, painting picture.terminal, 'Never name a side or a size'), which buries the operative constraints in a wall of prose with no headings or ordering. Content is mostly relevant, but the packing is poor.

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?

For a 13-parameter tool with a large nested anyOf event object and no output schema, the description is unusually complete: it explains the return payload shape (counts, outcome, baseline intervals, split table, shape groups, episodes, picture, verdicts) and constrains the agent from fabricating statistics ('Do not compute a statistic the result does not contain. Ask the engine instead.'). The remaining gap is guidance on the secondary parameters (lookbackBars, episodeOrder, draw, symbol scope), which the description never mentions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 62%, so the description must compensate for the remainder, and it does add meaning: it explains that result.level counts failures within failWithinBars, gives the days-to-bars conversion rule, and enumerates the optional context axes (session, weekday/weekend, volatility regime, trend, event volume, distance from high) and horizonBars in plain language. It does not cover several schema parameters such as lookbackBars, episodeOrder, draw, symbols, or groupBy's 2-to-4-group output in depth, so it falls short of full compensation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a concrete verb and resource: 'Ask candle memory what happened after an event, and how that compares with ordinary windows.' That is a specific, testable purpose (event-conditional outcome vs. baseline) rather than a restatement of the name. It does not name any sibling tool to contrast with, so an agent must infer how it differs from evaluate_candle_hypothesis or investigate_candle_event_hypothesis.

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

Usage Guidelines3/5

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

Guidance is strong inside the tool – the 'move' vs 'excursion' distinction ('what a trader usually means by fell 5%'), the 'level' semantics, and 'Convert days to bars for the interval yourself' all steer correct invocation. However, there is no statement of when to prefer this tool over a sibling, no prerequisites, and no exclusions, so routing between the many candle-memory tools is left to inference.

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

All aipricepatterns tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?