Chartgaze

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only a vague statement about correlations and influence, with no detail on data sources, timeframe behavior, cost/latency of multi-symbol comparison, or anything an agent couldn't infer from the name.

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, with the outcome framing second. Slightly padded by redundant phrasing ('cross-asset relationships, correlations') but no wasted 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?

No output schema exists, so the description must convey what a comparison returns; it only gestures at 'correlations and influence' without describing the shape or granularity of results. Adequate to attempt a call, but incomplete for predicting the response.

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 three parameters including the timeframe default. The description adds no format hints (e.g., how related_symbols like DXY/US10Y are interpreted) beyond what the schema provides, so 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 (compare) and resource (symbol vs. related markets), and the second sentence clarifies what the comparison yields (cross-asset relationships, correlations, influence). This distinguishes it reasonably from snapshot/context siblings, though it never names 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?

Usage is only implied: 'compare primary symbol against related markets' suggests multi-symbol analysis, but there is no explicit when-to-use versus get_market_context, get_market_snapshot, or get_historical_context, and no exclusions or prerequisites.

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, destructiveHint=false and openWorldHint=false, so the write/safety profile is covered. The description adds that the alert is surfaced on 'ChartGaze Trade and alerts', which hints at a persistent, user-visible side effect, but it says nothing about duplicates, replacement behavior, or what is 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, front-loaded with the core action, and no filler. The second sentence partly duplicates the schema, which slightly reduces its value but costs little space.

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 three-parameter mutation with full schema coverage and annotations, this is barely sufficient. Given no output schema, the description should ideally indicate what the caller receives back (e.g., an alert id) and whether the alert persists immediately.

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 symbol, alert_type and the nested condition object. The description restates the direction enum values and condition.price, adding no syntax or edge-case meaning 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 gives a specific verb and resource ('Create a price alert') and names the product surface where it appears. It is clearly distinguishable from the delete/update/list alert siblings by its verb, though it never states that distinction 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?

There is no guidance on when to create a new alert versus calling update_market_alert, and no mention of prerequisites (account, symbol validity, alert limits). The only directive is about how to fill the condition object, which is parameter syntax, not usage 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?

The annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the mutation profile is known without the description. The description adds only the domain framing (organizing/monitoring symbols) and says nothing about duplicate-name behavior, symbol validation, or what a partially valid symbol list does.

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 well-formed sentence with the action front-loaded and zero filler. It is efficient, though its brevity leaves little room for the routing detail a create-vs-update decision needs.

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 two-parameter creation tool with annotations present and no output schema, the description is minimally sufficient to call it. It omits what is returned (e.g., a new watchlist identifier) and error/duplicate behavior, which an agent would want before invoking a create 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 coverage is 100% — both `name` and `symbols` are documented with optionality — so the schema carries the parameter burden and baseline 3 applies. The description adds no constraints such as name uniqueness or expected ticker format for symbols.

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+resource ("Create a new watchlist") plus the intent (organize and monitor trading symbols), which cleanly separates it from get_watchlist, update_watchlist, and delete_watchlist. It stops short of explicitly naming those siblings, so it isn't 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 only implied by the verb 'create' and the purpose phrase; there is no explicit when-to-use / when-not-to-use guidance. It never says to use update_watchlist instead when the watchlist already exists, nor does it mention prerequisites or limits on the number of watchlists.

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 explicitly states the operation is "permanent," which directly conflicts with the annotation destructiveHint=false (a hint that means only additive changes occur). An agent trusting the annotation would treat this as non-destructive and skip confirmation. The description is the accurate side here, but the contradiction is the dangerous part.

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 destructive consequence and the confirmation requirement front-loaded. Nothing is redundant and nothing needed is buried.

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 one-parameter mutation with no output schema, the description covers what is removed, that it is irreversible, and that the ID should be verified first. The remaining gap is the unresolved conflict with the destructive hint, which an agent cannot reconcile from the description alone.

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?

There is a single parameter at 100% schema coverage, and the schema already explains the ID comes from creation or listing. The description only adds a confirmation instruction, which is workflow rather than additional semantics for alert_id.

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?

"Delete one of your price alerts" names a specific verb (delete) and resource (price alert), and the verb alone separates it from list_market_alerts, create_market_alert, and update_market_alert. No agent could confuse this with a sibling.

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 a concrete pre-call workflow ("confirm the alert ID with the user before deleting") and a clear consequence that governs use. It does not mention alternatives — e.g. that update_market_alert should be used to modify rather than remove an alert — so it stops short of a 5.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the risk profile is known from structured data. The description adds nothing beyond that: it does not say whether the deletion is permanent, whether contained alerts/items are removed, or what happens when the ID does not exist.

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. It is short to the point of under-specification for a destructive operation, but the sentence itself is efficient.

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 destructive, irreversible mutation with no output schema and no parameter documentation, the definition omits the essentials: permanence, side effects, and how to source the ID. Annotations cover only the generic destructive hint.

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 0%, so the description carries weight; 'by ID' at least tells the agent the single parameter is an identifier. It still does not indicate the ID format (string, where to find it) or whether it must be an owned watchlist.

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?

Specific verb 'Delete' plus resource 'watchlists' with scope 'one of your watchlists by ID'. It is distinguishable from delete_market_alert by the resource noun, but the description never explicitly contrasts the two 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?

No guidance on when to delete versus update_watchlist, no note that get_watchlist should be used to obtain the ID, and no warning to confirm before calling. The agent must infer all preconditions from the name alone.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the useful fact that the result spans a full week of events, but says nothing about which week (current? calendar week?), timezone, or freshness. With annotations carrying the safety burden, this is adequate but thin.

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 resource stated first. 'At a glance' and the trading-planning line are mild marketing filler but cost little space and do convey scope and intent.

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 zero-param, no-output-schema tool, the description omits the things an agent most needs: which week is returned, what timezone/dates the events use, and roughly what the response looks like. Annotations cover the read-only nature, but the temporal scope remains ambiguous.

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 there is no parameter semantics to convey; baseline 4 applies. The description correctly does not pretend otherwise.

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 and scope: the full week of economic events. An agent can tell this is a weekly economic-calendar read, distinct from siblings like get_market_events or get_market_news. The verb 'See' is weak, but the resource 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?

'Plan your trading around major announcements' implies the use case (pre-event planning) but gives no explicit when-to-use/when-not and never names an alternative. With get_market_events in the sibling set, a routing sentence would have been valuable. Usage is implied only.

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 readOnly/openWorld/non-destructive, so the safety profile is covered. The description adds real behavioral substance beyond that: analysis is restricted to fully closed candles, so no look-ahead leakage in the base path, and date-only requests return a 1-hour OHLC summary plus multi-timeframe context as of end-of-day. It does not reconcile that no-look-ahead promise with include_forward_window.

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, front-loaded with the core constraint ('completed candles only') before the input forms. The final sentence partly repeats the date parameter's schema description, which is the only redundancy, but overall nothing is 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?

