FXMacroData

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

Annotations already declare readOnly/openWorld/non-destructive, so the description's job is to add operational context — and it does: traversal depth bounds, the 50-result cap, cursor-based continuation, and an explicit caveat that returned paths are recorded metadata edges rather than causal or equivalence claims. It also states access policy (public metadata, no API key). Missing only something about failure behavior for invalid or stale node IDs.

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

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

Front-loaded with purpose, then constraints, then the semantic caveat, then access — a logical order with no filler sentences. Slightly dense with semicolon-chained clauses, but every sentence carries 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 an output schema present, return values need not be explained, and annotations cover the safety profile; the description supplies the remaining essentials (entry point, bounds, pagination, interpretation caveat, access). Only minor gaps remain around what a relationship path contains and error conditions.

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 every parameter including depth, limit, cursor, node_id and the relationship enum is already documented. The description's parameter remarks (depth one or two, limit at most fifty, reuse the cursor) duplicate the schema rather than adding new meaning. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Follow evidence-linked catalogue relationships') and ties the input to a named sibling ('node ID returned by catalogue_search'). This distinguishes it clearly from catalogue_search and the many task/tool siblings that do not traverse graph edges.

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

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

Explicitly frames the entry condition (you need a node ID from catalogue_search) and warns about interpretation ('not causality or series equivalence'), which is real usage guidance. It stops short of an explicit when-not-to-use statement or naming an alternative traversal tool, so it is a strong 4 rather than 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?

Beyond the read-only/open-world annotations, the description adds important behavioral context: access is public with no API key, empty results do not imply missing coverage, organisation lookup returns at most ten references, and results contain stable IDs plus exact next-tool arguments. It also warns that no observation values are returned, which prevents misuse for data retrieval.

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 compact and front-loaded, starting with the core purpose and then layering in search modes, empty-result caveats, result contents, and access constraints. Every sentence contributes operational value without repetition.

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 tool has seven parameters, an output schema, and explicit annotations, and the description supplies the remaining operational context an agent needs: public access, no API key, no observation values, stable IDs, exact next-tool arguments, and an important empty-results caveat. Nothing essential for correct selection or invocation appears to be 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?

Schema coverage is 100%, so all seven parameters are already documented in the input schema. The description reinforces text search and filter usage, and mentions the two-character organisation query constraint, but adds little parameter-level detail 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 opens with a specific verb and resource scope: find public macro indicator series, publishers, country links, or organisation references. It clearly separates catalogue metadata search from observation retrieval by stating results include IDs and next-tool arguments but no observation values.

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 explains that users can search by text or filter by currency, country code, or publisher ID, and notes the two-character requirement for organisation lookup. It provides clear usage context but does not explicitly route the agent away from sibling tools such as organisation_search or indicator_query.

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 safety is covered. The description adds subscription/credential requirements, which is real value, but then contradicts itself with 'Requires an API key. Access: keyless: subscription_required', leaving the auth model ambiguous. It also says nothing about rate limits, latency, or what happens when no indicator is 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?

Front-loaded with the purpose before the supported-values list and access note. The ten-slug enumeration is redundant with the schema's indicator description and the garbled access sentence costs clarity, but nothing else 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?

An output schema exists, so return values needn't be explained, and the description covers credential requirements and the valid indicator vocabulary. An agent can invoke it correctly from the schema alone once the purpose and auth context are known.

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 schema already documents latest, symbol, start_date, end_date, and indicator. The description only restates the slug enumeration, which the indicator parameter already contains, and adds no meaning about date-range semantics, the symbol/indicator precedence, or the default behavior when everything is omitted. 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 historical price series for supported commodity indicators', plus the exact set of valid slugs. An agent can tell this is a time-series retrieval tool, though it never distinguishes itself from close siblings such as indicator_query, forex, or rate_curve.

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 operational prerequisites (exact slugs required, subscription/API-key access) but gives no when-to-use guidance and never names an alternative tool. With indicator_query and data_catalogue in the sibling list, the agent is left to infer which product to call.

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 safety is covered. The description adds genuinely useful behavior: Friday 15:30 ET publication, Tuesday cutoff, a 15-minute release delay for keyless USD, and a 90-day keyless history window. It does not describe pagination behavior, result ordering, or what the weekly snapshots look like beyond the field categories, and it omits the instrument-based access path entirely.

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

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

Front-loaded with the purpose, then cadence, then access conditions — a sensible order for an agent scanning for go/no-go information. It is dense but each sentence carries information. Minor waste: the keyless/subscription condition is stated twice (the 90-day sentence and the 'Access:' sentence), which could be merged.

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

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

With an output schema present, the description need not explain return values, and it still characterizes them (long/short open interest by trader category, weekly snapshots). For a zero-required-parameter read tool with 100% schema coverage, this is close to complete. The one notable omission is that the instrument-based query path is invisible from the description, making the tool appear narrower than it is.

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 limit, offset, report, start_date and end_date are already documented, and the description largely restates the currency list rather than adding meaning. One real clarification is that USD means the USD Index contract rather than a currency pair. The bigger gap is that the description frames the tool as FX-only and never mentions the instrument parameter (e.g. ust_10y, wti_crude, 'list'), which the schema presents as an alternative query mode.

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 weekly CFTC Commitment of Traders (COT) positioning data for a currency's FX futures contract on the CME', plus the payload categories (speculator positioning, non-commercial longs vs shorts, sentiment extremes). That is well beyond tautology. It stops short of naming a sibling (forex, commodities, data_catalogue) it is not, so the agent must infer the boundary itself.

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?

Provides a real prerequisite: USD is keyless for the most recent 90 days on a 15-minute delay, while every other currency and full history require an API key with a subscribe link. That tells the agent whether a call will succeed. It gives no when-to-use / when-not guidance against alternatives such as forex or commodities, and never mentions the alternative non-FX path via the instrument parameter that the schema exposes.

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 readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuine behavioral context beyond them: the returned `indicator` slugs are the canonical strings reused by indicator, calendar, and prediction endpoints, `forecasts` deliberately omits values, and the whole set is keyless. It says nothing about result size or pagination for a tool that 'lists every' indicator, which is the only notable gap.

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 core capability is front-loaded in the first sentence, and the secondary views and access note follow in a compact, parallel structure. It is dense but every sentence carries information; the view enumeration is slightly redundant with the schema enum descriptions but justifies its place by routing the agent before it opens the 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?

Given an output schema exists, return-value detail is not required, and the description still covers the things that matter: which view serves which need, which views omit values, that the slugs are reusable elsewhere, and that access is keyless. For a 7-parameter multi-view catalogue with full schema coverage and annotations, nothing an agent needs to call it correctly 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?

Schema coverage is 100%, with every parameter including `view`, `sha256`, `source`, `currency`, and both include flags documented in-schema. The description adds a little meaning, notably that the `indicator` values are shared slugs across endpoints and that `sources` returns a persisted definition by metadata sha256, but most of the view semantics simply restate the enum descriptions. Baseline 3 is appropriate.

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

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

States a specific verb and resource: 'List every macroeconomic indicator FXMacroData publishes for a currency, with units, frequency, and coverage/freshness metadata,' and then enumerates the four alternate views this endpoint also serves. It clearly distinguishes the views within the tool, but never distinguishes this tool from near-name siblings such as catalogue_search or indicator_query, so an agent must infer the split.

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?

Gives real usage context: 'Rows whose coverage is stale, partial, or unavailable are not suitable for real-time carry or inflation analysis,' and clarifies that `forecasts` is coverage-only with 'no forecast values.' It also states access conditions ('all currencies keyless'). What is missing is an explicit when-to-use-this-versus-X statement against the catalogue_search / indicator_query siblings.

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, destructiveHint=false, so the safety profile is covered. The description adds substantive behavior beyond that: the replay horizons (1, 5, 20 observations), the rule that daily windows exclude the publication-day fixing, the caveat that changes from previous actuals are not consensus surprises, and a per-currency access model. This is meaningful context an agent would otherwise get wrong.

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 compact sentences with zero filler, and the core purpose is front-loaded ahead of methodology caveats and access tiering. The prose is dense and jargon-heavy ('publication-day fixing', 'consensus surprises'), but each sentence carries information an agent 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 seven-parameter analytical task tool with no output schema, the definition covers the methodology and access model well but says nothing about the shape of the result (per-event return rows, summary statistics, units) or about the lookback_events/date-window interaction. An agent can call it but cannot predict what it gets back.

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 each of the seven parameters (base, quote, currency, indicator, start_date, end_date, lookback_events) is already documented in the schema. The description adds nothing parameter-specific, and notably does not clarify the distinction between the macro-event 'currency' and the FX 'base'/'quote' pair, which is the main ambiguity an agent faces. Baseline 3 is appropriate.

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

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

