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

With no annotations, the description carries the full burden of behavioral disclosure. It says nothing about merge-versus-overwrite behavior (append semantics live only in schema field descriptions), whether unknown trade IDs create records or error, what 'last' resolves to, or whether the write is idempotent — meaningful gaps for a mutation tool.

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?

A single front-loaded sentence with no filler, which is good for scanning. It is arguably too terse for an 11-parameter tool, but nothing in it 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?

Eleven optional parameters, no annotations, and an output schema present, yet the description never explains the append-by-default semantics, the 'last' default for trade, or failure behavior — all load-bearing for correct invocation. It is under-specified 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.

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

The description merely re-lists field names (setup, emotions, mistakes, notes, rating) already present in the schema, and omits the trade selector, symbol/on_date narrowing, followed_plan, and both replace flags entirely. At 55% schema coverage those undocumented parameters get no help from either source.

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 — add journal details (setup, emotions, mistakes, notes, rating) to a trade — and hints at scope by noting the trade is 'usually one synced from MT5', which implicitly separates it from log_trade. It stops short of naming siblings explicitly, so an agent must infer the boundary with log_trade on its own.

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?

'Usually one synced from MT5' implies this is for enriching existing trades rather than creating them, which is useful context against log_trade. However, there is no explicit when-to-use/when-not guidance, no mention of what happens when the trade is not found, and no direction on when to prefer log_trade or get_trade first.

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?

With no annotations, the description carries the full burden. It usefully discloses that deleted MT5 trades reappear on sync, which is real behavioral context, but never states that deletion is irreversible, what happens to attached notes/feedback/tags, or whether any confirmation/permission is required for a destructive mutation.

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?