There is no output schema, so the description carries return-value burden, and it only explains the date-only response. It never says what a timestamp-addressed or time-addressed request returns, nor what include_forward_window does to the result, leaving an agent to guess on half the call shapes.

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%, so the baseline is 3, but the description contributes beyond the schema by making the date/time and ISO 8601 timestamp forms explicitly alternative addressings and by stating what a date-only request yields. The one parameter it omits entirely is include_forward_window, whose schema text ('Minutes to look forward') is the thinnest in the set.

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 — reconstruct historical market context — and scopes it to completed candles only, which separates it from live-context siblings like get_market_context and get_market_snapshot. It never names those siblings explicitly, so the differentiation is implied rather than asserted.

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 how to address a point in time (date + optional time, or an ISO 8601 timestamp) but says nothing about when to prefer this over get_market_context, get_market_snapshot, or get_market_events. Usage is implied by the word 'historical' rather than stated as a selection rule.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful behavior context by naming the returned dimensions (trend, structure, momentum, volatility) and the market_data_source metadata, which tells the agent this is a composite analysis rather than raw quotes. It does not mention cost, latency, or whether results are cached or live, so it stops short of rich disclosure.

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; the analysis scope is front-loaded and the return contents follow. No filler or marketing language. Slightly denser payoff could be achieved by trading the redundant timeframe enumeration for a pointer to the sibling that handles single-snapshot lookups.

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 annotations covering safety and a fully documented schema, the description's job is to convey scope and return shape, and it does both by listing the analysis dimensions. No output schema exists, yet the description enumerates the return fields, which compensates well. The remaining gap is the absence of any guidance on how this differs in cost or purpose from get_market_snapshot for the same symbol.

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 each of the four parameters is documented in the schema, including the default timeframe list, so the schema carries the burden. The description only repeats the timeframe set rather than adding syntax or validity rules (e.g. whether unsupported timeframe strings error or are ignored). Baseline 3.

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 multi-timeframe market analysis' with the exact timeframes enumerated (5m, 15m, 1h, 4h, 1D) and names the analysis dimensions returned. That clearly separates it from get_market_news or get_economic_calendar_week, but it never distinguishes it from the closest sibling, get_market_snapshot, so an agent must infer the boundary.

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 when-to-use guidance and no exclusion of alternatives. With siblings like get_market_snapshot, get_historical_context, and compare_markets all plausibly answering 'what is the market doing', the description leaves the routing decision entirely to inference. The only contextual hint is the schema note about account_id when brokers are linked.

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, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds the event categories returned, but omits a critical trait: all four parameters are optional, so what the tool returns with no time window (default range? everything?) is undisclosed, as are ordering and volume of results.

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 operation front-loaded. The trailing 'understand what's happening this week' carries little informational weight but does not obstruct comprehension.

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 output schema, the description must carry return-value information, and it only partly does by naming event types; it says nothing about result shape, ordering, or the all-optional-parameter default behavior. For an open-world calendar tool with four optional filters, that leaves real gaps.

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%, so each parameter is already documented at the field level. The description reinforces the 'time window' concept behind start_time/end_time but adds no syntax, default, or interaction detail beyond the schema. 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 and resource (get economic calendar) plus the contents it covers (high-impact events, earnings, central-bank decisions). However, it never distinguishes itself from the near-identical sibling get_economic_calendar_week, leaving the primary ambiguity unresolved.

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 explicit when-to-use or when-not guidance, and the presence of get_economic_calendar_week makes the omission costly: an agent has no basis to choose between the two. 'Understand what's happening this week' hints at a use case but reads as marketing rather than routing guidance.

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 readOnly, openWorld and non-destructive, so the safety profile is covered; the description adds genuine context on top: the backing store, a ~2-month retention limit that bounds valid input, and the UTC default. It stops short of explaining what 'news risk' actually contains in the response.

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 with no filler; the resource and scope come first, followed by the date defaults and filters. Every clause carries operational 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?

With no output schema, the description carries the burden of explaining return values, and 'news risk' is never unpacked — an agent cannot tell whether it gets a list of events, a risk score, counts, or severity ratings. Input-side coverage is solid, but the output side is a real gap for a tool whose payload is its whole reason to exist.

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 three parameters and the baseline is 3. The description adds only marginal value — it restates the date default and clarifies that symbol filters via currency pairs (EURUSD, XAUUSD) rather than raw instrument names, plus the retained-window constraint on date.

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 concrete resource and scope: economic-calendar news risk for a single day, sourced from ChartGaze DB. The 'for a day' framing implicitly separates it from the weekly sibling get_economic_calendar_week, but that sibling is never named, so differentiation is left to inference.

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 concrete operating guidance — default is today UTC, pass date=YYYY-MM-DD for any day in the cached window, symbol narrows by currency — which is enough to call it correctly. However it never says when to prefer this over get_economic_calendar_week or get_market_events, so the choice among siblings remains implied.

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/openWorld/non-destructive, so the description correctly focuses on what annotations can't say: the concrete return fields and the data-source caveat that quotes come from the general CAR feed and broker accounts are not yet used for OHLCV. That caveat is genuinely decision-relevant for an agent reasoning about data reliability.

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 purpose then return payload, no filler. The trailing parenthetical about data sources is dense but earns its place; only slight tightening would improve readability.

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 output schema, the description carries the burden of describing returns and does so by listing the field set, plus it discloses the data-source limitation. A minor gap: no mention of latency, streaming vs point-in-time, or nullability of fields like bid/ask for illiquid symbols.

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 both symbol and account_id documented in-schema including the cross-reference to get_trading_accounts, so the description need not repeat it. The description adds no parameter-level semantics beyond the schema, which is the expected baseline here.

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 live market state for a symbol') and enumerates the returned fields (price, bid/ask, volume, volatility, trend), so the agent knows exactly what it gets. It does not name a sibling such as compare_markets or get_market_context to draw the boundary, so it falls short of the 5 bar.

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 rather than stated: 'live market state' signals this is the current-snapshot tool versus get_historical_context or get_market_context, but no when-to-use or when-not-to-use rule is given. The note about broker accounts is a data-provenance caveat, not routing guidance.

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, openWorldHint=false and destructiveHint=false, so safety is covered structurally. The description's contribution is limited to noting the results are 'currently open' (live state, not historical) and scoped to linked accounts; it says nothing about staleness, ordering, or empty-result behavior.

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 compact sentences with the resource and the live-state qualifier front-loaded, followed by the safety profile and the optional filter. 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?

