Skip to main content
Glama

Find analogous moments

find_analogs

Find the past moments whose price shape most resembles a given one, each with the path that followed it. Reach for this when what you hold is a moment and what you want is other moments shaped like it. If what you hold is a condition you can state, use query_history; if it is a kind of recurring event, use get_topic_outcomes; if you already have the moments and only want their paths drawn together, use get_price_paths. Matching is done by a model of ours: it reads the shape of the move before a moment rather than its level, so a quiet stretch can match a violent one and two moments thousands of dollars apart can be alike. Matches come back one by one and are never averaged; the spread between them is the answer. Each is point-in-time — what it reports was knowable at that moment, and what came after is labelled as having followed. Read the quality field before reading anything into the set. asset takes a symbol from list_coverage. at is a UTC ISO-8601 moment inside that asset's range; omit it to search from now. k is how many moments come back, and a call costs one answer for every ten of them. scale only sets the window the paths are drawn at — it does not change which moments are found. An asset kept at one value a day — list_coverage's searched says which — is matched and drawn on that one value, so the path after a moment is a bar or two rather than a curve and quality.range_median_pct comes back near zero. Read it before making anything of such a set.

Input Schema

NameRequiredDescriptionDefault
kNoHow many past moments to return. One answer per ten.
atNoUTC moment to search from, ISO 8601. Omit for now.
assetNoAsset symbol, e.g. BTC. list_coverage lists them.BTC
scaleNoWindow the paths are drawn at. One of 5m, 15m, 30m, 1h, 2h, 4h, 1d15m

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: matching is model-based on shape not level, results are returned individually and never averaged, each is point-in-time with forward outcomes labelled, and each call costs one answer per ten k. It also discloses the degraded case for flat-per-day assets and warns to read `quality` before interpreting results.

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

Conciseness3/5

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

Front-loaded with purpose and routing, which is good, but the second sentence restates the first in looser language and the closing flat-asset paragraph runs long. Roughly a quarter of the text could be cut without losing routing or behavioral signal.

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?

No output schema exists, so the description must describe returns, and it does: per-match paths, `quality`, `range_median_pct`, and the point-in-time framing. It stops short of saying what `quality` values mean or what happens when `at` falls outside the asset range, leaving a small interpretive gap.

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 100%, so baseline is 3; the description earns an extra point by clarifying that `scale` only sets the drawing window and does not change which moments are found, which the schema alone would not tell an agent. `at`, `k` and `asset` are consistent with the schema but add little beyond it.

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?

Names a specific verb and resource (find past moments whose price shape resembles a given one) and states the payload (the path that followed each). The shape-vs-condition framing makes it immediately distinguishable from query_history and get_topic_outcomes.

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 routes three sibling cases: a statable condition goes to query_history, a recurring event to get_topic_outcomes, already-held moments to get_price_paths. It also states the matching premise (you hold a moment, you want like-shaped moments), which is the condition that selects this tool.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources