TradeMemory Protocol

by mnemox-ai

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

evolution_discover_patterns

Analyze OHLCV data for a symbol via LLM to generate candidate trading patterns with entry/exit rules for backtesting.

Instructions

Discover trading patterns from market data using LLM analysis.

Uses Claude to analyze OHLCV data and generate candidate trading patterns with entry/exit conditions. Each pattern can be backtested afterward.

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": {
      "symbol": "<symbol>"
    },
    "name": "evolution_discover_patterns"
  }
}

Input Schema

Name	Required	Description	Default
`days`	No	Days of history to analyze (default 90)
`count`	No	Number of patterns to generate (default 5)
`symbol`	Yes	Trading pair (e.g. "BTCUSDT")
`timeframe`	No	Bar timeframe — "5m", "15m", "1h", "4h", "1d"	1h
`temperature`	No	LLM creativity 0-1 (default 0.7, higher = more diverse)

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.5.4Aug 2, 2026

TDQS

A3.8/5.0

Behavior3/5

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

The description discloses that the tool uses Claude (LLM) for analysis, which implies non-deterministic behavior and potential API costs. It also notes patterns are 'candidate' and can be backtested later, providing workflow context. However, with all annotations false and no mention of side effects, permissions, or failure modes, the description does not fully carry the transparency burden.

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 compact and front-loaded, using two short sentences to convey purpose and method, followed by a single sentence on the backtesting workflow. Every sentence adds value without repetition, and the structure is clean and scannable.

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?

The description covers the core aspects: what the tool does, how it works (LLM), the input data (OHLCV), output (patterns with entry/exit), and next steps (backtesting). Given that an output schema exists and the parameter schema is fully descriptive, the description is reasonably complete for agent decision-making, though it could mention prerequisites like data availability.

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?

All five parameters are fully documented in the schema (100% coverage), so the description adds little extra meaning. It mentions 'OHLCV data' (relevant to symbol/timeframe) and 'generate candidate patterns' (relevant to count), but these do not significantly enhance understanding beyond the schema descriptions. Baseline 3 is appropriate because the schema already handles parameter semantics.

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: 'Discover trading patterns from market data using LLM analysis.' It specifies the method (LLM/Claude), the input (OHLCV data), and the output (candidate patterns with entry/exit conditions). This distinguishes it from sibling tools like evolution_run_backtest (backtesting) and evolution_evolve_strategy (strategy evolution).

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?

The description implies a workflow by stating 'Each pattern can be backtested afterward,' but it does not explicitly say when to use this tool versus alternatives, nor does it provide prerequisites or exclusions. There is no direct guidance on choosing between this and the sibling tools, so usage context is only implicit.

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