The description names a specific verb and resource: replaying verified publication events against measured 1/5/20-observation FX reference returns. That is clearly distinct from siblings like event_predictions, fx_backtest_task, or geopolitical_event_reaction. It stops short of explicitly contrasting itself with any named alternative, which keeps it at 4.

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 methodology (replaying verified publication events over a date range) and by the access note (USD keyless, others require subscription), which is genuinely useful pre-call guidance. However, there is no explicit statement of when to pick this over event_predictions or fx_backtest_task, nor any prerequisite or exclusion 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, destructiveHint=false and openWorldHint, so the safety profile is covered; the description goes beyond them by disclosing the row keying (announcement_id/date/indicator), the inclusion of prediction source metadata, the lowercase-currency constraint, and the subscription access requirement. It does not describe pagination or cursor semantics beyond what the schema states, which keeps it from a 5.

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 core purpose is front-loaded in the first clause, but the opening sentence is an eight-item enumeration that inflates length without adding discrimination after the first two or three items. The access note appended at the end reads as a bolted-on afterthought rather than an integrated constraint.

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 20-parameter read tool with a full output schema and safety annotations, the description covers the essential non-schema facts: what the rows represent, what metadata accompanies them, currency casing, and the subscription gate. The remaining gap is the absence of guidance on the relationship between the prediction groups and the separate official_forecasts section, which is left entirely to the schema.

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

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

Schema description coverage is 100%, so the schema already documents all 20 parameters, making 3 the baseline. The description adds only marginal meaning — that currency must be a lowercase 3-letter catalogue code and that indicator accepts catalogue slugs — and the claim that 'the `indicator` parameter lists the accepted indicator slugs' is a pointer rather than actual added 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 gives a specific verb ('Return') plus a precise resource enumeration (stored forecasts, consensus, central-bank projections, nowcasts, blended predictions) scoped to macro announcements, which clearly separates it from actual-data siblings like latest_announcements or indicator_query. It stops short of naming a sibling or stating an explicit boundary, so it lands just under 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 through the phrase 'for actual-vs-consensus, prior-vs-forecast, or event-surprise context', which hints at the analytic scenarios but never says when to prefer this over alternatives such as indicator_query or official_datasets. There are no explicit exclusions or routing rules; the access note ('keyless: subscription_required with a subscribe link') is a prerequisite, not a when-to-use 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 genuinely new behavior: the data are official central-bank reference rates, history spans multiple years, and access requires a subscription despite the keyless entry point. It does not describe rate limits or result-size 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?

The core purpose and scope are front-loaded, and the indicator/interval and access notes are compact. The listing 'plain-text table, raw rows, exact values, or JSON-like data' is repetitive hedging across four near-synonyms and could be condensed to one phrase.

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 8 parameters at full schema coverage and an output schema present, the description needn't explain return values, and it focuses on provenance, indicator mechanics, and access requirements. The remaining gap is the lack of differentiation from sibling FX tools, which matters given the crowded toolset.

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 every parameter is already documented, setting the baseline at 3. The description reinforces that indicators are comma-separated slugs and that interval toggles daily/intraday, but adds no date-format, bounds, or default semantics beyond what the schema states.

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 ('Get raw historical FX spot-rate rows for a currency pair') and scopes it ('without chart metadata'), which separates it from plot/visualization siblings. However, it never distinguishes itself from adjacent FX tools such as fx_backtest_task, fx_trade_setup_task, or pair_intel_task, leaving that inference to the agent.

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 clarifies selection within the tool (daily vs intraday via interval, indicators as optional comma-separated slugs) and states the access model ('keyless: subscription_required with a subscribe link'). It gives no explicit when-to-use/when-not guidance relative to the many sibling tools, so usage is only 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 cover safety (readOnlyHint, destructiveHint false, openWorld). The description adds real behavioral context beyond that: it downloads full histories, verifies vintages and price coverage, charges opening/rebalancing/closing costs, and explicitly excludes funding income and broker rollover from the carry signal — meaningful modelling caveats an agent could not infer.

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

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

Four tight sentences, front-loaded with the core action and followed by mechanics, caveats, and access. No filler, though the access sentence is slightly awkwardly worded ('Access: keyless: subscription_required').

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 10-parameter compute-heavy task with no output schema, the description covers inputs, cost model, and data-quality behaviour but says nothing about what the result contains (equity curve, trade list, metrics) or expected runtime. An agent knows how to invoke it but not what to expect back.

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

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

Schema description coverage is 100%, so parameters are already documented, including the event-gating nuance and the strategy enum-like examples. The description adds only one extra semantic — that the carry signal omits funding/rollover income — which is a useful model caveat but not parameter-level detail. Baseline 3 applies.

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

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

States a specific verb and resource — 'Run a spot-only FX backtest' — and names the signals used (policy-rate-differential and lagged momentum). It is clearly distinct from siblings like fx_trade_setup_task or quant_scenario_lab_task, though it never names an 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?

Implied usage: this is the tool for historical FX signal evaluation, and the access line ('subscription_required with a subscribe link') flags a prerequisite. But there is no guidance on when to pick this over sibling backtest/scenario tools, nor any exclusions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful access context ('keyless: subscription_required with a subscribe link'), but it does not say what happens if the subscription is absent (error vs. degraded output) or how long a build takes. Adequate, not rich.

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 core purpose front-loaded and no filler. The trailing access clause is slightly cryptic in its 'keyless: subscription_required' formatting but is short enough not to hurt.

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 the deliverable, and it only gestures at it via the ingredient list without saying what the resulting 'setup' contains or how it is ranked. For a composite analytical task with four parameters, the access and failure-mode story is also left incomplete.

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 base, quote, include_cot and horizon_events fully. The description only mirrors those fields at a high level ('optional COT positioning', 'upcoming catalyst risk') without adding format, validation, or edge-case meaning. 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 ('Build a trader-oriented FX pair setup') and enumerates the four inputs it composes (spot context, macro differentials, catalyst risk, COT positioning). It never names a sibling, so an agent cannot tell from the text alone why this differs from pair_intel_task or fx_backtest_task, which keeps it below 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?

There is no explicit when-to-use or when-not-to-use guidance and no alternatives are named, despite a crowded sibling set of FX/macro analysis tools. Usage is only inferable from the ingredient list, leaving the agent to guess whether this is a pre-trade briefing, a backtest input, or a substitute for pair_intel_task.

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 adds valuable context regarding the data structure by specifying the presence of 'incident, publication and capture dates.' This informs the agent about the granularity of the data returned. However, it does not describe operational behaviors like error handling or rate limiting.

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 highly concise and professional, stating the core function in a single sentence. Every word contributes to defining the nature and content of the retrieved event.

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

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

Given that the input parameters are fully documented in the schema and the safety profile is handled by annotations, the description is sufficient for the agent to understand what kind of deep detail it can expect. It is complete without unnecessary verbosity.

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?

Since the schema description coverage is 100%, the tool already comprehensively documents its inputs. The description merely reinforces the concept of a single 'event' rather than adding semantic meaning to the parameters beyond what is already defined.

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 clearly identifies the tool's function: retrieving a single, original-source event. While it lacks a strong action verb like 'fetch' or 'retrieve,' the phrase 'One original-source event' clearly defines the resource being accessed.

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 tool fails to provide any guidance on when to use this specific tool relative to its many siblings. It only describes the content of the result, offering no comparison to search functions like `geopolitical_history` or `geopolitical_sources`.

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 two genuinely useful behavioral facts beyond that: the values are precomputed rather than live-derived, and any event/price co-movement is correlational, which sets correct expectations for how to report 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?

