TradeMemory Protocol

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.5.4
Disambiguation4/5
Tools have clear, detailed descriptions, but some overlap exists between evolution_run_backtest and validate_strategy, and between get_strategy_performance and evolution_get_log, which could cause misselection. Most tools are distinct enough for an agent to pick the right one with careful reading.
Naming Consistency4/5
The naming is mostly consistent with verb_noun snake_case, and the evolution_ prefix groups related tools well. However, validate_strategy lacks the prefix, and names like get_daily_root deviate slightly, so the pattern is not perfectly uniform.
Tool Count5/5
20 tools is a well-scoped number for a comprehensive trading memory and evolution system, covering memory operations, planning, evolution, backtesting, audit, and validation without feeling excessive or thin.
Completeness4/5
The tool surface covers core workflows such as memory storage, planning, evolution, and audit. Minor gaps exist, such as no explicit cancel_plan tool or a tool to list all plans, and evolution_fetch_market_data is restricted to Binance, but agents can generally work around these limitations.
Average 4.1/5 across 20 of 20 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 29 commits in the last 12 weeks
- Last stable release on July 28, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Queries' and 'Recall', implying a read-only operation, while annotations declare readOnlyHint=false. This is a contradiction. The description also doesn't disclose any side effects (e.g., updating recency scores) or the silent fallback from hybrid to pure OWM, which is only documented in the schema parameter.
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 concise, with a clear first sentence and a short paragraph giving relevant detail. Every sentence adds value, with no fluff or repetition.
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 tool with 9 parameters and an output schema, the description covers the main purpose, scoring factors, and return format. It lacks usage guidance and doesn't address the discrepancy with readOnlyHint=false, but the output schema presumably covers return structure, so overall it is mostly complete with a notable gap.
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?
Schema coverage is 100%, with detailed parameter descriptions including defaults and fallback behavior for use_hybrid. The description adds scoring dimensions (outcome quality, context similarity, recency, confidence, affective modulation), but these are not parameters; it doesn't provide additional meaning beyond the schema.
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 recalls memories using OWM outcome-weighted scoring, and specifies it queries episodic and semantic memories, returns ranked memories with score breakdown. This distinguishes it from sibling tools like remember_trade (write operation) and get_trade_reflection (single trade reflection).
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 the tool is for retrieving memories, but does not explicitly state when to use it versus alternatives such as get_trade_reflection or get_behavioral_analysis. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations are all false, so the description carries the burden of behavioral disclosure. It effectively communicates that the plan is stored in prospective memory and remains active until triggered, expired, or cancelled, giving useful lifecycle context beyond the structured schema.
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 three concise sentences with no filler. It opens with the main purpose, then adds storage and lifecycle details, each sentence earning its place.
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?
Given the rich input schema and presence of an output schema, the description adequately covers the tool's core behavior and lifecycle. It lacks examples or edge-case handling, but it is sufficient for a tool of this complexity.
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?
The input schema has 100% parameter description coverage, so the description does not need to repeat parameter details. It adds no extra parameter-specific semantics beyond the schema, so the baseline score of 3 is appropriate.
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 description clearly identifies the tool as creating a prospective trading plan that activates on conditions. It specifies the verb 'create' and the resource 'trading plan', and the activation rule distinguishes it from a general memory tool, though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It implies usage for setting up conditional trading plans but lacks exclusions, prerequisites, or comparisons to related tools like remember_trade or check_active_plans.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait: it expires plans past their expiry date. This goes beyond the basic annotations (readOnlyHint=false, idempotentHint=true) by clarifying that the tool mutates state. It also states it queries all active prospective plans, which adds scope. No contradictions with annotations.
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 highly concise, with two sentences that front-load the core purpose and then provide necessary details. There is no filler or redundant phrasing, making it easy to parse quickly.
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 main functionality, side effects, and context requirements. Since an output schema exists, it doesn't need to explain return values. It could mention prerequisites or the matching logic in more depth, but overall it is sufficiently complete.
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?
Schema coverage is 100% for both parameters (context_atr_d1, context_regime) with meaningful descriptions. The tool description only refers to 'provided context' without adding extra detail about the parameters, so it adds minimal value beyond the schema.
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: checking active trading plans against current market context, and explicitly mentions the expiration side-effect. This distinguishes it from sibling tools like create_trading_plan or evolution functions, making its purpose unambiguous.
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 when to use the tool (when reviewing active plans and cleaning up expired ones) but does not explicitly state alternatives or when not to use it. There is no mention of how it relates to other tools or any exclusions, so usage guidance remains implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, providing minimal behavioral signal. The description adds useful process details (LLM generation, in-sample/out-of-sample validation, elimination of weak hypotheses) and return value ('graduated strategies and graveyard'). It does not disclose potential side effects like resource usage or persistence, but it does not contradict the annotations.
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 front-loaded with a one-line summary ('Run full evolution loop — generate, backtest, select, eliminate.') followed by a concise elaboration. It contains no fluff and every sentence contributes to understanding the tool's behavior.
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 workflow, data splits, and return value, and an output schema exists so return format details are covered. It does not mention prerequisites or how it relates to sibling tools (e.g., whether it requires evolution_fetch_market_data first), but for a complex pipeline the description is sufficiently comprehensive.
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?
The input schema has 100% parameter description coverage, so the schema already explains every parameter. The description adds no direct parameter-level meaning beyond the schema, making the baseline 3 appropriate.
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 explicitly states 'Run full evolution loop' and lists the specific steps (generate, backtest, select, eliminate), making the tool's purpose unmistakable. It also differentiates itself from sibling tools like evolution_run_backtest and evolution_discover_patterns by focusing on the complete multi-generation pipeline rather than individual steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly defines the tool as a full-loop process, implying it should be used when the complete evolution workflow is needed. However, it does not explicitly mention alternatives or say 'use evolution_run_backtest for single backtests,' so it lacks explicit exclusion guidance but provides strong contextual clues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety profile: idempotentHint=true and destructiveHint=false. The description adds that data is sourced from Binance and that it downloads historical bars, which provides useful context. However, it does not disclose any side effects (e.g., whether data is stored locally) despite readOnlyHint=false, nor does it mention rate limits or data freshness. The annotation prevents a lower score, but the description itself could be richer.
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 extremely concise and front-loaded. Two sentences convey the core purpose and usage instruction with no wasted words. Every sentence earns its place, and the structure is easy to scan.
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 tool is simple and the description, combined with the schema and annotations, gives a clear picture of how to use it. However, a small gap remains: the description does not clarify how the fetched data is made available to downstream tools (e.g., whether it is stored, cached, or returned directly), especially given readOnlyHint=false. With an output schema present, return values are covered, but the side-effect behavior is somewhat ambiguous.
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?
The schema provides 100% coverage of parameters, each with clear descriptions and defaults. The description adds no parameter-specific details beyond the schema, so it does not increase understanding beyond what is already structured. Baseline 3 is appropriate given high schema coverage.
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 function with a specific verb and resource: "Fetch OHLCV market data from Binance for evolution analysis." It also mentions downloading historical price bars for backtesting and pattern discovery, which distinguishes it from sibling tools like discover_patterns and run_backtest that operate on the data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: "Use this before discover_patterns or run_backtest to get data." This names specific downstream tools and clarifies when this tool should be invoked. However, it does not mention alternative data sources or when not to use it, so it stops short of a full when/when-not/alternatives distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds minimal behavioral detail beyond the tool's name and purpose, so it does not significantly enrich understanding of side effects or execution behavior.
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 two sentences, front-loaded with the core purpose, and contains no filler. Every phrase adds value, making it highly concise and well-structured.
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?
Given the tool's simplicity, full schema coverage, and presence of an output schema, the description is largely sufficient. It could optionally specify whether stats are based on closed trades or open positions, but this is not critical for selection.
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?
Schema coverage is 100% and both parameters (symbol, strategy_name) have descriptions. The description adds no parameter-specific information beyond what the schema provides, so the baseline score of 3 is appropriate.
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 'Get aggregate performance stats per strategy,' using a specific verb and resource. It distinguishes the tool from siblings like get_behavioral_analysis or evolution_get_log by focusing on strategy-level performance evaluation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context: 'Use this to evaluate which strategies are working and which need adjustment.' It clearly indicates when to use the tool, though it does not mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by specifying the data source ('procedural memory'), the aggregate nature of the stats, and the exact metrics returned, which is context beyond the structured annotations.
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 two efficient sentences. The first sentence states the action and source, and the second lists the specific return values. No unnecessary words or redundant information, and the key verb is front-loaded.
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?
With a read-only, idempotent, non-destructive annotation set, an output schema, and fully documented parameters, the description provides sufficient context for the agent to correctly select and invoke the tool. It explains the source, the aggregate nature, and the key metrics returned, leaving no critical gaps.
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?
Schema description coverage is 100% (both symbol and strategy_name are described with 'Returns all if omitted'). The description itself does not add parameter details or syntax, and the schema already fully documents the parameters. Baseline 3 applies because the schema carries the heavy lifting.
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 function with a specific verb ('Get') and a well-defined resource ('behavioral analysis from procedural memory'). It enumerates the specific output metrics (hold times, disposition ratio, lot sizing variance, Kelly criterion comparison), which distinguishes it from sibling tools like get_strategy_performance or get_trade_reflection.
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 usage context by specifying the source (procedural memory) and aggregate nature, but it does not explicitly state when to use this tool over alternatives or provide exclusions. There is no mention of alternative tools or conditions where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds minimal behavioral context beyond that, only indicating that it returns context and reflection, which is largely implied by the tool name and output schema.
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 exactly two sentences, begins with the action verb 'Get', and includes a practical usage note. Every word earns its place, with no redundant or vague phrasing.
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?
For a simple read-only lookup with one parameter, full schema coverage, a complete set of annotations, and an output schema, the description provides all necessary context: what it does, when to use it, and its safety profile. It does not need to explain return values because the output schema exists.
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?
The input schema contains a single required parameter trade_id with a clear description, achieving 100% schema description coverage. The description adds no extra parameter semantics, but the schema already fully documents the parameter, so the baseline score of 3 is appropriate.
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 starts with a specific verb 'Get' and names the resource 'full context and reflection for a specific trade', clearly distinguishing it from sibling tools like remember_trade or get_strategy_performance. The second sentence reinforces its unique purpose by framing it as a deep-dive into a trade's reasoning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use this to deep-dive into a particular trade's reasoning and lessons.' This provides clear context, but it does not name alternative tools or mention exclusions, so it stops short of the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context beyond annotations: it explains the four tests performed, mentions the input format requirement (trade log or daily returns CSV), and adds educational/research-only and not-financial-advice disclaimers. It does not contradict the annotations.
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 moderately sized but well-structured: a one-line purpose statement, a disclaimer, a sentence on required input, and a numbered list of tests. Each sentence earns its place, though the test list could be slightly more compact. No filler or redundant phrasing is present, but it is not as tight as a two-sentence description.
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 tool with four statistical tests, an output schema, and full schema/annotation support, the description covers the essential aspects: purpose, tests, input format, and disclaimers. It does not describe the output structure, but the output schema exists and reduces the need to do so. It also does not mention error handling or performance constraints, but the complexity is adequately addressed. A 4 reflects solid completeness without being exhaustive.
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?
Schema description coverage is 100%, so the schema already fully describes all four parameters (file_path, format, strategy_name, num_strategies), including column details and defaults. The description's mention of CSV formats and the four tests adds only minimal extra meaning; it does not substantially deepen understanding beyond the schema. Baseline 3 is appropriate given full schema coverage.
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 uses a specific verb ('Validate') and names a concrete resource ('a trading strategy') while enumerating the exact statistical tests performed (DSR, Walk-Forward, Regime, CPCV). This clearly distinguishes it from siblings like evolution_run_backtest or get_strategy_performance, which focus on execution or reporting rather than statistical validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it is for validating strategies via statistical tests, and explicitly restricts use to educational/research purposes ('Not financial advice'). It does not name alternatives or state when not to use it, but the detailed test list implies the appropriate scenario, and the disclaimer sets boundaries. No alternate tool is mentioned, so a small deduction from 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false, so the agent knows repeated calls are safe and non-destructive. The description adds value by listing the specific evaluation criteria (sample size, memory quality, regime experience, streak state, drawdown), which gives behavioral insight beyond the structured annotations. No contradiction exists.
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 two sentences, front-loaded with the purpose and immediately followed by usage guidance and evaluation criteria. Every sentence contributes meaningful information with no redundancy or filler.
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 tool has an output schema (as noted) and annotations, so the description need not explain return values. It covers what the tool does, when to call it, and what it evaluates. It lacks explicit exclusions or alternative mentions, but for the tool's complexity, this is complete enough.
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?
Schema description coverage is 100%, so all parameters are well-documented. The description does not add additional parameter-level semantics beyond the schema; the mentioned criteria are internal evaluations, not parameter explanations. Baseline 3 is appropriate since the schema handles parameter meaning.
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 function: 'Check if the agent has sufficient data and confidence to trade.' It uses a specific verb ('check') and resource ('trade legitimacy'), and differentiates from siblings by focusing on pre-trade evaluation with explicit criteria (sample size, memory quality, regime experience, streak state, drawdown). This distinguishes it from related tools like check_active_plans or validate_strategy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs 'Call this before making any trade decision,' providing clear context for when to use the tool. It does not mention explicit alternatives or when not to use it, but the instruction is strong and the purpose is distinguishable from siblings, which is sufficient for a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and readOnlyHint=false. The description adds that the root summarises entries by `chained_at` and that rebuilding is possible, but does not disclose side effects such as overwriting the stored root or TSA failure behavior — these details only appear in the schema, not the description.
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 two short paragraphs, front-loaded with the core action in the first sentence. It provides concise domain context without repeating parameter schema details.
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 tool with an output schema and well-documented parameters, the description gives sufficient domain background and use-case context. It lacks explicit guidance on when `rebuild=True` is needed or that overwriting occurs, but the schema covers mechanics and the output schema covers returns — acceptable completeness.
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 the baseline is 3. The description adds crucial meaning by stating the date is a 'UTC date' and that entries are filtered by `chained_at` falling inside the UTC day — this timezone context is absent from the schema's dry 'YYYY-MM-DD format' description.
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 states 'Get (or rebuild) the daily Merkle root for a UTC date' — a clear verb+resource+scope. It distinguishes itself from sibling verification tools by focusing on obtaining/rebuilding a day-level root, not verifying individual hashes or chains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that verifying this root proves integrity of every TDR for that day 'without re-walking each one,' implying the tool is for whole-day integrity checks. It does not explicitly name alternatives or exclusions, but the context separates it from verify_audit_hash/chain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses an important behavioral trait not covered by annotations: 'Data is in-memory (resets on server restart).' This adds context about persistence and freshness that annotations (readOnlyHint, idempotentHint) do not provide. It also specifies the return scope ('from this session'), which is useful behavioral information. No contradiction with annotations.
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 two sentences: the first states the primary action, the second details the return contents and a critical caveat. It is front-loaded, efficient, and every sentence contributes value without redundancy. This is a model of concise structuring.
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?
Given the tool has no parameters, an output schema exists to define the return structure, and annotations cover safety behavior, the description provides all necessary contextual information: what the tool returns and the in-memory limitation. It is complete for a simple log retrieval tool.
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?
With zero parameters, the input schema is trivially complete, and the description need not elaborate on parameter semantics. The baseline for 0 params is 4, and the description appropriately does not attempt to invent parameter details. It adds no parameter-level information, but none is needed.
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 function: 'Get the log of past evolution runs from this session.' It specifies the resource (evolution runs log) and the action (get), and the additional details about returned content (graduated strategies, graveyard, token usage) make its purpose unambiguous. It is distinct from sibling tools like evolution_evolve_strategy or evolution_run_backtest, which perform different actions.
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 when to use the tool (when you need the history of evolution runs) but does not explicitly state alternatives or exclusions. It notes the session-scoped nature, which is a usage hint, but lacks direct comparison to other retrieval tools like get_strategy_performance or get_agent_state. This meets the 'implied usage' level but not explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds behavioral context beyond annotations by emphasizing a 'complete, tamper-evident record' and revealing that exported data includes 'memory context (similar trades, beliefs)', which is valuable for understanding what the output entails.
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 two sentences, front-loaded with the primary purpose, followed by a concise elaboration on the record's content and integrity. Every sentence contributes value with no redundancy or unnecessary detail.
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?
Given the output schema exists and the annotations cover safety, the description is complete enough. It explains what is exported, why (audit/compliance), and critical characteristics (tamper-evident, includes memory context). The optional parameters are fully specified in the schema, so no gaps remain.
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?
Schema description coverage is 100%, so all five parameters are already well-documented with types, defaults, and examples. The description does not add additional parameter-level meaning, and the baseline of 3 applies since the schema handles the heavy lifting.
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 'Exports Trading Decision Records' for 'audit and compliance review', which is a specific verb+resource combination. It distinguishes itself from sibling tools like verify_audit_hash and verify_audit_chain, which focus on verification rather than export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context ('for audit and compliance review') indicating when this tool is appropriate. However, it does not explicitly mention alternatives or state when not to use it. Sibling tools like verify_audit_hash are not referenced, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context by specifying the exact output fields (confidence, risk appetite, drawdown, streaks, equity) and a behavior: 'recommended action based on current drawdown severity.' This goes beyond the annotations without contradicting them.
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 two sentences, front-loaded with the core purpose, and the second sentence adds concise detail about return values. Every clause contributes meaningful information without redundancy.
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?
For a zero-parameter read-only tool with a rich output schema (present), the description sufficiently explains what the tool provides and the logic for the recommended action. No additional context is needed given the schema and annotations cover the safety profile.
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?
With zero parameters, the description has no parameter burden. The schema is trivially fully covered. Baseline for 0 params is 4, and the description adds no unnecessary parameter noise.
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: 'Get the current agent affective state' and enumerates specific components (confidence, risk, drawdown). It distinguishes from sibling tools by focusing on the agent's internal state rather than plans, performance, or reflections.
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 when to use this tool: when you need the current affective state. However, it does not explicitly mention alternatives or provide exclusion criteria. Sibling tool names suggest different purposes, but no direct comparison is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by explaining the verification algorithm (recompute SHA256 from stored inputs and compare) and the consequence of a mismatch (tampering). This goes beyond the annotations and gives the agent a clear model of behavior.
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 concise, two sentences, front-loaded with the core purpose. Every sentence earns its place without any fluff.
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?
This is a simple tool with a single required parameter, rich annotations, and an output schema present. The description explains both what it does and the verification logic, making it complete for the given complexity. Return values are already covered by the output schema.
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?
The input schema has 100% coverage with a clear description of trade_id. The tool description does not add further parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.
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 verifies the integrity of a Trading Decision Record and explains the mechanism: it recomputes the SHA256 data_hash and compares it with the original. This specific verb+resource distinguishes it from sibling tools like verify_audit_chain (which likely verifies the chain) and get_trade_reflection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear use case: verifying a single record for tampering. The singular 'a Trading Decision Record' provides context, but it does not explicitly name alternatives or exclusion scenarios (e.g., when to use verify_audit_chain instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false, establishing that repeated calls are safe and non-destructive. The description adds valuable context by explaining it 'runs a vectorized backtest' and 'Returns fitness metrics: Sharpe ratio, win rate, trade count, max drawdown, total PnL,' which helps the agent understand the tool's behavior and output beyond the annotations.
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 concise—two short sentences that front-load the core purpose ('Backtest a candidate pattern') and then provide necessary detail about the input and output. Every sentence contributes meaningful information with no redundancy.
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 tool's purpose, input origin, and output metrics, making it sufficiently complete for a backtest tool. While it doesn't elaborate on all parameters (days, symbol, timeframe), the schema fully documents those, and the description doesn't need to repeat them. The output schema exists, so detailed return documentation isn't required.
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 description coverage is 100%, so the baseline is 3. The description adds meaning by specifying that pattern_dict is 'from discover_patterns output', clarifying the expected structure and origin of the key required parameter. It doesn't repeat the schema's parameter details, but the added context about the input source is valuable.
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?
Description states a specific verb+resource: 'Backtest a candidate pattern against historical OHLCV data.' It clearly distinguishes from siblings like evolution_discover_patterns (which discovers patterns) and evolution_evolve_strategy (which evolves strategies).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the input comes 'from discover_patterns', giving clear context for when to use this tool (after pattern discovery). It doesn't explicitly name alternatives or exclusions, but the context is sufficient for an agent to infer appropriate usage relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations by listing the five factors it evaluates (regime match, position sizing vs Kelly, OWM similarity, risk state, historical pattern). The annotations already declare idempotentHint=true and destructiveHint=false, so the description does not need to repeat safety aspects. No contradiction exists.
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 tightly written in two sentences. The first sentence front-loads the primary purpose, and the second lists the five evaluation factors without any filler. Every word earns its place.
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?
Given the tool's complexity (7 parameters, output schema present, annotations provided), the description is complete. It explains what the tool does, when to use it, and what factors are considered. The output schema handles return-value details, so no further explanation is needed.
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%, giving the agent complete parameter documentation. The description goes a step further by grouping parameters conceptually: e.g., 'position sizing vs Kelly' connects to proposed_lot_size, and 'regime match' connects to context_regime. This semantic mapping adds value beyond the raw schema.
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 opens with a specific verb+resource: 'Compute Decision Quality Score before executing a trade.' It clearly distinguishes this from sibling tools by emphasizing that it evaluates the decision process (not outcome) across five named factors, which differentiates it from tools like check_trade_legitimacy or validate_strategy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use it: 'before executing a trade.' It provides strong contextual guidance, but it does not explicitly name alternatives or exclusion cases. Sibling tools exist for related purposes (e.g., check_trade_legitimacy, validate_strategy), but no comparison is given, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations by detailing the side effects: writes to episodic memory, auto-updates semantic (Bayesian), procedural (running averages + hold time + Kelly), affective (EWMA confidence/streaks), and writes to trade_records for backward compatibility. This level of disclosure is critical for a tool with significant side effects, and the annotations only indicate mutation (readOnly=false), not the full scope. No contradiction exists.
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: the first sentence states the core purpose, and the second sentence lists the side effects. Every sentence earns its place, with no fluff or redundant phrases. It delivers substantial information in just two sentences.
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?
Given the tool's complexity (17 parameters, multiple memory layers), the description provides a comprehensive overview of behavior and integration with the OWM system. It explains the automatic updates and backward compatibility, which is essential context. The output schema exists, so the description need not explain return values, and the input schema covers parameter details.
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?
Schema description coverage is 100%, so all 17 parameters are documented in the schema itself. The description adds no parameter-specific details beyond what the schema already provides. It does indirectly add context by explaining why the tool exists (e.g., 'Improves OWM scoring quality' is in the schema), but the description itself does not clarify parameter meanings. Thus a baseline of 3 is appropriate.
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: 'Store a trade into OWM multi-layer memory with automatic updates.' It specifies the resource (trade), the action (store), and the scope (multi-layer memory with automatic updates). It distinguishes itself from sibling read/query tools by explicitly listing the memory layers affected (episodic, semantic, procedural, affective, trade_records).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when a trade needs to be recorded into the OWM memory system with all automatic updates. It does not explicitly name alternative tools or state 'when not to use,' but the context is well defined. Given the sibling list includes many read/query tools, the write-oriented wording effectively differentiates it without needing explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint false), the description adds substantial context: the traversal algorithm, the exact hash relationship, and the meaning of return fields. It even clarifies edge semantics like `first_break_at` being None when verified=True, which is valuable for 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with three concise parts: a one-sentence purpose, a detailed algorithm explanation, and return value semantics. Every sentence adds necessary information with no redundancy or filler.
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?
Given the rich schema (100% coverage), strong annotations, and an output schema, the description fully round out the tool's behavior: it explains the verification logic, defaults, and return meaning. Nothing essential is missing for an agent to invoke and interpret results correctly.
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% for both parameters, so the baseline is 3. The description adds meaning by explaining that `from_seq` defaults to 1 (genesis record) and `to_seq` defaults to latest, complementing the schema's null defaults and making the runtime behavior explicit.
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: 'Verify the integrity of the audit chain.' It details the exact verification process—walking from `from_seq` to `to_seq`, checking `prev_hash` against `data_hash` and verifying the SHA256 computation—which fully distinguishes it from siblings like `verify_audit_hash`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the tool: it specifies the default range (genesis to latest) and how to constrain it via `from_seq`/`to_seq`. It does not explicitly mention alternatives or when not to use it, but the unique behavior makes the intended usage apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![tradememory-protocol MCP server](https://glama.ai/mcp/servers/mnemox-ai/tradememory-protocol/badges/card.svg)](https://glama.ai/mcp/servers/mnemox-ai/tradememory-protocol)

Score Badge

Copy to your README.md:

[![tradememory-protocol MCP server](https://glama.ai/mcp/servers/mnemox-ai/tradememory-protocol/badges/score.svg)](https://glama.ai/mcp/servers/mnemox-ai/tradememory-protocol)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/mnemox-ai/tradememory-protocol'

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