For a one-optional-parameter read tool with annotations covering safety and no output schema, the essentials are present. The gaps are minor: what a 'position' contains and whether omitting account_id aggregates across all linked accounts.

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 0% for the single parameter, so the description must carry it, and it does confirm account_id is optional and that it selects an account. It adds no format, default, or behavior when the value is omitted (are all accounts returned?) or what happens with an unknown account_id.

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?

A specific verb and resource ('List currently open positions') with the scope 'on your linked trading accounts', which distinguishes it from the account-management sibling get_trading_accounts. It stops short of naming a sibling alternative 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?

'Optionally select account_id' implies the when-to-narrow case, but the description gives no explicit guidance on when to call this versus get_trading_accounts or get_trade_history, and states no prerequisites (e.g. needing a linked account).

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the useful scope note that this returns historical fills rather than live positions, but says nothing about pagination behavior, the limit default, or what happens when no filters are supplied.

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 with the scope distinction front-loaded before the parameter list; 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?

With zero schema descriptions and no output schema, the description should explain the shape of a returned trade record and the default/window behavior when filters are omitted. It covers parameter names but leaves the return payload and unfiltered-call semantics entirely unspecified.

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%, so the description carries real weight here and does name all five parameters plus the ISO 8601 format for the time bounds. However, it omits symbol format conventions, account_id format, and what limit defaults to or how it interacts with the schema maximum of 200.

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 (read broker trade/deal/fill history) and explicitly scopes it as 'separate from currently open positions,' which cleanly distinguishes it from sibling get_open_positions.

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 'separate from currently open positions' tells the agent when to pick this tool over get_open_positions. It doesn't cover when-not to use it or other alternatives, but the key routing decision is made 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 and destructiveHint=false, so safety is covered. The description adds non-obvious behavioral context: accounts are optional for market tools, and consumers should default to the is_default flag — information an agent could not infer from the structured fields.

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 and returned fields. Minor ambiguity: 'default_account_id' is referenced but not listed among the returned fields, leaving a small dangling reference.

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 zero parameters, no output schema, and rich annotations, the description carries exactly what is needed: what it returns, when it is unnecessary, and how to choose among multiple accounts. No pagination or filtering concerns apply.

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 no parameter semantics to convey — baseline 4 applies. The description instead enumerates the returned fields (id, provider, balance, is_default), which usefully pre-frames the response even without an output 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?

Specific verb+resource ('List all connected trading accounts') followed by the exact fields returned in parentheses. Nothing could be confused with the market/news/alert siblings, and the scope (all accounts) is 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?