One tight sentence with no filler and the causal caveat placed where it will be read first. It is efficient, though the brevity leans toward under-specification rather than purposeful economy.

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 and the input schema is fully documented, so return shape and parameter formats need no prose. However, the description never clarifies what 'reference-price context' concretely contains (windows, horizons, benchmarks) or how this tool differs from the several geopolitical and forex siblings, leaving a real gap for a read-only analytics tool in a 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 description coverage is 100% and all three parameters carry format guidance, including how event_id is obtained ('Event ID from history results'), so the schema does the heavy lifting. The description adds no parameter-level meaning, which is acceptable at full coverage but earns only the baseline.

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 sentence identifies the resource loosely as 'precomputed event reference-price context', which hints at event-linked price data, but it never states a concrete verb or what the agent actually receives. It also does not differentiate itself from nearby siblings such as geopolitical_event, geopolitical_event_revisions, or events_impact_replay_task, so an agent cannot tell them apart from this text alone.

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 or when-not-to-use guidance; the clause 'association is not causation or a trading signal' is an interpretive caveat, not routing advice. Nothing tells the agent to pick this over geopolitical_history or forex for event-reaction price data.

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 read-only, non-destructive, open-world behavior. The description adds the useful point-in-time notion of a historical cutoff, but it does not explain what "source-record revisions" represent or how the bounded result behaves.

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 concise sentence with no wasted wording. The fragmentary phrasing is efficient but somewhat under-specified.

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 tool that requires an event_id and exposes paginated revisions with an output schema, the description does not explain what revisions are, how they relate to the event_id, or when this should be used instead of adjacent tools. It leaves too much to schema inference.

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

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

Schema description coverage is 100%, so all four parameters already carry detailed meaning, including event_id and as_of. The description only loosely echoes the as_of cutoff and adds no meaningful interpretation 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 identifies the resource as "source-record revisions" and mentions a "historical cutoff," but it lacks a clear action verb such as list or retrieve and does not explicitly tie the revisions to a geopolitical event. It remains only vaguely distinguishable from siblings like geopolitical_history or geopolitical_event.

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 use this tool versus geopolitical_event, geopolitical_history, or geopolitical_sources. The historical cutoff hint is not enough to tell an agent which tool to select.

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 description is not required to explain the safety profile. It does add two things annotations cannot express: a subscription/entitlement prerequisite ('Subscriber access') and the existence of explicit date-basis and revision semantics, which signals that results carry provenance and can be fetched incrementally. It stops short of describing paging behavior or result envelopes, hence not a 5.

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 fragments with no filler — nothing wasted. The domain qualifier is front-loaded, but the 'Subscriber access.' sentence fragment is cryptic in isolation and the overall structure is too compressed for a 12-parameter tool.

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 tool with 12 optional filter parameters, an output schema, and four similarly named geopolitical siblings, the description is far too thin. An output schema removes the need to explain return values, but the agent still lacks any statement of what the tool returns conceptually, how filters interact, or how to pick among the sibling tools.

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

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

Schema description coverage is 100%, so every one of the 12 parameters (as_of, date_basis, after_revision, include_undated, etc.) is already documented in the schema. The description only loosely gestures at date_basis and after_revision via 'explicit date basis and revision history' and adds no syntax, defaults, or interaction rules 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?

The description is a noun phrase — 'Stored official maritime, sanctions and conflict-zone records' — with no verb stating the operation (query, list, retrieve), so an agent cannot tell whether this returns rows, summaries, or aggregates. It also gives no basis for choosing it over siblings such as geopolitical_event, geopolitical_event_revisions, or geopolitical_event_reaction, all of which sound like they cover the same records.

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 or when-not-to-use guidance and no named alternative. The only contextual cue is the fragment 'Subscriber access,' which hints at a precondition but does not tell the agent when this tool is the right choice versus the other geopolitical_* tools.

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 establish that this is a read-only, non-destructive, open-world tool. The description adds some domain context by naming stored counts, collection outcomes, and coverage limits, but it does not explain freshness, aggregation level, or what a "coverage limit" means 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 concise fragment with no wasted wording, but the lack of a verb or clear structure makes it under-specified rather than effectively concise. It is short without being front-loaded around an action.

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?

Because the tool has no parameters, an output schema, and read-only annotations, not everything needs to be in the description. Still, the description leaves the tool's exact purpose and the meaning of its coverage outputs unclear, so it is only minimally adequate for an agent deciding whether to invoke it.

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 there are no parameter semantics for the description to clarify. The baseline for a zero-parameter tool is 4.

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 is a noun phrase rather than a specific action, saying only "Stored source counts, collection outcomes and coverage limits." It does not state whether the tool retrieves, summarizes, or reports coverage, and it does not distinguish itself from geopolitical_event, geopolitical_history, or other geopolitical 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?

There is no explicit guidance about when to use this tool versus the many sibling geopolitical tools. At best, the phrase "coverage limits" weakly implies a coverage-auditing use case, but no conditions or alternatives are named.

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 safety is largely covered. The description adds important context beyond that: access is tiered by currency (keyless for USD, subscription-gated otherwise) and the payload is a composite of series data, derived analytics, and release-timing context.

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 tightly written sentences: the first states what the tool builds and its components, the second front-loads the access constraint. Nothing is redundant and no sentence could be dropped without losing 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 must sketch the return shape, which it does via the three named components. It is close to complete for a 4-parameter read tool; the remaining gap is any indication of range behavior or response size when start_date/end_date span long periods.

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 currency, indicator, start_date, and end_date are already documented in detail in the schema. The description only echoes the single-indicator scoping and the USD/currency access distinction; it adds no format or semantics beyond the structured fields. 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?

"Build an intelligence pack for one indicator" gives a specific verb and scope, and the description enumerates the three components (series data, derived analytics, release timing context). It is clear what the tool produces, though it never names or distinguishes itself from close siblings such as indicator_query or macro_research_pack_task.

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 access note (USD keyless, others require a subscription link) is genuinely useful for deciding whether the call will succeed. However, there is no explicit guidance on when to choose this pack over indicator_query or the other *_task research packs, so the agent must infer selection 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?

Beyond readOnlyHint/openWorldHint/destructiveHint, the description discloses pagination mechanics (newest-first, default 100 with start_date else 20, limit max 100, partial_page.next_call for the next page), vintage/as_of semantics and revision interaction, and the official-only filtering rule. These are non-obvious behaviors an agent could not infer from the annotations or schema.

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

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

The opening sentence is well front-loaded, but the access rule is stated twice ("USD is free; non-USD requires an API key" then "Access: USD keyless; others: subscription_required with a subscribe link"), and the official-only rule is duplicated verbatim from the schema. The semicolon-dense packing makes several distinct behaviors hard to scan.

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 an 18-parameter tool with zero required params and an output schema, the definition covers the risky/ambiguous parts well: pagination contract, date-cutoff semantics, and authorization tiers. It leaves the mode switches (series_mode, value_mode, availability, dataset_version) to the schema, which is acceptable given the output schema exists, but a one-line note on how they interact would make it 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%, so the baseline is 3; the description earns extra credit by explaining cross-parameter behavior rather than restating field docs — how as_of interacts with vintages and revisions, how start_date changes the limit default, and how partial_page.next_call feeds offset/page. It does not mention factor, value_mode, series_mode or dataset_version in prose, so not a 5.

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?

"Returns one currency/indicator's persisted official-producer history using catalogue identifiers" is a specific verb and resource, and explicitly excludes chart metadata and private aggregator rows. It does not name a sibling tool it replaces or defers to (e.g. rate_curve or forex), so a 4 rather than 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?

Access conditions are stated clearly (USD free/keyless, non-USD needs an API key with a subscribe link), which tells the agent when the call will fail. However, there is no explicit routing guidance such as when to prefer this over forex, rate_curve or rate_differentials, or that catalogue_search should be used first to discover valid slugs; usage context is only 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 declare readOnlyHint, openWorldHint and destructiveHint=false, yet the description adds real behavioral context beyond them: the caveat that an unverified announcement_datetime is neither a verified scheduled time nor an observed publication, and the instruction to report missing evidence as unknown and latency as not measured. This meaningfully shapes how results should be interpreted; only the absence of any note on the 'changes' view behavior keeps it below 5.

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 opening snapshot sentence is well front-loaded, but the middle is dense jargon-heavy prose about verification provenance and evidence reporting that is hard to parse, and the access sentence is tacked on at the end. No sentence is truly wasted, but the structure is uneven rather than crisp.

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 explanation is not required, and the verification caveats cover interpretation well. The major gap is that a 7-parameter tool with a whole second 'changes' mode is described as if it only produced a single-currency snapshot, leaving the feed behavior to the schema 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?

Schema description coverage is 100%, so the schema already explains view, limit, since, payload, currency, currencies and indicators, including the next_cursor round-trip. The description adds only marginal semantics on top (currency-scoped snapshot, access gating), which is the expected baseline when the schema does the heavy lifting.

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 first sentence gives a specific verb and resource: return the newest stored macro value per indicator for one currency as a snapshot. It is, however, written entirely around the 'latest' mode and never names the second capability the schema exposes (the resumable 'changes' cross-currency feed), and it differentiates from no sibling such as release_calendar or macro_news.

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 through the currency scoping and the explicit access precondition (USD keyless, other currencies subscription_required with a subscribe link), which is genuinely useful before calling. There is no explicit when-to-use versus when-not statement and no routing to alternatives among the many sibling tools, 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 this as a read-only, open-world, non-destructive operation, so the bar is lower. The description still adds substantive context beyond them: the access tiers (USD keyless, other currencies subscription_required with a subscribe link pointing at subscribe_for_mcp_access), which directly affects whether a call succeeds, plus the breadth of sources pulled.

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

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

