TradeMemory Protocol

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

Annotations declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and the description usefully explains why it is not a pure read: it expires plans past their expiry date, a side effect the annotations alone do not spell out. It also clarifies the scope of the write (only plans past expiry) and that matching is done against supplied context, though it does not state what happens to plans whose context fields are null.

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

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

Two short sentences, zero filler, and the operational steps are front-loaded immediately after the one-line purpose statement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the mutation semantics are covered. The remaining gap is that both parameters are optional yet the description never says how the tool behaves when context is omitted, which matters for a matching operation.

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

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

Schema description coverage is 100% and both context parameters (context_atr_d1, context_regime) are documented in the schema with units and an enum-like value list. The description only refers generically to 'the provided context', adding no format or defaulting meaning beyond the schema, so the baseline of 3 applies.

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

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

The description gives a specific verb and resource ('Check active trading plans') and then breaks the operation into its three concrete steps: query active prospective plans, expire stale ones, and match against context. It is clearly distinguishable from the read-only siblings like get_strategy_performance, though it never names an alternative tool directly.

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

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

Usage is implied by the described lifecycle (query, expire, match), which suggests this is a periodic maintenance/validation call, but there is no explicit statement of when to invoke it versus create_trading_plan or validate_strategy, and no prerequisites or exclusions are given.

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

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

Annotations declare readOnlyHint=false and idempotentHint=true, which is slightly unusual for what reads as an evaluative check; the description explains it's a gating decision ('earned the right to trade at full size') rather than a mutation, adding useful behavioral context. It stops short of describing the return semantics or thresholds, but output schema exists to cover that.

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

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

Two short sentences, front-loaded with the core purpose and followed by the timing instruction. Efficient and easy to scan, though the second sentence packs several evaluation factors into a list.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists and full schema coverage, the description needn't detail return values. It adequately conveys purpose, timing, and evaluated dimensions for a decision-gating tool.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters thoroughly, giving a baseline of 3. The description adds no extra parameter-level meaning beyond indicating what is evaluated.

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

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

The description states a specific purpose: checking whether the agent has sufficient data and confidence to trade, and it lists the evaluated factors (sample size, memory quality, regime experience, streak state, drawdown). It's distinguishable from siblings like validate_strategy or get_agent_state, though the description does not explicitly contrast with them.

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

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

It gives a clear timing cue: 'Call this before making any trade decision.' This tells the agent when to use it, but it doesn't name alternatives or when-not-to-use cases (e.g., versus validate_strategy or compute_dqs).

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

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

Annotations declare readOnlyHint=false, destructiveHint=false and idempotentHint=true, so the safety profile is partly covered. The description adds the evaluation basis (process vs outcome, five named factors), which is genuinely useful. But it never explains why a 'compute' operation is not read-only — whether it persists a score, writes state, or has side effects — so a real behavioral gap remains.

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

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

Two tight sentences, front-loaded with the action and the timing constraint, followed by the factor list. Nothing is padding, though the factor enumeration could have been left to explain further downstream detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained here. The description supplies the scoring model at a level suitable for deciding to call it. It is slightly incomplete on side effects and on how the five factors combine, but covers the essentials for a scoring tool.

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

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 and the schema already documents all seven inputs. The description does indirectly map factors to inputs (context_regime to regime match, proposed_lot_size to Kelly sizing), which adds orientation, but provides no syntax, format, or fallback behavior beyond that.

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

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

The description gives a specific verb and resource ('Compute Decision Quality Score') and scopes it to timing ('before executing a trade'), then enumerates the five scoring factors. That is far more concrete than a restated title. It stops short of differentiating itself from close siblings like check_trade_legitimacy or validate_strategy, which an agent would plausibly confuse it with.

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

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

There is a clear timing cue ('before executing a trade'), which implies the intended usage point. However, no alternative or exclusion is named despite several overlapping siblings (check_trade_legitimacy, validate_strategy, create_trading_plan), so the agent must infer which pre-trade check applies.

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

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

Annotations already establish this is a non-read-only, non-destructive, non-idempotent write, so the bar is lower; the description adds genuinely useful state behavior — the plan persists until triggered, expired, or cancelled. It stops short of noting authorization needs, what happens on duplicate plans (relevant given idempotentHint=false), or any rate/size limits.

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

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