It tells the agent when this tool is NOT needed ('Market tools work with zero accounts') and how to pick among results ('use is_default / default_account_id unless the user picks one'). It stops short of naming an explicit alternative sibling or exclusions, but the conditional guidance is clear.

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, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds one useful behavioral fact — that results are enriched with live market data across all symbols — but says nothing about freshness, latency, or what happens when a watchlist_id is invalid.

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, correctly front-loaded with the core action before the value framing. 'At a glance' is mild marketing padding but not enough to hurt usability.

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 single-parameter read tool with full annotation coverage and 100% schema coverage, this is close to complete: the agent knows what it fetches and that market data comes along. Only return shape (no output schema) and error/empty-watchlist behavior are left 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 100% with the single parameter documented as 'ID of watchlist to fetch', so the schema carries the load. The description adds only the implication that all symbols in that watchlist are returned; it provides no format or lookup guidance. 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 and resource ('Get watchlist') and adds scope that matters: it returns current market data for all symbols, not just the watchlist definition. This distinguishes it from update/create/delete_watchlist, though it doesn't distinguish it from data-returning siblings like get_market_snapshot.

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?

'See your tracked assets at a glance' implies the read/inspection use case but never states when to prefer this over get_market_snapshot or other market-data siblings. No prerequisites or exclusions are given, so the agent must infer selection.

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, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds one useful behavioral trait — results are filtered to 'active' alerts scoped to the caller's own account. It says nothing about ordering, volume, or what a triggered alert 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?

A single short sentence with zero filler, and the most important qualifiers ('all active', 'you've set up') land immediately.

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 no-param, read-only list tool with annotations covering the safety profile, this is nearly sufficient. The only real gap is the absence of an output schema combined with no hint about what fields an alert returns or its ordering.

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 the baseline expectation is a 4. No parameter documentation is needed, and the description does not waste words inventing any.

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 ('View') and resource ('market alerts') with clear scope qualifiers: only 'active' alerts and only those 'you've set up'. This implicitly distinguishes it from the create/update/delete_market_alert siblings, though it never names 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?

Usage is only implied — an agent can infer this is the read path for alerts, but there is no explicit statement of when to call it versus update_market_alert or delete_market_alert, and no note on what happens with triggered or expired alerts.

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 this is a non-read-only, non-destructive, closed-world mutation. The description adds that it updates target price and/or direction, implying partial updates, but it does not explain whether omitted fields are preserved, whether the alert must already exist, or what happens on invalid input.

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 wasted words. It communicates the core update operation and optional fields efficiently.

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 mutation tool with low schema coverage and no output schema, the description is adequate but incomplete. It does not cover required alert_id usage, partial-update preservation, target_price constraints, or expected behavior when the alert is missing.

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 only 33% schema description coverage, the description partially compensates by naming target price and above/below direction (alert_type) and using 'and/or' to imply at least one optional field. It does not explain alert_id semantics beyond the schema, the positive target_price constraint, or the enum values in more detail.

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 (Update) and resource (price alerts), and names the updatable fields (target price and above/below direction). It implies an existing alert rather than creation/deletion, but does not explicitly differentiate from siblings like create_market_alert or delete_market_alert.

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 wording 'one of your price alerts' implies this is for modifying an existing alert, which helps distinguish it from create/delete siblings. However, it does not explicitly say when to use this versus alternatives or mention prerequisites such as the alert first existing.

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 and non-destructive, and the description usefully adds that the symbol list is replaced wholesale rather than merged — important context beyond the annotations. It still omits permission requirements, whether partial updates are allowed (name-only or symbols-only), and what the call returns.

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. Brevity is appropriate here, though it comes at the cost of the missing detail noted above.

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 three-parameter mutation tool with no output schema and zero schema description coverage, the description is the minimum viable: it identifies the two editable fields and the replace behavior but leaves optionality, symbol format, and safe partial-update semantics unexplained.

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%, so the description carries the burden. It maps name to renaming and symbols to the symbol list, but does not state that watchlist_id is required while the others are optional, does not specify symbol format, and does not clarify replacement vs. append semantics for symbols.

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 (rename/replace) and resource (watchlist), and the mutating nature distinguishes it from get_watchlist, create_watchlist and delete_watchlist siblings. It does not, however, name those siblings or clarify its relationship to 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?

There is no explicit guidance on when to use this versus create_watchlist or delete_watchlist, and no prerequisites or caveats are stated. Usage is only inferable from the verb.

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