Two sentences, front-loaded with the action and resource, then the access constraint. The nine-item source list is long but earns its place by setting expectations for what the briefing contains; it could be tightened but is not padding.

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

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

For a one-parameter aggregator with no output schema and safety already covered by annotations, the definition covers purpose and access conditions. It omits any signal about output shape or size, generation latency, or freshness/caching behavior, which matter for an agent deciding between this and lighter siblings.

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

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

There is a single required parameter with full schema description coverage, including ISO code format and case-insensitivity. The description adds only "for a currency", so the schema is doing all the work; baseline 3 is appropriate for complete coverage with negligible added meaning.

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

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

States a specific verb and resource ("Build a compact macro briefing for a currency") and enumerates the nine data domains it aggregates, which lets an agent distinguish it from narrow siblings like cot_data or seasonality. It does not, however, differentiate itself from other aggregate task tools such as macro_war_room_task, macro_research_pack_task, or macro_heatmap_task.

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: the phrase "compact macro briefing" suggests a use case (aggregated overview rather than a single indicator lookup), and the access note tells the agent that non-USD requests require a subscription. There is no explicit when-to-use or when-not guidance and no named alternative for narrower questions.

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 value by disclosing what the return payload contains (latest values, recent changes, z-scores), which matters since there is no output schema, but it omits behaviour for missing/sparse indicator data and any dependency on a catalogue lookup for valid slugs.

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 that front-loads the action and resource and then states the output. Nothing is redundant and nothing is padding.

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

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

The return-shape disclosure compensates somewhat for the missing output schema, and annotations carry the safety profile. However, with four optional parameters and zero required ones, the description never says what the defaults or scope are (all currencies? all indicators?) or that valid values come from the catalogue, which is the main operational gap.

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

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

Schema description coverage is 100% and all four parameters are documented with types, formats and examples, so the baseline is 3. The description adds no per-parameter meaning beyond the schema, notably not what happens when currencies or indicators are omitted.

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 ("Build a cross-currency macro heatmap from indicator time series") and names the output shape (matrix of latest values, recent changes, z-scores). That is far more specific than the bare title, but it does not distinguish this tool from adjacent *_task siblings such as macro_briefing_task or indicator_intel_task.

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 or when-not-to-use guidance, and no alternative tool is named. The only implicit usage signal is that the caller wants a heatmap, which the agent must infer from the description's output clause.

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 readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the description need not explain basic safety. It adds useful behavioral context: official-source headlines, conditional keyword-derived affected_indicators and sentiment fields, and concrete access rules including keyless USD access and subscription requirements for other currencies. It does not cover rate limits or pagination behavior, but that is covered by schema and output schema.

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

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

The description is front-loaded with the core purpose and remains compact. Most sentences earn their place by adding source scope, output caveats, or access rules, though the supported-currency sentence largely repeats the 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?

With an output schema present, the description need not explain return values in detail, and it still covers source type, topic coverage, conditional derived fields, currency support, and access constraints. An agent has enough to call the tool correctly, with the main remaining gap being explicit sibling-tool routing guidance.

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 limit, offset, currency, and lookback_days. The description reinforces the lowercase 3-letter currency convention with examples, but it adds little meaning beyond the schema for the other parameters. The baseline of 3 is appropriate when the schema does the heavy lifting.

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: return recent official central-bank news and press-release headlines for a currency. It also scopes the content to policy, inflation, employment, GDP, trade, fiscal, energy, and commodity narratives. It is clear, but it does not explicitly distinguish itself from siblings such as press_releases or latest_announcements.

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 implies use for currency-specific central-bank and macro headline monitoring, and it gives access prerequisites for USD versus other currencies. However, it does not explicitly say when to choose this tool over sibling tools like press_releases, latest_announcements, or macro_briefing_task.

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 safety is covered. The description adds two genuinely new facts beyond the annotations: the tiered access model (keyless USD vs. subscription_required for others) and the qualitative shape of the output ('explicit assumptions and confidence notes'), which tells the agent the result is interpretive rather than a raw number. It still says nothing about latency, data freshness, or failure modes for unsubscribed currencies.

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 dense sentences with the core purpose front-loaded and access constraints trailing as a caveat, which is a sensible ordering. Nothing is wasted, though the access sentence is slightly compressed to the point of being terse.

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 three simple flat parameters, no output schema, and read-only annotations, the definition covers the essentials: what it produces, the contextual inputs, and the access prerequisite. The main residual gap is that the return structure is only hinted at via 'assumptions and confidence notes' rather than described, but that is defensible for a task-style tool with no output schema.

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

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