Three short sentences, front-loaded with the core action and followed by lifecycle context; nothing is padded. Minor overlap between 'prospective trading plan' and 'prospective memory' costs it the top score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and the schema fully documents the six parameters. The lifecycle sentence completes the picture; only the relationship to 'check_active_plans' and the consequences of a non-idempotent create are unaddressed.

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

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

With 100% schema description coverage, every parameter including priority, expiry_days, trigger_type, planned_action, trigger_condition, and reasoning is already documented in the schema. The description adds no syntax, format, or example detail beyond it, so the baseline 3 applies.

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

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

The description states a specific verb and resource ('Create a prospective trading plan') and clarifies the defining behavior — activation on met conditions. It doesn't explicitly contrast with the related sibling 'check_active_plans', which is the main thing an agent would confuse this with when looking for existing plans.

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

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

The description explains the plan's lifecycle but never says when an agent should create a plan rather than, say, record a memory ('remember_trade') or inspect existing plans ('check_active_plans'). No alternatives or prerequisites are named, so the routing decision 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.

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

Annotations declare a non-read-only, non-idempotent, closed-world operation, and the description usefully adds that generation is LLM-driven with an associated temperature concept. However, it does not disclose what side effects occur (are patterns persisted?), that repeat calls yield different results, or any latency/cost implications of the LLM call.

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

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

Three short sentences, front-loaded with the core purpose, then method, then follow-on step. Minor redundancy between 'using LLM analysis' and 'Uses Claude,' but no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be described, and the schema fully covers parameters. The description conveys purpose, method, and the downstream backtest step, leaving only small gaps around persistence and non-determinism.

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

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

Schema description coverage is 100%, so all five parameters (symbol, days, count, timeframe, temperature) are already documented with defaults and examples. The description mentions OHLCV and entry/exit conditions but adds no syntax or constraint detail beyond the schema, so the baseline applies.

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

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

States a specific verb and resource ('Discover trading patterns') plus the method ('LLM analysis', 'Uses Claude'). It implicitly separates itself from siblings by noting patterns 'can be backtested afterward' (vs. evolution_run_backtest) and that it consumes OHLCV data (vs. evolution_fetch_market_data). The boundary against evolution_evolve_strategy is not spelled out, so it stops short of a 5.

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

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

The description sketches the workflow ('generate candidate patterns... backtested afterward') but never states when to choose this tool over evolution_evolve_strategy or validate_strategy, and gives no prerequisites or exclusions. Usage is implied rather than directed.

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

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

Annotations already establish the write/non-idempotent/non-destructive profile, and the description adds real behavioral substance: LLM-driven candidate generation, in-sample backtesting, out-of-sample validation of survivors, and elimination of weak hypotheses, plus what the result contains (graduated strategies and graveyard). It does not disclose that results are persisted (consistent with readOnlyHint=false), nor runtime/cost expectations for an LLM-plus-backtest loop.

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

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

The pipeline summary is front-loaded in the first line and the second sentence elaborates with distinct detail rather than restating. There is mild redundancy between 'generate, backtest, select, eliminate' and the subsequent sentence, but overall it is tight and worth its length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need no elaboration, and the description still characterizes the return as graduated strategies plus a graveyard. The multi-stage process an agent must anticipate for a five-parameter orchestration tool is adequately conveyed, with only cost/latency and side effects left implicit.

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

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

Schema description coverage is 100%, so symbol, days, timeframe, generations, and population_size are already fully documented in the schema with defaults and enum-like values. The description adds no parameter-level meaning beyond that, leaving this at the baseline for a well-covered schema.

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

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

The description names a specific verb and resource ('Run full evolution loop') and enumerates the four internal stages (generate, backtest, select, eliminate), which distinguishes it from nitty-gritty siblings like evolution_run_backtest or evolution_discover_patterns. It stops short of naming those siblings explicitly, so the differentiation is inferred rather than stated.

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

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

The phrase 'Run full evolution loop' implies this is the end-to-end orchestrator rather than a single step, which is useful context against the granular evolution_* siblings. However, it never states when to prefer this tool over chaining evolution_discover_patterns + evolution_run_backtest, nor any prerequisites or exclusions.

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

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

