Skip to main content
Glama
edgedepthhq

EdgeDepth Research MCP Server

Official
by edgedepthhq

Run a research scan (record_occurrences)

run_scan
Read-only

Execute a research_query.v2 scan to retrieve match counts, outcome summaries (30m to 24h MFE/MAE), reproducibility key, and page-1 example rows from recorded market conditions.

Instructions

Execute a research_query.v2 document over the deterministic engine and return counts, denominators, outcomes_summary, the reproducibility key and page-1 rows as the engine's canonical bytes. outcomes_summary carries forward outcomes over FOUR horizons per occurrence: 30m return, 1h MFE/MAE, and 4h and 24h return + MFE/MAE (record_result.v3), with a closed threshold ladder to +/-20 pct - "how often did this setup reach +5% within 24h, with how much drawdown" is answered by the summary over ALL occurrences. Completeness caveat: an occurrence closer to the end of recorded data than a horizon has that horizon ABSENT (counted in the absent tally, never a truncated or implied-zero outcome) - quote present, not total_matching, as the denominator for any horizon rate. Document-only input: stated chips are the only input the scan path accepts (use interpret_prose first if you have prose, then re-submit its document). CONTRACT (relay to the user): Echo the exact document and the reproducibility key to the user with the result. Rates come from outcomes_summary over all occurrences; page rows are examples, never the denominator. Outcome fields cannot be filtered; expect OUTCOME_IN_PREDICATE if tried. sequence.within accepts 15m/30m/1h/4h/12h/24h and the matching ISO aliases; both normalize to canonical ISO before hashing. identity.symbol must be an exact lowercase Binance USDT-M perpetual symbol: case, whitespace and separators are rejected. You may rerun freely: a rerun of the same document is served from cache (X-Research-Cache: hit), and reruns and 304 revalidations are free. SIZE: page rows carry full 33-feature setup vectors (~2 KB each); page.limit 50 returns ~120 KB, which can overflow an agent context. Counts, outcomes_summary and representatives are complete-result regardless of page size - set page.limit 1-5 unless you need row-level evidence, then page with next_page. PROJECTION: counts_by_symbol lists only instruments with at least one match; the number of zero-count instruments omitted is stated in a trailing note (absence = 0 matches, not missing data). Pass full_counts: true for the engine's verbatim canonical bytes with every zero entry.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
documentYesA complete research_query.v2 document (target record_occurrences, stated chips only). Call list_features for the grammar; do not invent field names.
full_countsNoTrue returns the engine's verbatim canonical bytes, including every zero-count instrument in counts_by_symbol (~150 KB+ for universe scans). Default omits zero-count entries and states how many were omitted.
if_none_matchNoAn ETag from a previous run to revalidate: identical data answers 304 and spends nothing. Pass it back verbatim (it may be weak, W/"...").
Behavior5/5

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

The description richly discloses behavioral traits beyond the readOnlyHint and openWorldHint annotations: caching and 304 revalidation behavior, absence of horizons in outcomes_summary, context size overflow risks, zero-count omission semantics, contract to echo document/key, and the OUTCOME_IN_PREDICATE error. No contradiction with annotations; in fact it elaborates on the read-only, cache-friendly nature.

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 dense and front-loaded, starting with the core purpose before diving into caveats. While lengthy, every sentence adds value for a complex tool. A slight structural improvement could be collapsing some repeated warnings, but it is well-organized and not redundant.

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?

Without an output schema, the description fully explains return values, the meaning of outcomes_summary across horizons, the role of page rows as examples, and the caveat about absent horizons. It also covers size limits, pagination, and zero-count handling—everything an agent needs to correctly invoke and interpret results.

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?

Despite 100% schema coverage, the description adds significant meaning beyond the schema: the document must contain 'stated chips only', full_counts returns 'verbatim canonical bytes' with size implications, and if_none_match is a weak ETag that can be revalidated. It also provides crucial domain semantics (e.g., exact lowercase Binance symbols) that the schema's brief descriptions lack.

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 a specific action: 'Execute a research_query.v2 document over the deterministic engine' and enumerates the outputs (counts, denominators, outcomes_summary, reproducibility key, page-1 rows). It distinguishes this from sibling tools by explicitly naming interpret_prose, list_features, next_page, and run_cohort as alternatives for different needs.

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-to-use guidance: use interpret_prose first for prose input, call list_features for grammar, use next_page for row-level evidence, and set page.limit 1-5 unless needed. It also clarifies when to pass full_counts: true and explicitly warns against filtering outcome fields. This is strong usage guidance with named alternatives and exclusions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/edgedepthhq/edgedepth-research-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server