Schema coverage is 100%, so currency, start_date, and end_date are already fully documented in the schema, making 3 the baseline. The description adds no parameter-level detail beyond that and does not explain how the optional date bounds interact with the regime classification window.

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 ('Classify a currency's macro regime') plus the input dimensions it reasons over (policy rate, inflation, GDP, unemployment), so the tool's function is unambiguous. It does not, however, distinguish itself from adjacent macro siblings such as macro_briefing_task or macro_heatmap_task, leaving the agent to 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 explicit statement of when to pick this classifier over the other macro_*_task tools or when not to use it. The one piece of conditional guidance is access-related: USD is keyless while other currencies require a subscription via a subscribe link, which is useful but is about entitlements rather than use-case 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, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds real context beyond that: it composes multiple data families into one payload and discloses a tiered entitlement model (USD free, other currencies subscription-gated with a subscribe link), which is exactly the kind of access behavior an agent needs before calling. It stops short of describing failure behavior for gated currencies or payload 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 sentences, front-loaded with the payload composition and followed by the access rule, with no filler. The phrase 'persistent-host-friendly research payload' is slightly jargon-heavy and could be plainer, which keeps it from a 5.

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 six parameters, no output schema, and a composite return, the description must carry the burden of explaining what comes back. It lists the four bundled data families, which is adequate to set expectations, but omits the response shape, whether sections are omitted when data is unavailable, and what happens when a non-USD call lacks subscription entitlement.

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 every parameter including the optional base/quote FX pair and the start_date/end_date bounds is already documented in the schema. The description only echoes the FX pair context as optional, adding no syntax, format, or interaction detail beyond the structured fields. Baseline 3 applies when the schema does the heavy lifting.

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 composite resource: catalogue data, indicator history, next release timing, and optional FX pair context in a single payload. That is far more informative than the bare name 'macro_research_pack_task'. However, it never distinguishes itself from plausible siblings such as indicator_intel_task, macro_briefing_task, or pair_intel_task, so an agent cannot tell which one to choose from the purpose text alone.

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 only guidance is an access precondition: USD is keyless, other currencies require a subscription with a subscribe link. That is genuinely useful for deciding whether a call will succeed, but there is no statement of when to use this bundled pack versus the individual indicator, catalogue, or pair tools in the sibling list, and no exclusions.

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

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

Annotations already declare readOnly/destructive/openWorld, so the description's added value is the access model: USD is keyless while other currencies require a subscription with a subscribe link — a real operational constraint the agent needs before calling. It stops short of describing panel layout or size/response shape, but the safety and access picture is clear.

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, and the panel composition is front-loaded before the access caveat. Efficient, though the second sentence is purely an access caveat rather than reinforcement of purpose.

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 composite cockpit tool with six optional parameters, full schema coverage, and no output schema, the description adequately previews the four panels a caller will receive and flags the access gate. Missing only explicit guidance on ordering/limits of the release queue window relative to start_date/end_date.

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 six parameters (base, quote, currency, start/end date, indicator) are already fully documented with defaults, examples, and formats. The description only alludes to them indirectly through "pair context" and "release queue" and adds no new semantics, 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?

Specific verb ("Build") plus a concrete deliverable ("multi-panel macro market cockpit") and an enumeration of what it combines (FX sessions, release queue, pair context, risk alerts). It differentiates well from single-purpose siblings like release_calendar or pair_intel_task, though it never names a sibling to contrast with.

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

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

Usage is implied via the composite nature (use when you want all four views at once rather than individual calls), but there is no explicit when-to-use/when-not guidance and no routing to alternatives such as macro_briefing_task or macro_heatmap_task. The access note does give a practical prerequisite (subscription for non-USD).

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 genuinely useful behavior beyond that: weekend and major banking holiday handling, plus free/no-API-key access. It stops short of describing output shape or edge cases such as holidays with partial session closures.

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

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

Front-loaded with the return payload, then the example use cases, then the optional parameter override, then access terms. Three sentences with no filler; every clause carries decision-relevant 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 an output schema present, the description needn't explain return values, and one optional parameter is fully covered. Holiday/weekend handling and free access are disclosed, leaving only minor gaps like how partial holidays are treated.

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 schema already specifies the ISO-8601 UTC format, examples, nullability, and the 'defaults to now' behavior. The description's 'instead of now' framing restates the schema rather than adding new meaning, so the baseline 3 applies.

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

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

Names the specific resource (FX trading sessions) and the exact payload (which sessions are open plus the next open/close), and enumerates the four sessions. It is clearly distinguishable from siblings like forex or risk_sentiment, which concern prices and sentiment rather than session state.

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 quoted example questions ('is the market open?', 'when does London open?', 'which sessions overlap right now?') give strong when-to-use context, and the `at` sentence explains the historical-snapshot case. It does not name an alternative sibling or state when not to use it, so it falls 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 readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuine value beyond that by disclosing that answers are client-aware (ChatGPT, Claude, Cursor, Codex, plain MCP) and that the content spans rendering behaviour and access tiers. It stops short of saying whether the client is auto-detected or inferred from the topic argument.

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

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

Two sentences, front-loaded with the core 'explains what the server can do' claim, and the enumerated facets are compressed into parallel clauses rather than prose sprawl. The client-name list is slightly heavy but each item carries 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 one optional parameter, no output schema and a read-only annotation set, the description gives enough to call it correctly and to know what kind of answer to expect. The only gap is how the two topic modes differ in depth, which the schema covers minimally but the description does not reinforce.

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 the single 'topic' enum already documents both 'overview' and 'auth' with their meanings. The description never mentions the topic argument at all, so it adds no meaning 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?

The description opens with a specific verb and resource: 'Explains what the FXMacroData MCP server can do', then enumerates the exact facets covered (which tools render MCP Apps, which return plain rows, public vs subscriber-only, per-client selection differences). No sibling tool in the list serves this self-documentation role, so the purpose is unambiguous against the catalogue.

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 three concrete triggering situations: questions about what is available, why visuals are not showing, and how to get the same result in another interface. That is clear when-to-use guidance, but it names no exclusions or alternative tools (e.g. data_catalogue for a pure listing), so an agent could still hesitate between this and the catalogue tools.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful access context that annotations cannot carry: API-key requirement, USD keyless vs. subscription_required for other currencies, and a subscribe link. It says nothing about result volume, pagination defaults, or what a listing response 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?

Front-loaded with the core purpose, then a dense but necessary enumeration of the four families, then access constraints last. The single vaguer sentence ('Omit the selector to list what a family holds') is the only real ambiguity in an otherwise tight paragraph.

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 11 parameters, an output schema, and full annotations, the description covers the family taxonomy, listing behavior, currency scoping, and auth tiers – enough for an agent to call it correctly. Minor gaps remain around pagination defaults and the family-specific filters object, though the output schema and param descriptions absorb most of that.

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 earns extra credit by explaining what each family enum value actually contains, which the enum labels alone do not convey. It also clarifies currency scoping ('for financial_prices and official_dataset') beyond the schema wording, though it does not touch pagination or date-bound behavior.

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 (read/list) and resource (official datasets), then enumerates all four families and the concrete data each contains (yield curves, TIC positions, balance of payments, trading updates). It contrasts itself with 'headline indicators' (the indicator_query sibling) but never names an actual sibling tool, so differentiation is implied rather than explicit.

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

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

Gives one useful usage rule – 'Omit the selector to list what a family holds' – which tells the agent to probe before reading. However, 'the selector' is ambiguous (it reads as if family could be omitted, contradicting the required family param), and there is no explicit guidance on when to choose this over indicator_query, rate_curve, or release_calendar.

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

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

Annotations already establish this as a safe, open-world read, so the bar is lower, yet the description adds genuinely useful scope limits: no regulatory approval or endorsement is implied, and no claim evidence or contact records are returned. That negative-scope disclosure prevents an agent from assuming the profile contains compliance or contact data, though it says nothing about coverage or lookup-miss behaviour.

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 action, with scope disclaimers and access terms following in decreasing importance. The endorsement disclaimer is mildly legalistic but earns its place as a scope boundary; nothing is redundant with the annotations.

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?

This is a simple single-parameter read tool with a full output schema, so return shape need not be described. The description covers what is returned, what is excluded, and access requirements; only the failure mode for an invalid or missing slug is unaddressed, which is a minor gap given the low 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 single parameter is fully documented in the schema (100% coverage) including its exact format — 'lowercase hyphenated organisation slug from a directory search result'. The description adds 'by slug' but no new meaning beyond the schema, so the baseline of 3 applies.

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

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

The opening clause gives a specific verb and resource — 'Read one sourced public organisation summary by slug' — and enumerates the payload (services, original sources, canonical FXMacroData citation URL). It implicitly separates itself from the directory listing tool via 'from a directory search result' in the schema, but never names organisation_search, so the sibling distinction is inferred rather than stated.

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

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

The description implies the precondition that a slug must already exist (you cannot read a profile without one) and adds access context ('no API key required', 'one public organisation summary'). However, it never explicitly says to call organisation_search first or when to prefer that tool, leaving routing guidance to inference.

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

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

Annotations already establish readOnly, openWorld and non-destructive semantics, yet the description adds real value: the ten-result ceiling, the fact that results carry canonical citation URLs, that firms are not ranked, and that access is public with no API key. That access and result-shape context is exactly what annotations cannot convey. Minor overlap with the schema's limit maximum is the only redundancy.

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 tightly packed sentences: scope first, return shape second, access constraints third. Every clause carries information an agent would otherwise have to infer, and nothing is repeated.

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

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

With an output schema present, return-value detail is not required, and the description still covers the essentials: matching keys, optional category narrowing, result cap, citation URLs, non-ranking behaviour and no-auth access. Nothing an agent needs in order to call this correctly 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?

Schema description coverage is 100%, so all three parameters are already documented, which sets the baseline at 3. The description reinforces meaning by framing 'query' as a name-or-service search and 'category' as an optional filter, and confirms the ten-result cap, but adds no syntax or format guidance beyond what the schema already states.

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 ('Find') plus a well-defined resource ('publication-cleared FX industry organisations'), and states the matching keys (name or service, optional category). It implicitly separates itself from organisation_profile by emphasising that it returns 'directory references with canonical citation URLs' rather than profiles, but it never names that sibling explicitly.

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

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

It gives clear triggering context: look up organisations by name or service, optionally constrained to a business category. It also sets expectations (at most ten results, no ranking, no export), which steers the agent away from expecting bulk or ranked output. It stops short of naming a follow-up tool such as organisation_profile for detailed records.

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 one genuinely useful behavioral fact — that access is subscription-gated — but the phrasing "keyless: subscription_required with a subscribe link" is contradictory/ambiguous and doesn't say what happens when unsubscribed (error vs. truncated pack) or how large/expensive the response is.

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 purpose front-loaded and no padding. The second sentence is muddled — "keyless: subscription_required" reads as an internal tag dump rather than prose — but the description is not bloated.

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 the return contract, and it only broadly names the three components of the pack without saying what the artifact looks like, how it is structured, or how much data a date range yields. For a composite "intelligence pack" tool among many similarly named *_task siblings, that leaves a real gap.

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

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

Schema description coverage is 100% and all four parameters (base, quote, start_date, end_date) are documented with types, formats and examples. The description only implicitly gestures at the date parameters via "release-timing metadata" and adds no syntax or constraint detail beyond the schema, so the baseline 3 applies.

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

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

The description gives a specific verb and output ("Build an intelligence pack for an FX pair") and enumerates the three inputs to that pack: policy-rate spread context, spot-rate context, and release-timing metadata. That is enough to separate it from plain data tools like `rate_differentials` or `forex`, though no sibling is named 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 when-to-use guidance at all: nothing says when an agent should pick this composite pack over calling `rate_differentials` + `forex` + `release_calendar` separately, nor any prerequisite beyond an access note. The only routing information is an access/login statement, not usage 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?

The annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds the useful detail that the check spans two layers (API and MCP server) rather than one, but it says nothing about latency, failure behaviour, or whether a failure surfaces as an error or a payload field.

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 wasted words, with the identifying purpose ('health check') front-loaded before the scope qualifier. Nothing is buried or repeated from the title.

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?

This is a parameterless tool with an output schema, so the description needn't explain return values and is nearly complete as written. The only marginal gap is the absence of any signal about what an agent should do with the result, which for a diagnostic tool would be a small but real addition.

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 are zero parameters, so the baseline of 4 applies. No additional parameter meaning is needed or expected 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?

The description states a specific verb and resource: a health check that confirms reachability of both the FXMacroData API and the MCP server. That scope is unmistakable against every sibling tool, none of which is a connectivity probe, so an agent can select it without ambiguity.

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 strongly implied by the phrase 'health check' – an agent will infer this is a pre-flight or diagnostic call rather than a data query. However, the description never explicitly says when to prefer it (for example, before a batch of calls, or after a failure) or that no other tool should be substituted for it.

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

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

Annotations already declare readOnly/openWorld/non-destructive, so the description's job is to add context, which it does: it discloses the data-scope restriction (no arbitrary URLs or custom code), the tiered access model with a subscribe link, and the special rate-differential rendering behavior. Missing only details like payload size limits or pagination behavior across sources.

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

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

Four sentences, front-loaded with the core purpose before constraints and access. Dense but largely waste-free; the only mild weakness is that the rate-differential detail sits mid-paragraph rather than being grouped with the chart-kind 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?

For a 19-parameter, zero-required, no-output-schema tool whose schema is fully documented, the description covers the essential conceptual model (single vs multi-series, actual-vs-consensus, spread plots), data scoping, and access gating. It leaves pagination/limit behavior and cross-source alignment to the schema, which is acceptable given complete schema coverage.

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 and the schema already explains every parameter in detail. The description adds a small amount of meaning beyond the schema by clarifying the series-vs-source selection model and that rate_differential requires base and quote, but it does not explain interaction between the top-level single-series params and the nested series specs.

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 ('Build a generic MCP Apps chart') and enumerates the chart families it covers: single/multi-series, actual-vs-consensus, and rate-differential spread views. It implicitly distinguishes itself from release_calendar_visual_artifact by calling itself 'generic', but never names that sibling, so the 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?

Gives strong applicability boundaries ('Charts FXMacroData data only; no arbitrary URLs or custom code') and access tiers (USD keyless; others subscription_required), which effectively tells the agent when the tool is usable. However, it offers no explicit when-to-use-vs-alternative routing against siblings such as release_calendar_visual_artifact, indicator_query, or forex data tools.

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 real value beyond them: it discloses that the elasticity is a scenario assumption 'not a forecast guarantee,' and it surfaces an access prerequisite (subscription required with a subscribe link). It does not describe output shape or how the directional impact is expressed.

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 with the core purpose front-loaded and no wasted preamble. The access note is somewhat awkwardly punctuated ('keyless: subscription_required') but still compact and informative.

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 must carry the return-value burden alone; it only says it estimates 'directional spot impact,' leaving the shape of the result unclear. For an eight-parameter modeling tool in a crowded scenario-tool family, it also lacks the sibling differentiation an agent needs to pick correctly.

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

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

Schema description coverage is 100 percent, so the schema already documents all eight parameters, including the policy_shock_bps alias and elasticity_per_100bps defaults. The description reinforces the elasticity parameter as an explicit heuristic assumption but adds no syntax, ranges, or interaction rules beyond the schema. Baseline 3 is appropriate.

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

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

The description names a specific verb and resource: run a policy-rate spread what-if scenario for an FX pair and estimate directional spot impact. It also names the modeling mechanism (heuristic elasticity), which separates it from plain data lookups like forex or rate_differentials. It does not, however, distinguish itself from other scenario siblings such as quant_scenario_lab_task or fx_backtest_task.

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 phrase 'what-if scenario ... using an explicit heuristic elasticity assumption,' which signals this is an assumption-driven scenario tool rather than a forecast or backtest. No explicit when-to-use or when-not guidance is given, and none of the many scenario siblings (quant_scenario_lab_task, fx_backtest_task, event_impact_replay_task) are named as alternatives.

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 genuinely new behavioral information by disclosing that access is subscription-gated with a subscribe link, but it says nothing about cost, rate limits, or what the analysis returns, and the phrase 'keyless: subscription_required' is internally confusing.

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 analytical purpose before the access caveat. The only weakness is the awkward, colon-heavy access clause, which reads like an annotation string pasted into prose rather than a crafted sentence.

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 and three parameters, the description is only partly complete: it tells the agent what dimensions are analyzed but not the shape or content of the result, so an agent cannot anticipate the response format. For a tool whose whole value is an analytical report, that omission matters more than for a simple lookup.

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 each of the three parameters documented including examples and defaults, so the baseline of 3 applies. The description adds no additional meaning about positions_json structure, horizon_events counting, or what stress_shock_pct units actually imply for results.

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 ('Analyze') and a specific resource ('a multi-position FX book') and enumerates the three analytical outputs: concentration, stress exposure, and event-driven catalyst risk. That makes it distinguishable from adjacent analytical siblings such as fx_backtest_task or quant_scenario_lab_task, though it never explicitly names a boundary against 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 statement of when an agent should pick this tool over fx_backtest_task, quant_scenario_lab_task, or pair_intel_task, and no prerequisites or exclusions are given. The only context offered is an access note about subscription requirements, which is not usage 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 this to be a read-only, non-destructive, open-world call, yet the description adds the material detail the annotations omit: per-currency access tiers, with only USD being keyless and all others requiring a subscription. It also discloses that results are the original official rows rather than derived/classified data, which shapes interpretation of the payload. Return format and pagination behavior are not covered, keeping it at 4.

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, with the resource and the key differentiator front-loaded and the access constraint stated immediately after. Every clause carries information; there is no filler or repetition of the 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?

With an output schema present, the description does not need to describe return values, and it covers the one non-obvious runtime hazard (subscription gating per currency). For a three-parameter read tool this is close to complete; only pagination behavior and the currency universe are left unstated, both of which the schema largely handles.

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 every parameter (currency, limit, offset) is already documented in the schema, and the description adds no syntax, defaults, or bounds beyond that. Its only extra signal is scoping the archive 'for a currency', which is a baseline 3 under high coverage.

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 clear verb ('Return') on a specific resource ('public central-bank press-release archive for a currency') and explicitly states what the rows are not ('without derived sentiment or indicator classifications'), which separates it from derived-data siblings like risk_sentiment or indicator_query. It stops short of naming a sibling tool outright, so it falls just below 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 access note ('USD keyless; others: subscription_required with a subscribe link') tells the agent when a call will be gated and implicitly routes to subscribe_for_mcp_access, which is genuinely actionable. However, there is no guidance on when to prefer this over adjacent news/release tools such as latest_announcements, macro_news, or release_calendar, so tool selection is left to inference.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by naming the computational character of the operation (deterministic projection, stress percentiles) and, importantly, the subscription requirement — a constraint the annotations do not express.

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

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

Two sentences, front-loaded with the operation and its outputs, with no padding. The access clause is slightly awkwardly stacked ('keyless: subscription_required') but still compact and informative.

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 9 parameters full described in the schema and no output schema, the missing piece is what a returned scenario contains and how results should be interpreted relative to sibling scenario tools. The description covers the operation and access gating but leaves the result shape and sibling routing 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 description coverage is 100%, so every parameter including shock_bps, shock_leg, elasticity_per_100bps, and annualized_volatility_pct is already documented in the schema. The description only alludes to 'stress percentiles and horizon assumptions' without adding units, defaults, or interaction semantics, so the baseline 3 applies.

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

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

The description gives a specific verb and resource ('Run an expanded quant-style policy scenario for an FX pair') plus the outputs it produces (deterministic projection, stress percentiles, horizon assumptions). That is concrete and actionable, but it never distinguishes this from the closely related siblings policy_scenario_modeler_task, fx_backtest_task, or fx_trade_setup_task, so an agent cannot tell which scenario tool to pick from the text alone.

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 only guidance is the access prerequisite ('keyless: subscription_required with a subscribe link'), which is genuinely useful gating information. There is no statement of when to prefer this over policy_scenario_modeler_task or when a scenario run is inappropriate, so usage is only implied by the name and description.

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 genuinely useful operational context — subscription requirement and a subscribe link — but the claim that it 'preserves the endpoint's requested view and method metadata' is vague and doesn't tell the agent what that means 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?

The purpose is front-loaded in a single clear sentence, but the middle sentence about preserving view and method metadata is low-information filler that adds length without meaning. It could be tightened without losing anything an agent 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?

With an output schema present, return values needn't be explained, and annotations cover safety. The description supplies the two things structured fields don't: the data scope (government nominal, one currency) and the access precondition (subscription). Adequate for a 6-parameter read tool.

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

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

Schema description coverage is 100%, so all six parameters are already documented at the schema level. The description only echoes the view/method framing without adding format, defaults, or constraints beyond the schema, which is the baseline case.

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 — returning government-nominal curve nodes, slopes, or forward segments for a single currency — which distinguishes it from catalogue-style siblings. It stops short of naming the closest alternative (rate_differentials), so differentiation is implied rather than explicit.

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

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

The description signals this is a subscriber-only data tool and points to a subscribe path, which is implied usage context. It never says when to pick this over rate_differentials or how the view/method choices should drive 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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds real value by stating values may be 'stored or derived' and flagging subscription-gated access, but it does not explain what 'derived' computation entails or how pagination/metadata affect 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 sentences with the core purpose front-loaded and no filler. The access sentence is tersely structured and slightly ambiguous ('keyless: subscription_required'), but it is short and does not bury the main statement.

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

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

With an output schema, annotations, and full parameter coverage, most burden is carried elsewhere, so the description is adequate. Still, for an 11-parameter tool it omits any mention of pagination behavior, date-range semantics, or how forward vs spot modes change the returned data, leaving meaningful 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 description coverage is 100% across all 11 parameters, so the schema already documents base/quote, dates, measure, rate type, curve family, and tenor bounds. The description echoes the same field names without adding format rules, interaction constraints (e.g., tenors only apply when rate_type is forward, which the schema hints at), or defaults.

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

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

The description names a specific verb and resource: 'Return the stored or derived rate differential for one FX pair.' It also enumerates the defining dimensions (measure, rate type, curve family, tenor). It does not distinguish itself from the sibling rate_curve or forex tools, so it stops short of a 5.

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

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

There is no guidance on when to call this versus rate_curve, forex, or indicator_query, which are the obvious alternatives for rate-related data. The only usage-adjacent statement is the access line, which describes subscription requirements rather than selection criteria or preconditions for use.

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, openWorldHint and destructiveHint=false, so safety is covered; the description adds genuinely new behavioural facts: access tiers ('USD keyless; others: subscription_required with a subscribe link') and that unbounded calls return future releases only. It also previews the return payload shape (ISO-8601 UTC, market-local timestamps, markdown agenda, app metadata), which the annotations cannot convey. It does not, however, disclose snapshot/versions/archive_coverage behaviour, which is the most consequential non-default behaviour.

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

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

Front-loaded with purpose and a concrete use case, then filter semantics, then access rules — a sensible ordering with little filler. The 'Supported currencies: lowercase 3-letter catalogue currency, e.g. usd or eur' sentence largely duplicates the schema's own description of `currency`, and the indicator-slug sentence is redundant and unclear.

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 return payload is described well enough that the absence of an output schema is not a problem, and the default 'upcoming' path is fully covered. But with 14 parameters and four view modes, the description explains only the default upcoming view; snapshot, versions and archive_coverage are left entirely to the schema's terse enum strings, which is a meaningful gap 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?

Schema coverage is 100%, so the baseline is 3, but the description earns above baseline by explaining that `timezone` adds an `announcement_datetime_requested_timezone` field and that start/end bounds can express a month, week, day or explicit range. Minor negative: 'The `indicator` parameter lists the accepted indicator slugs' is misleading, since the parameter itself does not enumerate 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?

Opens with a specific verb and resource ('Get upcoming scheduled macroeconomic release timestamps for a currency') and gives concrete example questions (CPI, GDP, payrolls, policy decisions), which lets an agent separate this from generic news/announcement siblings. It does not explicitly name a sibling alternative (e.g. latest_announcements or release_calendar_visual_artifact), so it stops just short of full differentiation.

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 'when the next X is due' framing gives clear use context and the unbounded-vs-bounded behaviour is stated, which implicitly tells the agent when to apply date filters. There are no explicit when-not-to-use conditions or named alternatives, so it is clear context without exclusions.

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

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

Annotations already cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint), and the description adds real value on top: client-compatibility behavior (metadata for MCP Apps rendering), access tiers (USD keyless vs. subscription_required with a subscribe link), and how filters scope the range. It does not describe payload size or pagination, which is a minor omission for a calendar of this kind.

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

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