A single front-loaded sentence with the core action first and the scoping caveat in parentheses. No wasted words.

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, and the MT5 caveat is helpful. But for a destructive, unannotated tool with an undocumented identifier parameter, the definition leaves gaps an agent would need filled before calling safely.

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 0% and there is one required parameter, trade_id, which the description does not explain at all — not its source, format, or whether it is the manual-trade identifier rather than an MT5 ticket. The description does not compensate for the coverage gap.

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 ('Delete a manually logged trade') and immediately narrows scope with the MT5 carve-out, which implicitly distinguishes it from sync_mt5 behavior. It never names a sibling explicitly, but the operation is unambiguous.

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 supplies an explicit exclusion ('MT5 trades can't be deleted') but offers no positive when-to-use criteria and no alternative for what an agent should do with MT5-sourced trades. Usage context 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?

With no annotations, the description must carry the safety profile, and 'Search' implies a read-only operation, which is reasonable. It also discloses the return shape (compact list plus total count), but does not explain whether limit truncates the list while total count reflects all matches, or how pagination beyond the first page works.

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 zero filler, front-loaded with the core action. The return-shape sentence is mildly redundant given an output schema exists, but it costs little.

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 needn't be detailed, but for a 13-parameter search tool with no annotations and thin schema descriptions, the definition is under-specified. Critical semantics such as list-vs-total behavior and filter interactions are left entirely unstated.

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 only 38% across 13 parameters, so the description should compensate, yet it mentions no parameters at all. It adds no meaning for the unenumerated filters (setup, emotion, mistake, source) or for how status/period interact with date_from/date_to.

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 ('Search trades') that an agent can act on immediately. It does not distinguish itself from siblings like get_trade or get_performance, so the agent must infer that this returns a filtered list rather than a single record or an aggregate.

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 when-to-use guidance, no exclusions, and no routing among the 16 siblings. Nothing tells the agent to prefer get_trade for a known ID, get_performance for aggregates, or get_calendar for date-bucketed views.

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?

No annotations exist, so the description bears the full burden; it does disclose the detection categories and that monetary cost accompanies them, which is useful context. However, it does not state that the operation is read-only, how flags are scored or thresholded, or how the period/date filters interact in practice.

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?

It is a single front-loaded sentence with no wasted clauses, and the most informative content (the specific flag categories) comes first. The trailing ellipsis and '...with cost' phrasing are slightly informal, but the definition is appropriately sized.

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 structure need not be explained, and all four parameters are fully documented in the schema. What is missing is calling context: how this diagnostic report should be used relative to the sibling performance and coaching tools, and what the report fundamentally contains beyond a flag list.

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 period enums, symbol suffix handling, and date range precedence. The description adds no parameter meaning beyond that, making the baseline 3 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 names a specific resource — behavioural red flags (revenge trading, overtrading, stops, early exits, sizing up after losses) — and adds that cost is reported. That is much more concrete than the tool name alone, though it never contrasts itself with siblings such as get_performance or get_coaching_context.

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 says nothing about when to call this versus get_performance, get_coaching_context, or find_trades, and gives no prerequisites or exclusions. The agent is left to infer that this is the diagnostic/behavioral counterpart to a plain performance report.

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?

No annotations, so the description must carry the behavioral load itself. 'Daily P&L' and 'trading days only' imply a read-only report and disclose that non-trading days are excluded, but the description never states that it is side-effect free, what happens on empty months, or whether it's scoped to a user/account. Adequate but thin for a zero-annotation tool.

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?

A single compact line that front-loads the primary payload (daily P&L) before secondary aggregates. No wasted words, though the sentence fragment style leaves the read/query nature implicit.

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 needn't be described, and the single parameter is fully documented in the schema. What remains missing is the read-only confirmation and any routing hint relative to the many sibling report tools, which matters given the crowded namespace.

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%, with the schema already documenting the YYYY-MM format and current-month default. The description adds nothing about the month parameter, so the baseline 3 applies even though the 'trading days only' note usefully frames how the month is interpreted.

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 the resource ('calendar') and specifies the exact content returned: daily P&L per trading day, weekly totals, and a month summary. It doesn't explicitly contrast itself with get_performance or get_instrument_breakdown, but the output shape is distinct enough that an agent can identify it.

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 use this versus get_performance, get_instrument_breakdown, or get_coaching_context. The only usage hint is the implicit default month from the schema, so the agent must infer the triggering scenario (e.g., 'show me my daily P&L for March').

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?

No annotations are provided, so the description carries the full burden; it implies a read-only aggregate via 'Everything needed...' but never states it explicitly, nor does it mention cost/size of a fan-out call or whether anything is persisted. The period-ignored-over-date-range rule and broker-suffix normalization exist only in the schema, not the prose.

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?

One sentence, front-loaded with the value proposition before the content list. The itemized enumeration is dense but each element conveys distinct return content rather than filler; there is mild redundancy with the output schema.

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, yet the enumeration usefully signals breadth for selection purposes. With four optional params fully documented and no side effects implied, the main omission is any statement of read-only behavior or call weight, which matters for an aggregate fan-out 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%, with all four optional params documented (defaults, date format, suffix handling), so the schema does the work. The description adds no param-level meaning beyond hinting that a comparison period is involved. 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 concrete composite deliverable ('everything needed for a coaching review in one call') and then enumerates the payload: stats vs previous period, per-instrument verdicts, breakdowns, behaviour flags, best/worst trades, notes, rules and prior action plan. That enumeration is what separates it from sibling aggregation tools like get_performance, get_instrument_breakdown and get_behavior_report. The verb is only implicit via the name, which keeps it out of the top band.

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?

'In one call' hints that this is the batch alternative to calling the individual breakdown/report tools, but the description never names those siblings or states when to prefer them. There are no exclusions, prerequisites, or guidance on period vs. explicit date ranges (which would matter since period is ignored when dates are supplied).

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?

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about read-only safety, side effects, or data requirements. It does disclose the analytical payload (verdict categories, red flags), which is useful, but it omits how verdicts are derived and whether the call is expensive or cached.

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 single sentence is compact and front-loads the key content categories with no filler. However, it is so terse that it reads as a label rather than a structured explanation, and the lack of a leading verb slightly weakens orientation.

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 needn't be explained, and parameters are fully documented. But with no annotations and no usage guidance, the definition is incomplete for distinguishing this analytical tool from overlapping siblings; an agent has no basis for choosing it over get_performance.

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% with three documented parameters, so the schema already explains the period window and date overrides. The description adds nothing about filtering semantics or default behavior beyond what the schema provides, making a baseline 3 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 names the resource (per-instrument breakdown) and enumerates the output content (verdict, best/worst sessions, insights, red flags), so an agent can infer what it produces. But it is a noun-phrase fragment with no verb, and it does not distinguish the tool from siblings like get_performance or get_behavior_report, both of which plausibly overlap.

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 when-to-use guidance, no prerequisites, and no mention of alternatives. The agent must guess whether to call this versus get_performance for instrument-level analysis. It also does not say whether it requires existing trade data or a minimum sample size for verdicts.

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?

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only reporting operation through its metric list and 'get' name, but does not explicitly disclose read-only behavior, authentication requirements, scoping limits, or other behavioral traits.

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 a single compact sentence that front-loads the metrics returned. It is efficient, though its telegraphic style leaves some clarity on the table.

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?

The output schema exists and all five parameters are optional and fully documented in the schema, so the description is sufficient for invocation. However, with no annotations and no sibling differentiation, it does not fully establish when or why to choose this reporting tool over adjacent ones.

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 parameter meanings are already fully documented in the schema. The description adds only a high-level hint about optional dimensional breakdown corresponding to group_by, which is appropriate but not substantial beyond the 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 concretely lists the performance metrics returned (win rate, P&L, profit factor, expectancy, R, drawdown, streaks) and notes optional dimensional breakdowns. It is clear what the tool does, though it does not explicitly differentiate itself from siblings like get_instrument_breakdown or get_behavior_report.

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 no guidance on when to use this tool versus alternatives in the sibling set. The only usage hint is that results can be broken down by dimension, with no exclusions or selection criteria.

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?

No annotations at all, so the description carries the full behavioral burden; it discloses scope of returned data but never states that this is a read-only, side-effect-free lookup or what happens on a missing id. The enumeration of returned fields adds genuine context, but key operational traits are left implicit.

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?

A single front-loaded sentence with no filler; every listed item earns its place by telling the agent what payload to expect.

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 document return structure, and it still gives a useful content preview. It is nearly complete for a one-parameter read, missing only explicit read-only framing and not-found behavior.

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 0% for trade_id, so the description must compensate; it only implies the parameter by saying 'one trade'. The meaning of trade_id is obvious enough in context but never spelled out (format, where to obtain it).

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 ('Full detail of one trade') and enumerates the exact content returned (prices, costs, R, MFE/MAE, deals, journal, behaviour flags). It is clearly a single-record fetch, implicitly distinct from find_trades, though no sibling is named.

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?

'One trade' implies you already have an identifier rather than searching, which is a reasonable usage signal. But there is no explicit when-to-use vs find_trades guidance, no preconditions, and no statement about behaviour when the id is invalid.

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?

No annotations, so the description carries the burden; it implies a safe read but never says so, nor whether results are cached or user-scoped. For a zero-param read tool this is a modest gap, but it does clarify the three vocabulary categories returned.

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 waste, with the resource identity front-loaded before the action guidance.

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 and no parameters, the description only needs to say what the tool yields and how to use it — both are covered. It stops just short of tying itself to the tagging siblings by name.

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 no parameters, so baseline is 4; the description correctly adds no parameter noise and instead frames the content of the response.

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?

Names the specific resource it returns — the user's setup, emotion and mistake vocabularies — which is concrete and distinguishable from siblings like annotate_trade or log_trade. Lacks an explicit verb ("list"/"retrieve"), so it reads as a noun phrase rather than a clear action.

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?

"Reuse these names when tagging" implies this should be called before tagging operations such as annotate_trade, but it never names the sibling or states the condition explicitly. Usage is inferable rather than stated.

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?

No annotations are provided, so the description carries the burden, and it does disclose two real behaviors: the record is persisted and returned, and validation feedback comes back as "warnings." It does not say what triggers a warning (duplicate detection against MT5? inconsistent close time?), whether the write is reversible or editable, or that required fields must come from the user's dictation rather than being inferred.

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, zero filler — the scoping condition is front-loaded and the return behavior is a compact second beat. Nothing here could be cut without losing meaning.

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 shape need not be explained, and the description correctly points at warnings. But for a 17-parameter mutation with no annotations, the definition says nothing about what happens on partial data, how the many optional trade-journal fields should be sourced from dictation, or what a warning implies for the caller.

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?

At 47% schema description coverage across 17 parameters, the description needs to compensate and adds nothing — no explanation of the journal metadata fields (setup, emotions, mistakes, followed_plan), the units for volume or stop_loss, or how pnl relates to entry/exit prices and commission. Only three parameters are documented in the schema at all, and the description mentions none of them.

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 (Log) and resource (a trade), plus a scope qualifier — trades the user dictates that are NOT in MT5, whether from another broker or unsynced. That qualifier alone separates it from the MT5-sync path and from annotate_trade/get_trade, so an agent can route without opening the schema.

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 negative condition "NOT in MT5 (other broker, or not synced)" plus "the user dictates" is a clear when-to-use signal. It stops short of naming the explicit alternative (sync_mt5) or stating what to do when a trade turns out to be in MT5, so it is not a full when/when-not/alternatives treatment.

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?

With no annotations, the description carries the full burden. It usefully discloses the downstream effect (the report becomes visible in the web app on two page types) and an authoring constraint, but says nothing about overwrite/upsert behavior, whether repeated saves duplicate, permissions, or limits on report size.

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 action and its effect, then a single authoring constraint. Nothing redundant or padded.

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?

For a write tool with no annotations, the description covers what happens and one quality rule, and an output schema exists so return values need not be explained. It is still thin on mutation semantics (create vs update), on how 'kind' relates to 'symbol'/'instruments', and on how the report content should be sourced.

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 single top-level parameter 'report' is undocumented in both the description and the schema, though nested fields carry their own descriptions. The description adds one meaningful content rule ('every claim should be backed by numbers from the journal') but no structural guidance about which sections to populate for which 'kind'.

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 ('Save a coaching review') and adds the effect ('shows in the web app, AI Coach page and each instrument's page'), which is concrete. It does not explicitly differentiate from save_trade_feedback, the nearest sibling, so it falls 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?

Usage is implied by the visibility note (this is the way to surface a review in the app), and the 'backed by numbers' sentence hints at content expectations. There is no explicit when-to-use / when-not-to-use versus save_trade_feedback, and no prerequisite guidance such as whether a review must be generated first.

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?

No annotations are provided, so the description carries the full behavioral burden. It implies a write operation but does not disclose whether existing feedback is overwritten, what permissions are required, or what happens if the trade_id is invalid. The note that feedback is shown on the trade's page is helpful but insufficient for a mutation tool.

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 a single front-loaded sentence with no wasted words. It immediately identifies the action, resource, and visibility scope.

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?

For a simple two-parameter save tool with an output schema, the description covers the core action and display location. However, with no annotations and only 50% schema coverage, it leaves important behavioral details such as overwrite behavior, validation errors, and prerequisites 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?

Schema coverage is 50%: feedback has a schema description, while trade_id is undocumented but self-explanatory. The description adds some meaning by clarifying that the feedback is AI feedback attached to a single trade, but it does not explain format, length, or overwrite semantics.

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: attach AI feedback to a single trade. It also clarifies the effect is visible on the trade's page. It does not explicitly distinguish itself from sibling tools like annotate_trade or save_ai_report, so it falls 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 gives no explicit guidance on when to use this tool versus alternatives such as annotate_trade, write_day_note, or save_ai_report. Usage is only weakly implied by the mention of AI feedback on a single trade, leaving the agent to infer the correct context.

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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that the rules are later read by coaching reviews, which explains the persistence purpose. However, it omits whether saving replaces prior rules (overwrite vs append), whether a partial rules text is acceptable, and whether confirmation is needed.

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?

One sentence, zero filler, with the core action front-loaded and the rationale trailing. It is efficiently sized for a one-parameter tool, though the brevity leaves gaps that a second short clause could have closed.

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 single parameter is fully documented in the schema. What remains missing is behavioral: overwrite semantics and how the rules interact with the behavior/coaching reports. For a simple persistence tool this is adequate but not 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 coverage is 100% with a single parameter already documented as 'The user's full trading plan/rules as text.' The description's phrasing ('written trading rules') adds no format, length, or completeness guidance 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 and resource: save the user's written trading rules. It also hints at downstream consumers (coaching reviews), which clarifies what the stored data is for. It doesn't distinguish itself from near-siblings like save_trade_feedback or save_ai_report, which also save user-authored text.

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 only implied: use when the user has written trading rules to persist. There is no explicit guidance on when to prefer this over save_trade_feedback or write_day_note, nor any precondition such as 'call only after the user has articulated a full plan.'

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?

No annotations are provided, so the description carries the full burden of disclosure. It does not say whether the sync writes/overwrites local trade data, whether it is idempotent, how long it may take, or whether duplicates are created — significant gaps for a tool that mutates stored state.

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?

A single tight sentence with the action front-loaded and zero waste. It is efficient, though it borders on under-specification given the behavioral gaps.

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 needn't be explained, and the parameter is fully documented. However, for a state-changing sync tool with no annotations, the description omits operational context an agent needs (source availability, side effects, duration).

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 `force` parameter is already documented as 'Re-read every file and rebuild all trades'. The description adds no additional meaning about `force`, 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 and resource ('Pull the latest trades from MT5') with temporal immediacy ('right now'), which distinguishes it from read-only siblings like find_trades and get_trade. It doesn't explicitly name those siblings, so an agent must infer the sync-vs-query distinction.

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?

'Right now' implies the tool is for on-demand refresh, which hints at when to call it, but there is no explicit guidance on when to use this versus find_trades/get_trade, nor any stated preconditions (e.g., MT5 must be running) 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?

The description usefully discloses that text is appended rather than overwritten, which is important mutation behavior for a tool with no annotations. It does not clarify whether mood or rules_followed are overwritten, what permissions are needed, or what the final note structure looks like.

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 a single efficient sentence with the key append behavior front-loaded. Nothing is redundant, though it could be slightly more organized to cover the other note fields.

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?

A mutation tool with no annotations and five optional parameters needs more behavioral context than this. The append behavior for free text is covered and an output schema exists, but the roles of mood and rules_followed remain unclear.

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 only 40%, so the description should compensate for undocumented parameters. It only indirectly references pre_session_plan and post_session_review, and says nothing about day defaulting to today, mood, or rules_followed.

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 uses a specific verb and resource ('Save ... day note') and names the two main content fields, pre-session plan and post-session review. It is clear what operation is performed, though it does not explicitly distinguish itself from sibling save/log tools.

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 mention of pre-session planning and post-session review implies when the tool is useful. However, there is no explicit guidance on when to choose this over other save tools (e.g., save_trade_feedback or save_ai_report), and no exclusions are stated.

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