Annotations declare readOnlyHint=false but idempotentHint=true and destructiveHint=false, so the safety profile is already largely covered by structured data. The description adds that data comes from Binance (an external/open-world source) and that it supports backtesting and pattern discovery, which complements the openWorldHint. No contradiction, but the description doesn't resolve the apparent readOnly=false vs. non-destructive nature on its own.

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

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

Three short sentences, front-loaded with the core action and source. Slightly split between two sentences that could merge, but no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values don't need explanation. Description covers purpose, external source, and pipeline ordering. Could be complete except that it doesn't clarify the readOnly=false annotation implication (why a fetch isn't read-only), a minor gap given rich schema and output schema.

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

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

Schema description coverage is 100%, so symbol, timeframe, and days are all documented in the schema with examples and defaults. The description adds no parameter-specific syntax or format information beyond what the schema already carries. Baseline 3 is correct.

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

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

States a specific verb (Fetch), resource (OHLCV market data), and source (Binance), plus the purpose (evolution analysis). Distinguished from siblings discover_patterns and run_backtest by explicitly noting this is the data-acquisition predecessor.

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

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

Explicitly says to use this 'before discover_patterns or run_backtest to get data', giving clear ordering context. No exclusion conditions, but the sequencing guidance is unambiguous for the pipeline.

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

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

Annotations already cover readOnly, idempotent, and non-destructive traits. The description adds meaningful context beyond annotations: the data is in-memory and resets on server restart, which is critical operational knowledge. It also enumerates what the log contains.

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

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

Three sentences, each earning its place: purpose, return contents, and the ephemeral-data caveat. Front-loaded and free of filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return value structure need not be detailed. The description covers purpose, session scope, contents summary, and the in-memory reset caveat – everything an agent needs to call this no-parameter tool correctly.

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

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

Zero parameters, so baseline is 4. The description does not need to document parameters, and it correctly focuses on return contents instead.

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

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

States a specific verb (get) and resource (log of past evolution runs) with clear scope (from this session). Easily distinguished from siblings like evolution_run_backtest or evolution_evolve_strategy.

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

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

Implies usage context by mentioning the session scope, but does not explicitly state when to use this versus alternatives like get_strategy_performance or export_audit_trail. Usage is inferable but not guided.

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

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

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the description adds 'vectorized' as a mild performance hint. However, it does not explain why a seemingly pure computation is flagged readOnlyHint=false (e.g., writes a log or caches results), leaving that inconsistency unaddressed.

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

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

Two tight paragraphs, front-loaded with the core action, no filler. The trailing metrics list is partly redundant given an output schema exists, costing a small amount of value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the return-value list is redundant, and full schema coverage handles parameters. The remaining gap is behavioral: no guidance on when to choose this over sibling analysis tools and no explanation of the non-read-only side effects implied by annotations.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema, including pattern_dict coming from discover_patterns. The description's 'pattern dict (from discover_patterns)' merely restates the schema, adding no new syntax or constraints.

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

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

States a specific verb (backtest) and resource (a candidate pattern against historical OHLCV data), and identifies the upstream producer of the input ('from discover_patterns'). An agent can immediately distinguish this from siblings like evolution_evolve_strategy 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.

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

It implies a workflow by naming discover_patterns as the source of pattern_dict, but never states when to backtest versus validate_strategy or evolve_strategy, nor any prerequisites or exclusions. Usage is implied rather than prescribed.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds some value by characterizing the output as a 'complete, tamper-evident record' and naming what it contains (memory context, similar trades, beliefs). It does not, however, describe pagination/limit behavior or export format beyond what the schema provides.

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

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

Two sentences, front-loaded with the purpose before the content detail. No filler or repetition; the second sentence earns its place by describing what the record includes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be explained, and annotations cover the safety profile. The description supplies purpose and record content, so it is largely complete, though it omits routing guidance to the related audit-verification tools.

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

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

Schema description coverage is 100%, so parameters (start, end, limit, strategy, trade_id) are fully documented in the schema, including the notable 'trade_id overrides other filters' rule. The description adds no additional parameter meaning, so the baseline 3 applies.

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

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

States a specific verb (Export) and resource (Trading Decision Records), and clarifies the content includes memory context. Clear enough to distinguish from generic tools, but does not explicitly differentiate from the closely related verify_audit_hash / verify_audit_chain / get_daily_root siblings.

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

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

'for audit and compliance review' implies the usage context, giving an agent a sense of when this is appropriate. However, there is no explicit when-to-use vs. when-not, and no routing to the verification siblings (verify_audit_hash, verify_audit_chain) that an agent might reasonably confuse this with.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the substantive behavioral detail that a 'recommended action based on current drawdown severity' is derived server-side, but says nothing about freshness, caching, or when state is recomputed.

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

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

Two short sentences, the purpose front-loaded and the returned fields grouped after it. Nothing is padded or redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no inputs, an output schema present, and annotations carrying the safety profile, the description only needs to convey purpose and rough content — which it does. The one omission is how this read-only snapshot relates to the behavioral-analysis and performance siblings.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The parenthetical field list adds mild color but no parameter meaning.

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

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

States a specific verb and resource ('Get the current agent affective state') and enumerates the state dimensions returned (confidence, risk, drawdown). An agent understands the purpose immediately, but the description never distinguishes this from the conceptually similar sibling get_behavioral_analysis.

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

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

There is no indication of when to call this versus alternatives such as get_behavioral_analysis, get_strategy_performance, or check_active_plans, nor any prerequisites. Usage is only implied by the name.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered. The description adds the useful facts that data comes from procedural memory and is pre-aggregated rather than raw trades, but says nothing about computation timing, latency, or whether results are recomputed on call.

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

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

Two short sentences with the core action front-loaded and the returned metrics listed compactly. Slightly redundant with the title, and the return-value enumeration duplicates what an output schema presumably already carries.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the return enumeration is more than strictly necessary, and annotations handle safety. The remaining gap is routing: with many sibling read/analysis tools, the description never says when this is the right call versus get_strategy_performance or get_trade_reflection.

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

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

Schema description coverage is 100% and both optional filter parameters (symbol, strategy_name) are documented in the schema, including the 'returns all if omitted' semantics. The description adds no parameter detail beyond the schema, so the baseline of 3 is correct.

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

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

States a specific verb+resource ('get behavioral analysis from procedural memory') and enumerates the aggregate outputs (hold times, disposition ratio, lot sizing variance, Kelly criterion). It is distinguishable from generic siblings, but it never explicitly contrasts itself with close alternatives such as 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.

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

The description contains no when-to-use guidance, no prerequisites, and no named alternatives. An agent must infer that this tool is for post-hoc behavioral diagnostics rather than performance review, which is exactly the gap that sibling tools get_strategy_performance and get_trade_reflection occupy.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, so the agent knows this can write while being repeatable. The description adds useful conceptual context about what the root covers and why it is trustworthy, but does not add operational context (rebuild overwriting stored data, TSA submission side effects) beyond what the schema and annotations already say.

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

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

Front-loaded with the core action, then a compact two-sentence rationale that earns its place by explaining the value proposition of the tool. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present the description need not explain return values, and annotations cover the safety profile, so the remaining burden is light. The description covers purpose and rationale well but leaves the get-vs-rebuild decision and its side effects under-described for a tool with two distinct operational modes.

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

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

Schema description coverage is 100%, so all four parameters (date, rebuild, request_tsa, include_token) are already fully documented in the schema. The description adds no parameter-level semantics beyond naming 'rebuild' in passing, so the baseline of 3 applies.

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

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

States a specific verb (get/rebuild) and resource (the daily Merkle root for a UTC date) and explains what the root summarises. It implicitly contrasts with chain-walking verification siblings, but never names verify_audit_chain or verify_audit_hash, so the differentiation is inferential rather than explicit.

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

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

The description conveys the conceptual use case (verifying a whole day's integrity from one 32-byte root) but gives no explicit when-to-use guidance and never names the alternative verification tools or states when a full chain walk is preferable. The 'or rebuild' branch is only hinted at, with conditions left to the schema.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety and repeatability profile is fully covered. The description adds only that results are aggregated per strategy, which is modest added value over the structured fields; it says nothing about caching, freshness, or scope of the aggregation.

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

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

Two short sentences, zero filler, with the core purpose front-loaded before the evaluative use case. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return-value detail is unnecessary, and the two optional filters are covered by the schema. The remaining gap is the absence of any indication of metric coverage (e.g., which stats are aggregated) or comparison semantics, but the definition is adequate for correct invocation.

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

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

Schema description coverage is 100%, so both filters (symbol, strategy_name) are already fully documented in the schema, including their default-all behavior. The description adds no syntax or semantics beyond that, so the baseline 3 applies.

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

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

The description states a specific verb and resource: 'Get aggregate performance stats per strategy.' An agent immediately knows this returns rolled-up per-strategy metrics. It does not, however, distinguish itself from sibling strategy tools like validate_strategy or evolution_run_backtest, so it stops short of a 5.

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

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

'Use this to evaluate which strategies are working and which need adjustment' implies the use case but gives no when-not guidance, no prerequisites, and does not name an alternative tool for related needs. Usage is inferable rather than explicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the agent knows this is a safe, repeatable local read. The description adds only that the content covers 'reasoning and lessons,' a small increment beyond the structured hints 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.

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

Two short sentences, no filler, with the core action front-loaded in the first sentence. Marginally wasteful in that the second sentence largely restates the first's intent rather than adding new information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be described, the single required parameter is fully covered, and annotations carry the safety profile. The definition is sufficient to invoke the tool, though it stops short of routing guidance among overlapping trade/memory siblings.

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

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

Schema coverage is 100% and the single trade_id parameter is already documented in the schema as 'The trade ID to look up.' The description adds no syntax, format, or lookup semantics beyond that, so the baseline of 3 applies.

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

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

States a specific verb+resource ('Get the full context and reflection for a specific trade'), so the agent knows exactly what is retrieved. However, it does not distinguish this tool from memory/analysis siblings like recall_memories or get_behavioral_analysis, which could plausibly surface trade reasoning.

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

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

'Use this to deep-dive into a particular trade's reasoning and lessons' gives an implied context for use but names no alternatives, exclusions, or prerequisites. With several overlapping trade/memory tools in the sibling list, explicit routing guidance is missing.

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

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

Annotations already declare idempotent=true, destructiveHint=false, and — somewhat surprisingly for a query tool — readOnlyHint=false. The description adds useful behavioral context by naming the scoring dimensions and stating that ranked results with score breakdown are returned. It does not address the readOnlyHint=false tension (e.g. whether recall mutates memory state/decay), so a moderate score is warranted.

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

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

The description is three short, front-loaded sentences with no filler; the ranking factors and return shape are conveyed efficiently. It could be slightly more compact, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description needn't explain return values, and it still summarizes what is returned (ranked memories with score breakdown). Together with full parameter coverage it is largely complete, missing only when-to-use routing against siblings.

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

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

Schema description coverage is 100% and all 9 parameters are documented in the schema, including hybrid_alpha, context_regime, and market_context. The description adds no parameter-level detail (e.g. the effect of limit or memory_types), so the baseline 3 applies.

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

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

The description states a specific verb (recall) and resource (episodic and semantic memories) and explains the OWM outcome-weighted scoring that distinguishes it from siblings like remember_trade. It's clear what the tool does, though it doesn't explicitly name the alternative retrieval/write tools it differs from.

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

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

No explicit when-to-use or when-not-to-use guidance is given, nor any mention of prerequisites or the sibling tools (e.g. remember_trade) that would be chosen instead. Usage is only implied by the word 'recall'.

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

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

Annotations declare non-readonly, non-idempotent, non-destructive, and the description adds substantial detail: which memory layers get written, that semantic updates use Bayesian methods, procedural uses running averages/Kelly, and affective uses EWMA. It also discloses backward-compat write to trade_records. This is real behavioral context beyond what annotations provide.

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

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

Four sentences, front-loaded with the main action and then detailing the memory layers. No wasted words; each clause adds information about write targets.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (17 params, multi-layer memory writes) and the presence of an output schema, the description covers the essential write behavior. It omits return-value details but those are in the output schema, which is acceptable.

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

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. The description doesn't mention any specific parameter semantics (e.g., how confidence or pnl_r feed into scoring), so it's baseline 3 for a fully-covered schema.

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

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

States a specific verb (store) and resource (trade) and clarifies the target system (OWM multi-layer memory). It doesn't explicitly differentiate from sibling recall_memories or get_trade_reflection, but the write-vs-read distinction is implied by 'Store'.

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

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

No guidance on when to call this versus alternatives like recall_memories or how often trades should be recorded. The description explains mechanics of what gets updated but never says when an agent should invoke it.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds meaningful behavioral context: it explains what each statistical test detects (overfitting, out-of-sample consistency, regime behavior, cross-validated stability), which is 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.

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

The purpose is front-loaded, which is good, but the four tests are named in the opening sentence and then re-listed in an overlapping numbered block, creating redundancy. The educational disclaimer is fine but the test list doubles up space without adding information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be explained. The description adequately covers inputs and the analytical steps for a validation tool. It is slightly thin on prerequisites (e.g., minimum data requirements) but otherwise complete.

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

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

Schema description coverage is 100%, so the schema already documents format, file_path, strategy_name, and num_strategies with their meanings and defaults. The description only echoes the CSV format options already in the schema, adding no new parameter detail; baseline 3 applies.

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

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

States a specific verb (validate) and resource (trading strategy) and enumerates the exact methods used (DSR, Walk-Forward, Regime, CPCV). This clearly distinguishes it from siblings like evolution_run_backtest and compute_dqs, which do different things.

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

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

It describes the input needed (trade log CSV or daily returns CSV) but gives no explicit guidance on when to use this versus evolution_run_backtest or the other analysis siblings, and no when-not conditions. Usage is implied by the description rather than spelled out.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds real behavioral value beyond that: the exact invariants checked, the default range (genesis to latest), and what a successful vs. broken result looks like. It stops short of noting cost/runtime on large chains or behavior when from_seq > to_seq.

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

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

Front-loads the purpose in one line, then explains the mechanism, defaults, and return contract in tight sentences. Slightly long, but every sentence carries information an agent needs to interpret the result; nothing is padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the return-value sentence is more than strictly required, but it usefully explains that verified=True with first_break_at=None means the range is intact. Combined with annotations and full schema coverage, the definition gives an agent everything needed to call and interpret the tool correctly.

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

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, but the description adds meaning: from_seq is the genesis record by default and to_seq runs through latest, and both bounds are framed as the inclusive verified range. Minor wording drift exists between the description's 'default: 1' and the schema's default of null, though the semantics ('from beginning') match.

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

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

States a specific verb and resource ('Verify the integrity of the audit chain') and immediately clarifies the scope by describing the walk from from_seq to to_seq. It implicitly distinguishes itself from the sibling verify_audit_hash by describing whole-chain linkage checks rather than single-hash verification, though it never names the sibling explicitly.

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

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

Usage is implied by the mechanics (walking the chain, checking prev_hash/data_hash linkage) and the defaults make the tool's natural invocation obvious. However, it never states when to reach for this over verify_audit_hash, get_daily_root, or export_audit_trail, nor any preconditions for running a verification.

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

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

Annotations already establish readOnly, idempotent and non-destructive behavior, so the safety profile is covered. The description adds genuine interpretive value beyond that: it discloses the internal mechanism (recompute from stored inputs) and what a mismatch signifies (tampering), which tells the agent how to read the result rather than just that it is a safe read.

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

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

Three short sentences, front-loaded with the purpose, followed by mechanism and the meaning of the outcome. No filler, no repetition of the title, every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be spelled out, and the mechanism plus mismatch semantics make the tool's behavior understandable for calling it. The only notable gap is the absence of any routing guidance against verify_audit_chain, which matters given the overlapping naming.

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

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

With a single parameter and 100% schema description coverage, the schema already documents trade_id fully (including the example format). The description adds no additional constraint, format, or scoping detail about the identifier, 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.

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

The description states a specific verb and resource (verify a Trading Decision Record) and even explains the mechanism (recompute SHA256 data_hash and compare against the decision-time hash). It is clear and self-contained, but it never names or distinguishes itself from the close sibling verify_audit_chain, which an agent could easily confuse it with.

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

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

Usage is implied: use this to check one record for tampering. There is no explicit statement of when to reach for this versus verify_audit_chain (chain-level verification) or export_audit_trail, leaving the agent to infer the selection rule from sibling names alone.

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