Front-loaded with the core behavior and return mode, then filters, then access constraints — a sensible order with little filler. The sentence restating 'lowercase 3-letter catalogue currency' duplicates the currency schema description and could be dropped without losing 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?

For a read-only, five-parameter artifact tool with no output schema, the description covers what is returned, how it renders, how filters compose, and the access/subscription requirement. The only meaningful omission is what happens on clients that don't support MCP Apps, plus any note on returned payload size.

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 goes beyond the schema by explaining the combined effect of the filters — narrowing to a series, month, week, day, or date range — and that timezone yields an additional converted local timestamp. It also discloses that indicator accepts catalogue slugs, which compensates for the absence of a schema enum.

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 — 'Returns the release calendar payload with MCP Apps metadata' — and immediately names the outcome ('compatible clients render the interactive Release Calendar App inline'). It also enumerates the request phrasings it answers ('show, display, visualize, or render a macro release calendar'), which distinguishes it from the plain data sibling release_calendar.

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 well signposted with concrete trigger phrasing such as 'show me the AUD release calendar', so an agent can match user intent confidently. The gap is that it never explicitly says when NOT to use it — e.g. that release_calendar is the right choice for raw/non-rendering data access.

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 does add genuine value by disclosing that scoring is heuristic (not a deterministic calculation) and that a subscription/access tier applies, but it says nothing about what a 'score' actually is, its scale, or what accompanies it.

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

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

Two sentences, front-loaded with the core action and no filler. The access sentence is awkwardly punctuated ('keyless: subscription_required with a subscribe link'), which slightly hurts readability but not content.

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 scoring tool with no output schema, the description should say what comes back — a numeric risk score, a per-event breakdown, a rationale — and it does not. The auth/subscription caveat is helpful, but the return contract is the biggest remaining hole for an agent deciding whether this answers its question.

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 base, quote and horizon_events are fully documented in the schema. The description only reinforces the 'currency pair' framing and mentions nothing about horizon_events or valid-currency constraints, so it adds no meaning beyond structured fields. 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 names a specific verb and resource ('Score upcoming releases for a currency pair') and even states the method ('release-calendar proximity and indicator-level heuristics'), which separates it from plain data tools like release_calendar. It stops short of naming that sibling explicitly, so the distinction is inferable rather than stated.

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

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

There is no when-to-use / when-not-to-use guidance and no pointer to alternatives such as release_calendar (raw events) or event_impact_replay_task (historical impact). The agent must guess whether to call this or fetch the calendar directly.

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 only declare readOnlyHint=false, destructiveHint=false and openWorldHint=false; the description adds real signal beyond that — append-only semantics, no mutation of prior notes, paid/owner-only access, no live orders or model inference, and subscription-gated auth. What's missing is any statement about failure modes (e.g., what happens if version_id does not belong to book_id).

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 most decision-relevant facts — append semantics, non-destructive scope, cost and ownership — are front-loaded in the first two clauses. The trailing 'keyless: subscription_required with a subscribe link' is telegraphic and reads like pasted metadata, but it is short and does not bury the main point.

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 5-parameter mutation tool with no output schema, the description covers safety profile, access requirements, and scope of effect, which is most of what an agent needs. It does not say what the append returns (note ID or event linkage) or whether book_id and version_id must be mutually consistent, leaving a small gap.

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 schema description coverage at 100%, the schema already documents all five parameters including the optional event_id and the enum values for kind. The description only reinforces the version-linkage constraint implied by version_id/event_id, adding little beyond the structured fields.

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 ('Append a version-linked journal note') and immediately scopes it with 'does not modify existing notes', which distinguishes it from the edit-oriented sibling research_paper_revise_journal. It stops short of naming that sibling outright, so the differentiation is inferential rather than explicit.

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

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

The clause 'does not modify existing notes' functions as a when-not condition, implicitly routing edits to the revise tool, and 'Paid, owner-only' adds the precondition for calling it. There is no explicit 'use X instead' sentence, so an agent must infer the alternative from the sibling list.

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?

Beyond the destructive annotation, the description adds critical behavior: the account cannot be resumed and archiving covers the active version. It also discloses access requirements and account restrictions, though it omits edge-case behavior such as idempotency or handling of already-archived accounts.

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 short and front-loads the action and irreversibility. The access sentence is slightly telegraphic with 'keyless: subscription_required', but overall it is efficiently structured.

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, parameterized mutation tool with no output schema, the description covers the core action, irreversibility, eligibility, and access requirements. It leaves some operational details unspecified, but an agent has enough to decide whether to call it.

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 both parameters are already documented in the schema. The description adds no further meaning about book_id or expected_version, which is acceptable but not value-adding.

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 clearly states the action and resource: archive a paper account and its active version. It also differentiates behaviorally from pause/resume by saying the account cannot be resumed, though it does not explicitly name a sibling alternative.

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 provides eligibility conditions such as paid, owner-only, no live orders, no model inference, and subscription access. However, it never explicitly says when to choose this over pause, flatten, or other lifecycle siblings, so usage is only 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 declare a safe, closed-world read, so the description adds real value on top: output is paged, full input evidence is deliberately excluded and lives in a private audit export, and there are no live orders or model inference. The remaining gap is pagination termination behavior and whether entries can be empty, which is not disclosed.

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?

Purpose is front-loaded in the first clause, followed by the evidence-withholding caveat and access requirements, with no filler sentences. The telegraphic fragments ("No live orders or model inference") are terse but each carries distinct 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?

For a two-parameter read with no output schema, the description covers what is returned (paged event summaries), what is not returned (raw input evidence), and the access model. Minor incompleteness remains around paging limits and result ordering, but nothing essential for a correct invocation 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?

Schema coverage is 100% with only two well-documented parameters, so the schema already carries offset semantics and the book_id format. The description only implies pagination via "paged" and adds no format or constraint 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?

"Read paged paper event summaries" names a specific verb and resource, and the follow-on clauses scope it (evidence withheld, paid, owner-only). It is distinguishable from write-side siblings like research_paper_append_journal, though it does not explicitly contrast with research_paper_read or research_paper_journal, which an agent must infer.

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 access preconditions (paid, owner-only, keyless subscription with subscribe link) which imply when the call will succeed, but it never states when to choose this over research_paper_read, research_paper_journal, or research_paper_list. Usage is implied rather than directed.

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

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

Goes well beyond the annotations by naming what is destroyed ('discard pending orders'), confirming scope ('simulated account state', 'no live orders or model inference'), and stating cost and access requirements. It stops short of saying whether the flatten is reversible or what a successful response contains.

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

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

Compact and front-loaded: the mutation is stated first, then scope, then commercial/access constraints. The final 'Access: keyless: subscription_required with a subscribe link' clause is slightly awkward in phrasing but still informative.

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 two-parameter mutation with full schema coverage and no output schema, the definition covers safety, cost, ownership and access gating. The main residual gap is return/confirmation behavior after a successful flatten.

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 never mentions book_id or expected_version; it adds no semantics beyond the schema. With schema description coverage at 100% the schema already explains both parameters, including the stale-update rejection, 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 and resource ('flatten' a 'paper account') plus a concrete side action ('discard pending orders'), and scopes it to simulated state. It does not name any sibling (e.g. research_paper_archive or research_paper_pause) as the alternative, so an agent must infer the boundary from the 'paper' framing alone.

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?

Prerequisites are given clearly (paid, owner-only, subscription_required with a subscribe link) and the action is implied by 'request paper position flattening'. However, there is no statement of when to choose flatten over the many sibling research_paper_* operations, nor any explicit exclusion beyond 'no live orders'.

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=false/non-destructive, and the description goes beyond them: fixed page size of five, truncation of long text, owner-only authorization, paid subscription requirement, and a clarification that no live orders or model inference occur. That is useful behavioral context an agent would not get from structured fields. It stops short of saying how truncation is signalled 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?

Front-loaded with the core action and page-size behavior, then progressively narrower constraints (paid, owner-only, no side effects, access). Four dense fragments with no filler, though the 'Access: keyless: subscription_required' phrasing is telegraphic and slightly awkward.

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 read with no output schema and full annotation coverage, the description covers pagination, truncation, and access requirements adequately. It leaves unclear what a journal note contains and how shortened text is marked, which matters for interpreting results, but the core call decision is supported.

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 adds genuinely new semantics by stating the page size is five notes per offset — something the schema does not say. It does not elaborate on book_id beyond what the schema already documents.

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 journal notes') and adds the key scope detail that results are paged five at a time with long text shortened. It is clearly distinguishable from research_paper_read (the paper itself) and research_paper_revise_journal/append_journal (writes), though it never names those siblings 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?

It gives access conditions ('Paid, owner-only', 'subscription_required with a subscribe link') which imply when the call will succeed, but there is no explicit guidance on when to use this versus research_paper_read or the revise/append journal tools. Usage is implied 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new context beyond them: paid tier, owner-only scope, and a keyless subscription_required access gate with a subscribe link. It stops short of describing whether results are paginated or empty-list behavior for non-subscribers.

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 with the subject front-loaded and zero filler; scope, billing/ownership, and access gating each get exactly one clause. Nothing is repeated from the annotations or 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?

For a zero-parameter read there is little to document, and the access and ownership constraints are stated. With no output schema, however, the description never indicates what an account record contains or in what form the list returns, leaving the agent to discover return shape empirically.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the schema is trivially complete. Baseline 4 applies; no parameter-level ambiguity exists.

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: 'List owned reference paper accounts.' That clearly separates it from mutating siblings such as research_paper_start or research_paper_archive and from research_paper_read. The term 'reference paper accounts' is somewhat jargon-laden, so an agent still has to infer whether an 'account' is a workspace or a paper-trading entity.

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

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

Implies the discovery role ('List owned ... accounts') and warns there are 'No live orders or model inference,' which frames the context. It never explicitly contrasts with research_run_list or research_paper_read, so the agent must infer when this list is the right entry point versus a run listing.

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 only declare readOnly=false, destructive=false, openWorld=false; the description adds substantive context beyond that: pausing blocks new entries specifically, existing state presumably persists, and live orders and model inference are unaffected. It also discloses the paid/owner-only authorization and keyless subscription access requirement, which the annotations do not cover at all.

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

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

Four short clauses, front-loaded with the action and scoped by the constraints that matter most. The telegraphic fragment style is efficient, though 'Access: keyless: subscription_required with a subscribe link' is dense enough to read ambiguously on first pass.

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, non-destructive mutation with no output schema, the description covers what changes, what does not change, who may call it, and the access precondition. The main remaining gap is whether pausing is reversible and what the response returns, though the existence of research_paper_resume partially implies reversibility.

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 both book_id and expected_version are already fully documented, including the stale-update rejection semantics. The description adds no parameter-level meaning beyond the schema, which is acceptable at this coverage level but earns no extra credit.

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 first sentence gives a specific verb and resource ('Pause new paper entries'), and the sibling set contains research_paper_resume, so the intended operation is unambiguous. It stops short of naming its counterpart explicitly, so differentiation is inferred from the verb rather than stated.

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

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

The description establishes the paid/owner-only precondition and the subscription access requirement, which are real usage gates. It never says when to choose pause over research_paper_archive, research_paper_flatten, or research_paper_resume, so the agent must infer the choice from naming 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 readOnly=true, destructive=false, openWorld=false, so the safety profile is covered. The description adds non-obvious context beyond them: monetization/ownership gating, subscription requirement, and the explicit negative scope 'No live orders or model inference', which prevents the agent from mistaking this for a trading or inference path.

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

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

Four short sentences, front-loaded with the core action and scope, then constraints. Efficient overall, though the 'Access: keyless: subscription_required' fragment is dense and grammatically awkward to parse.

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 read with annotations and no output schema, the definition covers access requirements and result scope adequately. It still leaves the agent guessing about error behavior when the subscription is missing (does it return a subscribe link, or fail?) and about version-list shape, which matters given 'and its versions' is part of the contract.

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 the single book_id parameter is fully documented in the schema, including the '32 lowercase hex' format and provenance from an owned account result. The description adds no parameter-level meaning, so the baseline 3 applies.

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

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

Specific verb+resource: 'Read one reference paper account and its versions' tells the agent exactly the unit of retrieval (single account plus its version history), which separates it from research_paper_list and research_run_read. It stops short of explicitly naming the sibling it is not, so it lands at 4 rather than 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?

'Paid, owner-only' plus the access line ('keyless: subscription_required with a subscribe link') gives clear preconditions that determine whether the agent can call it at all, pointing implicitly at subscribe_for_mcp_access. It does not state explicit when-not conditions or name the alternative read tools, so it is not a 5.

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