FXMacroData

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond those annotations: it is bounded, resumable via cursor, and safe for MCP use without holding long-lived streams. It does not go into rate limits or output format, but the annotations and output schema cover most safety and result structure needs.

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 two concise sentences with no filler. The first sentence front-loads the core action, and the second explains the intended usage pattern. Every clause earns its place.

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

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

Given the tool has 5 fully documented optional parameters, an output schema, and safety annotations, the description is complete enough. It explains the tool's role, cursor behavior, and bounded nature, while the schema and output schema cover parameter details and return values. No critical information is missing for an agent to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the schema fully documents each parameter. The description adds minimal semantic value beyond the schema, mainly clarifying that 'since' should be the returned next_cursor from a previous call. This is helpful context but not a significant addition because the schema already describes 'since' as 'Optional previous next_cursor, ISO 8601 timestamp, or Unix epoch seconds.'

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 tool's function: 'Poll recently ingested macro announcement changes with a resumable cursor.' It uses a specific verb ('poll') and resource ('macro announcement changes'), and distinguishes itself from streaming release events by positioning itself as 'the bounded MCP-safe companion to the release-event stream.' This differentiates it clearly from sibling tools like latest_announcements or 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?

The description provides explicit usage guidance: 'use the returned next_cursor as since on a later call instead of holding an unbounded streaming tool invocation open.' This tells the agent when and how to use the tool, and contrasts it with the alternative (unbounded streaming), making the choice clear.

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

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

Annotations already establish a safe read-only operation, and the description adds value by disclosing the API-key requirement—a behavioral prerequisite not visible in annotations. It also reinforces deterministic lookup via exact slugs, but does not detail response shape or error behavior; the output schema mitigates this.

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 action, followed by the API-key note and a compact list of supported indicators. Every sentence earns its place, though the indicator list is somewhat redundant with 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?

For a four-parameter, read-only tool with a full output schema and annotations, the description covers the essential selection and auth context. The omission of return-value details is acceptable because the output schema exists; it is complete enough to select and invoke 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?

All four parameters have descriptions in the schema, including date formats and the symbol/indicator alias precedence, so the schema covers 100% of parameter semantics. The description's list of supported indicators duplicates the schema's examples but usefully emphasizes using exact advertised slugs, adding no new syntax details.

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 ('Get') and resource ('historical price series for supported commodity indicators'), distinguishing it from siblings like 'latest_commodities' by emphasizing historical data. It also enumerates the exact supported slugs, leaving no ambiguity about scope.

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 states the tool is for historical price series and notes an API key requirement, giving clear context for when to call it. However, it does not explicitly name alternatives or state when not to use it, so it stops short of full exclusionary 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 cover read-only and non-destructive behavior. The description adds value by explaining the chart metadata packaging and rendering behavior. It does not contradict annotations.

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

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

A single, front-loaded sentence effectively conveys the tool's purpose and relationship to 'commodities'. No wasted words.

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

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

The description is concise and sufficient given the schema and annotations. It lacks explicit return format details, but the reference to 'commodities' and the absence of an output schema make it acceptable in the broader tool ecosystem.

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 detailed descriptions for all parameters. The description adds no additional parameter information beyond the schema, which is acceptable since the schema fully documents 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?

The description clearly states the tool produces an interactive commodity chart by packaging the same payload as 'commodities' with chart metadata. It distinguishes itself from the sibling 'commodities' tool and other visual artifacts.

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 references the 'commodities' sibling and indicates this version is for chart rendering in compatible clients, so the usage context is implied. It could be more explicit about when to choose this over 'commodities' or other visual tools, but the reference is a clear starting point.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context beyond that: refresh cadence ('Every Friday at 15:30 ET'), the Tuesday cutoff, weekly snapshot nature, and an API key requirement. These details help agents set expectations and handle failures.

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 (~70 words) yet information-dense. The core action and use-case triggers are front-loaded, with cadence, API key, and supported currencies efficiently appended. No sentence is wasted or redundant.

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

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

Given the output schema exists, the return shape does not need to be described. The description covers data content, update schedule, cutoff times, API key requirement, and supported currencies, which is complete for a simple 3-parameter, read-only lookup tool.

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

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

Schema description coverage is 100%, so the schema already documents every parameter, including formats, defaults, and supported values. The description adds no deeper parameter semantics beyond restating the supported currencies, so the baseline of 3 is appropriate.

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

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

States a specific verb ('Get'), a precise resource (weekly CFTC COT positioning data for a currency's FX futures contract on the CME), and the domain (speculator positioning). This clearly distinguishes it from broader data tools like forecast or commodities, and its focus on FX futures makes it distinct from sibling tools.

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

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

Gives explicit use-case triggers: 'speculator positioning, non-commercial longs vs shorts, hedge-fund FX positioning, or wants to gauge sentiment extremes.' It does not name alternatives or explicitly state when not to use it, but the context is clear enough for an agent to select it correctly among many 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 cover the safety profile (readOnlyHint=true, destructiveHint=false), so the description adds real value by disclosing the default charted field (noncommercial net positioning), the override mechanism via `metric`, and the output nature (MCP Apps chart metadata). These behavioral traits go beyond what the schema or annotations state.

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

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

Two compact, front-loaded sentences with zero filler. The first sentence establishes identity and default behavior; the second covers the primary customization. Every clause earns its place.

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

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

For a chart-oriented tool with 100% schema coverage and a read-only annotation profile, the essential context is present: payload equivalence with cot_data, default field, override parameter, and output type ('MCP Apps chart metadata'). The main gap is that no output schema exists and the description does not detail the chart metadata structure, but 'MCP Apps chart metadata' plus the visual-artifact naming convention carries enough meaning for correct invocation.

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

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

Schema description coverage is 100%, so the baseline is 3 and the schema already documents all four parameters including metric's default and examples. The description adds marginal value by confirming the metric's role and default in plain language and by pointing to cot_data's shared payload semantics, but it does not substantially enrich parameter meaning beyond the schema.

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

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

The description states a specific verb ('charts') and resource ('COT field'), names its data sibling cot_data, and draws the exact contrast: same payload but with MCP Apps chart metadata. An agent can immediately distinguish it from cot_data and from other asset-class visual artifacts like commodities_visual_artifact or forex_visual_artifact.

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

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

The phrase 'Same payload as cot_data, but with MCP Apps chart metadata' implies this is the chart-producing variant of the cot_data tool, giving the agent a selection heuristic. However, it never explicitly states when to choose this over alternatives (e.g., plot_visual_artifact or the raw cot_data feed), leaving usage to inference rather than explicit when/when-not 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?

While annotations declare readOnlyHint=true and destructiveHint=false, the description adds valuable behavioral context beyond those: it warns that stale/partial/unavailable coverage rows are not suitable for real-time analysis, lists supported currencies, and clarifies that output is slug strings for downstream calls. No contradiction with annotations.

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

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

The description is three sentences, front-loaded with purpose, then guidance, then supported currencies. It is slightly dense but every sentence earns its place. It does not repeat schema details, staying efficient.

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

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

Given the presence of a detailed input schema and output schema, the description covers usage flow, coverage caveats, and supported currency scope. It does not explain return values (covered by output schema) but provides sufficient context for agent decision-making. The only minor gap is not mentioning pagination or large result size, but this is not critical for a catalogue listing 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?

The input schema already provides 100% coverage with detailed descriptions, examples, and defaults for all four parameters. The description adds only marginal parameter-related semantic value, mainly the emphasis on checking the 'coverage' field, but this is more usage guidance than parameter semantics. 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 opens with a specific verb and resource: 'List every macroeconomic indicator FXMacroData publishes for a currency', and immediately names the metadata fields (units, frequency, coverage/freshness). It further distinguishes itself from siblings by explicitly naming downstream tools (indicator_query, release_calendar, indicator_visual_artifact) which helps disambiguate it from those alternatives.

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 explicit instruction on when to invoke: 'ALWAYS call this first when the user asks about a country's macro data'. It also provides conditional guidance for using coverage data before calling indicator_query, and states which tools to pass the returned slugs to. This is a textbook example of when-to-use vs 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 and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: the output is a 'replay timeline' with 'heuristic impact markers,' suggesting a derived/interpretive result rather than raw data, and it supports asynchronous task execution. It does not contradict the annotations.

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

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

The description is two sentences, with the primary purpose front-loaded and no wasted wording. The second sentence adds relevant async execution context without diluting the main message.

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

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

Given the rich input schema, clear annotations, and no output schema, the description provides enough conceptual output framing ('replay timeline mapping...') for an agent to understand what the tool returns. It does not describe output format details, but for an async task tool with fully documented parameters, this is a minor 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%, so the input schema fully documents all seven parameters. The description does not add parameter-specific detail, but it does conceptually tie 'macro announcements' to the indicator parameter and 'FX context' to base/quote/currency. This meets the baseline for a fully documented schema.

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

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

The description names a specific verb and resource: 'Create a point-in-time replay timeline mapping macro announcements to FX context and heuristic impact markers.' This is specific enough to distinguish it from most sibling tasks like macro_briefing_task or indicator_query, though it does not explicitly name a sibling alternative. The 'point-in-time replay' phrasing clearly signals a distinct analytical use case.

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 tool should be used when a point-in-time replay of macro announcements with FX context is needed, and it explicitly notes async execution via MCP Tasks. However, it gives no guidance on when not to use it or which sibling tools (e.g., known_at_time_task, macro_war_room_task) might be better suited for related but different scenarios.

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

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

With readOnlyHint=true and destructiveHint=false in annotations, the safety profile is already covered. The description adds useful behavioral context beyond annotations by stating that 'Rows are keyed by announcement_id/date/indicator and include prediction source metadata.' It also signals that these are stored/historical predictions rather than live real-time values, which is valuable for agent expectations.

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 first two sentences are front-loaded and effective, and the row-keying sentence is useful. However, the description is dominated by two enormous inline lists of supported currencies and indicators that duplicate the schema's own descriptions. This makes the description unnecessarily long and violates the principle that the description should add value beyond structured fields.

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

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

The description covers the core purpose, usage context, row structure, and key metadata, while pagination and date-range behaviors are fully documented in the schema with 100% coverage. An output schema exists, so return-value details need not be repeated. A 4 reflects that the description is sufficient for a tool of this complexity, though it could have briefly referenced the date-range and pagination parameters to tie the prose 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 every parameter including currency, indicator, date filters, pagination, prediction_type, and prediction_source. The description's supported-currency and supported-indicator lists simply repeat schema enum-like information. It adds no substantial new parameter semantics beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Return stored forecasts, consensus-style predictions, central-bank projections, survey forecasts, IMF forecasts, nowcasts, or FXMacroData blended predictions for macro announcements.' This clearly identifies the tool's output and distinguishes it from sibling tools like release_calendar and indicator_query, which focus on scheduled announcements and actual data rather than stored predictions.

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 explicitly says when to use the tool: 'Use this with release_calendar and indicator_query when a report needs actual-vs-consensus, prior-vs-forecast, or event-surprise context.' This provides clear context, but it does not explicitly list exclusions or alternative tools to use in other cases, so it falls just short of a perfect score.

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; the description adds source (official central-bank reference rates), granularity (daily), history depth (multi-year), and indicator attachment. No contradiction with annotations; could mention rate limits but not required.

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 usage guidance, but the full supported currency and indicator lists are duplicated verbatim from the schema, adding bulk without new information. Still organized and free of fluff; not overly 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?

With an output schema present and annotations covering the safety profile, the description adequately covers data source, granularity, history, alternatives, and options. No major 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 covers all five parameters with descriptions at 100%, so baseline is 3. The description largely repeats the currency and indicator lists from the schema, though it adds the 'attach to each row' nuance and lowercase-code hint; no significant additional parameter 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?

Description uses a specific verb-resource pair ('Get raw historical FX spot-rate rows') and clarifies the output style ('plain-text table, raw rows, exact values'). It differentiates from the sibling forex_visual_artifact by explicitly calling out chart-free use cases.

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?

States 'Prefer this tool when...' with explicit raw-data triggers and tells the agent to use forex_visual_artifact for general chart-friendly asks. Also gives supported indicator behavior, making selection criteria unambiguous.

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 and destructiveHint=false, so the description doesn't need to repeat safety. It adds context that the output includes 'MCP Apps chart metadata' and renders an 'interactive spot-rate chart inline,' describing the delivery mechanism beyond the raw data. However, it doesn't detail what happens for incompatible clients or the exact structure of the chart metadata, but this is a minor gap given the annotations.

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

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

The description is two sentences, with the first sentence stating purpose and the second giving usage guidance. It uses concrete examples without padding, making it efficient and front-loaded.

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 description covers the tool's unique value (chart metadata), its default usage, and when to fall back to forex. The lack of an output schema is mitigated by the reference to 'same payload as forex,' though agents without prior knowledge of forex may need more detail on the return structure. Overall, it's sufficiently complete for a well-documented sibling 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?

The input schema provides complete descriptions for all five parameters, including examples and supported values, so the description doesn't need to add parameter semantics. The phrase 'Same payload as forex' reinforces that parameters match the forex tool, but the schema already gives full coverage. 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 opens with 'Same payload as forex, but packaged with MCP Apps chart metadata so compatible clients render an interactive spot-rate chart inline,' clearly stating the tool fetches FX time-series data and renders it as a visual artifact. It distinguishes itself from the sibling forex tool and other visual artifacts by explicitly contrasting with forex.

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 provides explicit guidance: 'Prefer this by default for FX pair time-series requests' and gives example prompts. It also specifies when not to use it: 'Only prefer plain forex when the user explicitly asks for a table, raw values, JSON, CSV-style output, or exact row-by-row data,' making the alternative clear.

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

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

Annotations already declare safe behavior (readOnlyHint=true, destructiveHint=false), so the description does not need to restate those. It adds useful behavioral context: 'transparent rule-based' implies the logic is open and not a black box, and 'Supports MCP Tasks for async execution' discloses an async execution capability not present in annotations. No contradiction exists.

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

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

The description is two sentences and front-loaded with the core purpose, followed by the async execution note. Every sentence earns its place; there is no fluff or repetition of schema 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?

Although the schema is rich and annotations are present, no output schema exists and the description does not mention what the backtest returns (e.g., metrics, report, task result). For a 10-parameter tool, the description leaves the user without an understanding of the tool's output, which is a notable gap. The async execution hint partially addresses usage context but not return values.

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 input schema already documents all 10 parameters with examples and defaults. The description adds no additional parameter-related meaning beyond what the schema provides; its mention of carry/momentum signals is already echoed in the 'strategy' parameter description.

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 tool's function: 'Run a transparent rule-based FX backtest on historical spot data using carry and/or momentum signals.' It uses a specific verb (run), identifies the resource (FX backtest on historical spot data), and differentiates from siblings like fx_trade_setup_task or event_impact_replay_task by specifying the signal types and rule-based nature.

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 when to use the tool (whenever a rule-based FX backtest with carry/momentum signals is needed) but does not explicitly mention alternatives or exclusion criteria. The note about MCP Tasks for async execution provides some context, but it does not compare with related tools or explain when not to use it.

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

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

The description matches the annotations (readOnlyHint=true, destructiveHint=false) by stating it 'returns' observations, implying a safe read operation. It adds context about subscriber-only access, single-pair scope, and the need to verify availability, which goes beyond what annotations declare.

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, no fluff. The first sentence states the purpose and scope; the second provides a critical prerequisite. Everything earns its place, and it is front-loaded for quick comprehension.

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

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

With an output schema present, return-value details are covered. The description adequately covers purpose, scope, and usage prerequisite for a 4-parameter read-only query. It does not explicitly mention time-range behavior, but the schema parameters make it clear enough.

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 descriptions cover 100% of parameters, so the baseline is 3. The description adds meaningful context by emphasizing 'one pair' and instructing verification via fx_reference_universe, which enhances understanding of how to set base/quote parameters.

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 explicitly states 'Return subscriber intraday official FX reference-rate observations for one pair,' providing a specific verb, resource, and scope. It distinguishes from the sibling fx_reference_universe by focusing on observations and mentioning the prerequisite of checking availability.

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

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

It gives a clear precondition: 'Call fx_reference_universe first to verify pair and source availability,' which tells the agent the necessary preceding step. It does not explicitly state when not to use or name alternatives, but the context is clear for this specific data retrieval action.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds minor context by mentioning 'source policy' as part of the returned data, but it does not disclose other behavioral traits such as pagination, rate limits, or potential incompleteness of the list. The score reflects that the description adds some value but does not significantly go beyond annotations.

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

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

The description is a single, well-structured sentence that front-loads the verb 'List' and immediately conveys the tool's purpose, scope, and usage timing. Every word earns its place, with no redundancy or filler.

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

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

This is a simple list tool with no parameters, an output schema present, and annotations covering safety. The description provides the essential workflow context ('before requesting a pair-specific intraday reference-rate series') and clearly states what is listed. Given the tool's simplicity and the structured metadata, the description is fully complete for an agent to use it 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?

The tool has zero parameters, and the schema is empty. According to guidelines, a 0-parameter tool receives a baseline of 4. The description does not need to explain any parameter semantics, and the 'source policy' mention hints at what the output contains, which is adequate.

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 the specific verb 'List' and clearly identifies the resource: 'public official FX reference-rate sources and their source policy.' It also distinguishes itself from sibling tools like fx_intraday_reference_rates by explicitly noting 'before requesting a pair-specific intraday reference-rate series,' making the tool's purpose unambiguous and differentiated.

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 provides clear usage context by stating 'before requesting a pair-specific intraday reference-rate series,' which tells the agent when to invoke this tool. However, it does not explicitly name alternative tools or provide exclusion criteria, so it falls short of a full 5. The guidance is strong but could be more direct about 'use this instead of X'.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the behavioral context of 'public' (implying no special access needed) and notes optional filtering by currency or source id, which goes beyond the annotations.

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

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

The description is two sentences, front-loaded with the primary action and immediately followed by usage guidance. Every word earns its place; no redundancy.

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

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

For a simple read-only list tool with an output schema and no nested objects, the description covers the purpose, optional filters, and usage context (before intraday series). No critical information 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?

Both parameters are fully described in the input schema (source and currency with descriptions), giving 100% schema coverage. The description only rephrases the filtering capability without adding new semantics, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'List the public FX reference-rate pair universe, optionally filtered by currency or source id.' This uses a specific verb ('List') and resource, and distinguishes it from sibling tools by indicating it is a prerequisite for requesting intraday reference-rate series.

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 provides explicit usage timing: 'Call this before requesting an intraday reference-rate series.' This gives clear context for when to use the tool, though it does not explicitly mention alternatives or when not to use it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description aligns with a safe read operation. It adds context about the data sources and async execution, but neither the return format nor potential limitations are disclosed, providing moderate added value beyond annotations.

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

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

The description is exactly two sentences, front-loading the core purpose and adding one clarifying sentence about async execution. No filler or redundant wording.

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 should clarify what the 'setup' output contains and how async execution behaves. It leaves these details vague, but annotations and parameter descriptions handle safety and input definitions, creating a moderate 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 descriptions cover all four parameters (100% coverage) with detailed examples. The description adds minimal extra meaning by linking 'optional COT positioning' to include_cot and 'upcoming catalyst risk' to horizon_events, but does not surpass the schema's own clarity.

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 tool 'Build[s] a trader-oriented FX pair setup' and lists specific inputs (spot context, macro differentials, catalyst risk, COT). This specific verb+resource pairing distinguishes it from sibling tools like fx_backtest_task or pair_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?

Usage context is implied through the description of inputs and async support, but there is no explicit guidance on when to choose this tool over alternatives or any exclusions. The mention of MCP Tasks hints at async scenarios but does not compare with other task 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 the read-only and open-world profile. The description adds useful context about combining chart-ready series, derived analytics, release timing, and async MCP Task support, but it does not detail output handling or limitations. No contradiction with annotations.

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

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

Two dense sentences with the core purpose front-loaded and no filler. The async execution note is relevant and placed at the end without bloating the definition.

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 should more concretely explain what an 'intelligence pack' returns and how the result is delivered, especially in async mode. It names the components but leaves the response shape and delivery mechanism ambiguous.

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

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

Schema description coverage is 100%, with detailed supported-value lists and date formats. The description adds no parameter-level meaning beyond identifying the tool as single-indicator, so the baseline score of 3 is appropriate.

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

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

The description names a concrete deliverable ('intelligence pack'), scopes it to a single indicator, and lists the data components it combines. This distinguishes it from raw query or visualization siblings, though it does not explicitly name alternatives.

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 a clear scope and an explicit async condition ('when clients send task-augmented requests'), but it does not tell the agent when to choose this over related task tools like macro_research_pack_task or pair_intel_task. Usage is more implied than explicitly differentiated.

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 mark readOnlyHint true and destructiveHint false, and the description adds alignment plus extra behavioral traits: row shape including announcement_datetime for point-in-time integrity, official-source default with prohibited private aggregator rows always removed, and pagination response fields. No contradiction with annotations.

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

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

The opening sentences are front-loaded and information-dense, but the description becomes bloated by repeating the full supported-currencies and supported-indicators lists that already exist verbatim in the parameter schema. These duplicated lists add length without new information for an agent.

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 9-parameter tool with rich schema and output schema, the description leaves nothing essential uncovered: selection prerequisites, row semantics, pagination behavior, source restrictions, API-key requirements, supported currencies/indicators, and sibling routing are all present.

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?

All 9 parameters already have schema descriptions (100% coverage), so the baseline is 3. The description adds meaningful usage semantics beyond the schema by explaining how limit/offset/page map to pagination and directing agents to data_catalogue beforehand to resolve the correct slug/currency/indicator combination.

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 names the action ('Get'), the resource ('paginated historical time series of a single macroeconomic indicator for a currency'), and the data source. It differentiates itself by saying it returns raw rows for data workflows and pointing to indicator_visual_artifact for chart rendering.

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 explicit when-to-use context by listing series families (CPI, GDP, unemployment, rates, etc.), instructs to call data_catalogue(currency) first to obtain the exact slug, and names indicator_visual_artifact as the alternative for chart rendering. Access conditions (USD free, non-USD requires API key) further clarify when the call is valid.

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 readOnlyHint/destructiveHint annotations, the description discloses that the tool returns MCP Apps metadata, that compatible clients will render an interactive chart rather than a JSON dump, and that callers should use pagination controls and inspect pagination.next_offset rather than retrying shorter windows. It does not describe the exact metadata structure or output format, but it adds meaningful behavioral context that is not present in the annotations.

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

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

The key usage guidance is front-loaded and well organized, but the description is substantially bloated by redundantly listing the full supported currencies and indicators that already appear verbatim in the schema. While every sentence in the guidance portion earns its place, the repeated enumerations make the description longer than necessary without adding new information.

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

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

Given the tool has 7 parameters, no output schema, and several sibling visual-artifact tools, the description is largely complete: it explains the tool's purpose, default preference, fallback behavior, pagination strategy, and supported values. The main gap is that it does not specify what the MCP Apps metadata actually contains or how to interpret the returned artifact, but this is partly mitigated by the clear statement that compatible clients render an interactive line chart.

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 input schema already provides detailed descriptions and examples for all 7 parameters, including supported values for currency and indicator, making schema coverage 100%. The description mostly repeats those supported-value lists and adds no new parameter-level semantics beyond mentioning that limit, offset, and page behave as existing REST pagination controls. This aligns with the baseline 3 for high schema 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 states a clear, specific purpose: it is the same payload as indicator_query but additionally returns MCP Apps metadata so compatible clients render an interactive line chart. It also explicitly distinguishes itself from the sibling indicator_query by describing when each should be used, making the tool easy to differentiate even without inspecting the sibling's schema.

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

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

The description gives explicit when-to-use guidance: prefer this tool by default for indicator time-series requests, especially when the user wants to show, tell, explain, compare, inspect a trend, or review a recent window. It also states the exact fallback condition — use indicator_query when the user explicitly wants a raw table, plain text, JSON, exact rows, or minimal structured data — and gives pagination advice for broad histories.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context: the point-in-time integrity boundary using announcement_datetime, and support for MCP Tasks async execution. This goes beyond annotations without contradicting them.

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

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

Two concise sentences with the core action front-loaded. The async capability is a single secondary sentence. No filler or repetition of schema 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?

Given 5 parameters with full schema descriptions, readOnly/openWorld annotations, and no output schema, the description covers the essential retrieval logic and async behavior. It does not describe return shape, but for a simple macro-series slice that is a minor 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%, so the schema documents all five parameters in detail. The description adds no extra parameter-level semantics beyond the as_of boundary already documented in 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?

States a specific verb and resource: 'Return the slice of a macro series that would have been known at a specific timestamp.' The point-in-time boundary via announcement_datetime is explicit. It does not explicitly name a sibling alternative, so it stops short of fully distinguishing itself from tools like indicator_query, but the mechanism is clear.

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: it is for retrieving a historical as-of slice of a macro series. It does not mention when not to use it or explicitly compare with sibling tools like indicator_query or event_impact_replay_task. The async note adds execution context but no selection guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds context about returning the latest stored value for every indicator, implying a snapshot semantics, but doesn't disclose additional behavioral traits such as data freshness, response size, or any rate limits. With annotations in place, this is adequate but 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?

The description is two concise sentences that front-load the action and provide contextual usage guidance. Every sentence earns its place, with no redundant wording or repetition of schema fields.

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

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

Given the tool's simplicity (one parameter) and the presence of an output schema, the description adequately covers the core purpose and usage context. It could mention edge cases (e.g., missing data for a currency) but does not need to explain return values since an output schema exists.

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%: the schema already describes the currency parameter as '3-letter ISO currency code (case-insensitive)' with examples. The description adds only the phrase 'in one currency,' which does not meaningfully extend parameter semantics 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 clearly states the tool returns the latest stored macroeconomic value for every available indicator in one currency. The verb 'return' and specific resource ('latest stored macroeconomic value') make the purpose unambiguous, and it distinguishes itself from siblings like data_catalogue by focusing on a compact current snapshot.

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

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

The description provides a clear use case ('Use this for a compact current macro snapshot') and a prerequisite ('after data_catalogue has confirmed the currency coverage'). It mentions an alternative tool (data_catalogue) by name, though it does not explicitly state when not to use this tool.

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. The description adds useful behavioral context beyond these: it is a 'subscriber tool' (implying access restrictions) and returns all indicators in one response (batch behavior). It does not contradict annotations.

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

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

The description is two sentences with no wasted words. The first sentence front-loads the primary action and scope, and the second adds sibling context. It is appropriately sized for the tool's simplicity.

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 tool with an existing output schema, the description covers the essential points: what it returns (latest values for every commodity indicator), its batch nature, and its relationship to a sibling tool. No additional details are necessary.

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 has zero parameters, and the schema coverage is 100% (empty properties). The description reasonably needs no parameter details. Per the rubric, a zero-parameter tool gets a baseline of 4, and nothing in the description undermines that.

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

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

The description clearly states the action: 'Return the latest stored value for every available commodity indicator in one response.' It also distinguishes itself from the sibling tool by calling itself the 'batch counterpart to commodities,' making its scope and relationship explicit.

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

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

It provides context for when to use this tool: when a batch of all commodity indicators is needed, and references 'commodities' as the counterpart for individual queries. This implies the alternative, though it stops short of explicit exclusions or a direct 'use commodities for single values' instruction.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the aggregation of multiple contexts and the async execution capability, which is useful beyond annotations, but it does not disclose return format, latency, or other behavioral nuances.

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 fluff. The first sentence states the core function, and the second adds important execution context. Every word contributes value.

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

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

Given the moderate complexity (many data sources but one parameter), the description is largely complete: it lists all component types and the async capability. It does not describe the structure of the briefing output, but with a simple schema and good annotations, this is acceptable. A short note on output format would make it a 5.

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 schema fully covers the single 'currency' parameter with description and examples (100% coverage), so the baseline is 3. The description merely restates 'for a currency' without adding extra meaning beyond the schema.

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

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

The description uses a specific verb ('Build') and resource ('macro briefing for a currency'), and lists the component data sources. It clearly communicates what the tool does, though it does not explicitly distinguish it from sibling macro tasks like macro_research_pack_task or macro_war_room_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 description implies a use case: generating a compact brief that integrates many data types. It mentions async execution support but provides no guidance on when to prefer this tool over alternatives, and there is no 'use this instead of...' language.

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 that the factor is 'precomputed' and 'documented,' hinting at its curated nature, but does not go deeper into response structure or pagination behavior—though the output schema likely handles that. It neither contradicts annotations nor adds substantial behavioral context beyond what structured fields provide.

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

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

Two sentences, front-loaded with the action and resource, and zero filler. Every clause earns its place: the first defines what's returned, the second provides a usage 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?

Given output schema and annotations cover return format and safety, the description is adequate for a read-only lookup tool. It clarifies the single-currency scope and the optional includes, and the 'documented factor value' framing distinguishes it from underlying-release tools. Slightly more detail on pagination or the nature of 'component scores' would elevate it, but not necessary.

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

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

Schema description coverage is 100% and each parameter has a clear description (e.g., factor slug, ISO currency, date range, booleans). The description adds no parameter-level details beyond what the schema already states, so it meets the baseline without compensating for any gaps.

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 starts with a specific verb 'Return' and names the resource ('precomputed macro factor for one currency'), which clearly distinguishes it from the broader suite of sibling tools. It also clarifies the optional outputs (component scores and source references), leaving no ambiguity about what the tool delivers.

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 states when to use ('for a documented factor value') and when not to use ('not as a substitute for inspecting its underlying macro releases'). This gives clear direction without needing to name sibling tools, since the exclusion is behavioral rather than tool-specific.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It adds useful behavioral context beyond the annotations: the tool returns a matrix with latest values, recent changes, and z-scores, and it supports MCP Tasks for async execution. This is meaningful additional transparency.

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 only two sentences and front-loads the core purpose in the first sentence. The second sentence adds the async execution capability without redundant or promotional language. Every sentence contributes 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 tool with no required parameters and rich schema descriptions, the description covers the essential output shape (matrix of values, changes, z-scores) and the async task capability. It does not detail default date ranges or how defaults work, but the schema and annotations already provide a strong foundation, and no output schema is declared.

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 parameter (end_date, currencies, indicators, start_date) already documented with formats, examples, and value lists. The description itself does not add parameter-level detail beyond naming the components of the heatmap, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Build') and resource ('cross-currency macro heatmap from indicator time series'), and states exactly what it returns (a matrix with latest values, recent changes, and z-scores). This makes its purpose unambiguous and distinct from sibling tools like indicator_query or macro_factor.

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 tool should be used to generate a cross-currency macro heatmap, but it does not explicitly state when to choose this tool over alternatives, nor does it name any sibling it is not. Given the large sibling list, an agent receives no direct routing guidance beyond the inferred use case.

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 and destructiveHint, and the description adds meaningful behavioral detail: official-source headline rows, keyword-derived affected_indicators, and sentiment fields only 'when a headline is classifiable.' This goes beyond the annotations without contradicting them.

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

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

The description is front-loaded with the core purpose, followed by the use case, output behavior, and supported currencies. Each sentence earns its place and there is no filler or 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?

Given the output schema exists and annotations cover the safety profile, the description supplies the essential selection context: when to use it, what it returns, and which currencies are supported. Nothing material is missing for correct tool selection and invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description lists supported currencies, but that information is already present in the currency parameter schema. It does not add meaningful parameter-level meaning beyond what the schema provides.

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.' This is clear and actionable. However, it does not explicitly contrast with sibling tools like press_releases or latest_announcements, so it lacks full sibling 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 description gives explicit trigger conditions: 'Use this when a report needs headline context for central-bank policy, inflation, employment, GDP, trade, fiscal, energy, or commodity narratives.' It provides clear context but does not include when-not-to-use guidance or name alternative sibling tools, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it specifies that outputs include 'explicit assumptions and confidence notes' and mentions async execution via MCP Tasks. This goes beyond annotations without contradicting them.

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

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

The description is two sentences and every clause earns its place. It front-loads the core purpose and then adds the output notes and async support, with no redundancy or irrelevant details.

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 hints at return content ('explicit assumptions and confidence notes') and covers inputs and execution behavior. It doesn't detail error handling or edge cases, but for a read-only classifier with high schema coverage, this is reasonably complete. A more explicit return format description would push it to 5.

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 all parameters (currency, start_date, end_date) already described. The description does not add parameter-specific details beyond the schema, but the baseline is 3 given high coverage. It mentions the context elements (policy rate, inflation, GDP, unemployment), which relate to classification logic but not to parameter syntax.

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 'Classify a currency's macro regime using policy rate, inflation, GDP, and unemployment context' – a specific verb and resource. It also mentions the outputs (assumptions and confidence notes). While this differentiates the tool as a macro-regime classifier, it doesn't explicitly name sibling alternatives, so it stops short of a 5.

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

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

The description implies usage when a currency's macro regime classification is needed and notes support for MCP Tasks for async execution. However, it provides no explicit comparison to sibling macro tools (e.g., macro_heatmap_task, macro_briefing_task) or 'when not to use' guidance, leaving the context implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false; the description adds that the payload is 'persistent-host-friendly' and that task-augmented requests run asynchronously. This is useful context, though 'persistent-host-friendly' is vague and no rate limits, authorization, or response constraints are mentioned.

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 payload contents front-loaded and the async support stated separately. It is compact and mostly free of redundancy, aside from the somewhat vague 'persistent-host-friendly' phrasing.

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 six-parameter aggregate tool with no output schema, it identifies the main inputs and output components, so an agent can form a valid request. Missing are the output shape, valid start/end date and quote combinations, and guidance on when this aggregate is preferable to sibling task 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 coverage is 100%, with all six parameters described and example values, so the baseline of 3 applies. The description only adds that base/quote provide optional FX pair context and does not add date syntax or indicator-list semantics 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?

States it bundles four named components (catalogue, indicator history, next release timing, optional FX pair context) with the verb 'Bundle', so an agent can tell what output to expect. It does not explicitly differentiate from siblings like macro_briefing_task or known_at_time_task, but the component list makes its role reasonably specific.

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 usage cue is support for MCP Tasks when clients send task-augmented requests, which addresses async execution. It gives no condition for choosing this aggregate over sibling research/task tools, no exclusions, and no 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 and destructiveHint=false, so the safety profile is covered. The description adds a useful behavioral detail about MCP Tasks and async execution, but it does not clarify what 'task-augmented requests' means in practice, whether a direct call is also allowed, or what the returned cockpit looks like.

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

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

The description is two sentences with no filler, and the core purpose is front-loaded before the async note. It is compact but packs the main components into a single sentence, which keeps it scannable.

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 should at least convey what the tool returns, but it only says it 'builds' a cockpit. It also does not explain how the six optional inputs shape the panels, how dates affect the release queue, or how the async task mode is triggered beyond a vague reference. An agent can guess the intent but lacks important invocation and response context.

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 input schema already documents every parameter thoroughly. The description adds no additional meaning about how start_date, end_date, base, quote, currency, or indicator control the multi-panel cockpit, leaving the baseline of 3 appropriate.

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

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

The description uses a specific verb ('Build') and resource ('multi-panel macro market cockpit') and lists the four combined data areas: FX sessions, release queue, pair context, and risk alerts. This distinguishes it from narrower siblings like pair_intel_task or release_calendar_visual_artifact, though it does not explicitly say whether the result is a visual artifact or a data payload.

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

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

No explicit guidance is given on when to choose this tool over alternatives among the many task and visual-artifact siblings. The only usage-related note is that it supports MCP Tasks for async execution when task-augmented requests are sent, which is contextual but not tool-selection 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 and destructiveHint=false, so the description adds value by noting that the tool accounts for weekends and major banking holidays, and can snapshot a specific moment via the `at` parameter. It does not contradict annotations.

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

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

The description is three sentences, front-loaded with the primary function, then usage triggers, and then parameter guidance. Every sentence earns its place with no unnecessary detail.

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

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

For a read-only tool with one optional parameter and an output schema, the description is complete: it covers the core function, typical user queries, timestamp handling, and edge cases (weekends/holidays). No important context 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?

The input schema already provides 100% coverage for the 'at' parameter, including format, default, and purpose. The description reinforces this usage but does not add significant new semantics beyond the schema, so the baseline score of 3 applies.

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

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

The description clearly states the tool's function: it tells which FX trading sessions (Sydney, Tokyo, London, New York) are currently open and when the next session opens/closes. This specific verb+resource combination distinguishes it from sibling market data tools.

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

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

The description provides explicit trigger examples: 'is the market open?', 'when does London open?', and 'which sessions overlap right now?', giving clear guidance on when to use this tool. It does not mention alternatives or when not to use it, but the usage context is very clear.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe, open-ended read-only query. The description adds no extra behavioral context beyond scope (clients/platforms), which is adequate but 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 sentences: the first states purpose, the second gives usage triggers. No wasted words, front-loaded with the core 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?

For a zero-parameter, no-output-schema informational tool, the description fully covers what and when. The list of platforms is exhaustive for typical use cases, and no additional context is needed.

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?

No parameters exist in the schema, so the baseline is 4. The description adds value by listing the types of questions the tool handles (OAuth, API key, specific clients), effectively documenting what would otherwise be implicit.

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 action ('Explain which authentication mode to use') with a clear resource (FXMacroData MCP) and scope (across major clients and platforms). It distinguishes from sibling tools, which are mostly data-fetching tools, by focusing on auth guidance.

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

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

Explicitly says 'Use this when the user asks whether to use OAuth, an API key...' and enumerates specific clients/platforms. However, it does not explicitly mention when not to use it or provide alternative tool names, though none are obvious.

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 indicate readOnlyHint=true, destructiveHint=false. The description adds behavioral context beyond these flags by revealing the tool's meta-purpose: it explains server capabilities, tool rendering modes, and access tiers, which sets expectations for a textual, informative 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?

The description is compact and front-loaded with the main purpose ('Explain what...') followed by specific sub-topics and usage triggers. Every clause adds value, with no redundant or filler language.

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?

As a capabilities/discovery tool with no parameters and no output schema, the description fully covers what the tool does and when to use it. It also complements sibling tools by clearly positioning itself as the gateway for overview questions, making the response complete for an agent.

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

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

The tool takes zero parameters, so the schema places no burden on the description. With no params to describe, the baseline of 4 applies as the description correctly explains what the tool does without needing parameter details.

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 ('Explain') and a clear resource (FXMacroData MCP server capabilities) while enumerating concrete topics: which tools render MCP Apps, which return plain rows, public vs subscriber-only, and cross-client selection. This clearly distinguishes it from sibling tools like mcp_auth_guide or data_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?

The description explicitly states when to use the tool: 'when a user asks what is available, why visuals are not showing, or how to get the same result in a different interface.' This provides actionable triggers and helps the agent route correctly versus 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 the tool as read-only and non-destructive. The description adds behavioral context by noting 'metadata-first' and 'grouped by API endpoint type', which clarifies the nature of the payloads. This is similar to the high benchmark, where annotations cover safety and description adds scoping, so a 3 is appropriate.

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 just two sentences, with the first stating the core action and the second providing essential supported values. While the long lists add density, they are directly useful and each word serves a purpose. There is no redundant fluff.

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 and strong annotations, the description provides adequate context for a metadata retrieval tool. It explains what is returned, how to select parameters, and lists supported values. It does not discuss pagination or response details, but the output schema covers return structure.

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 detailed parameter descriptions, so the baseline is 3. The tool description repeats the supported lists for endpoint_type and dataset but adds no additional meaning beyond what the schema already provides, such as conditional requirements for component.

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 tool retrieves 'metadata-first official dataset payloads grouped by API endpoint type', with a specific verb and resource. It lists supported endpoint types and datasets, making its scope unambiguous and distinguishing it from sibling data tools like commodities or forex.

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 provides instructions on parameter selection ('Use endpoint_type to pick...') and enumerates supported values, implying usage when those datasets are needed. However, it does not explicitly contrast with alternative tools or state conditions for when not to use it, leaving some ambiguity relative to sibling tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds behavioral context by mentioning MCP Tasks support and listing the combined context sources, which goes beyond the annotations.

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

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

Two sentences, no fluff. The core action and the MCP Tasks behavior are stated efficiently, with no redundant 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?

Given full schema coverage and annotations, the description explains the tool's purpose and the three combined components. It lacks a description of the output format, but the tool name and 'intelligence pack' imply a structure. Slightly more detail on returned data could push it to 5.

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 input schema provides 100% coverage with descriptions for all four parameters, so the description need not repeat them. The description adds a high-level hint about the context sources but does not add parameter-specific semantics 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 clearly states the tool builds an intelligence pack for an FX pair, specifying the combination of policy-rate spread, spot-rate, and release-timing metadata. This distinguishes it from sibling tools like fx_backtest_task or macro_briefing_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 description implies usage: use when you need an intelligence pack for an FX pair with those three context types. It also notes support for MCP Tasks for async execution, adding context. However, it does not explicitly exclude alternative tools or name 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, openWorldHint=true, and destructiveHint=false, so the safety profile is known. The description adds useful behavioral context by specifying that the check covers both the API and MCP server reachability, and that it is for unexpected failures. It does not describe return format, but the output schema exists to cover that.

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

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

The description is exceptionally concise: two short sentences with no wasted words. The key phrase 'Quick health check' is front-loaded, and the usage guidance is directly stated.

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 zero-parameter health check, the description fully covers what the tool does and when to use it. The output schema exists to document return values, and the annotations cover safety. No additional context is necessary.

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 is 4. The description adds nothing about parameters, but none exist, so no further elaboration is needed.

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 tool's purpose: 'Quick health check that confirms the FXMacroData API and MCP server are reachable.' The verb 'confirms' and the resource 'FXMacroData API and MCP server' are specific, and this distinguishes it from all sibling tools, none of which are health checks.

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?

Explicit guidance is provided: 'Use this only if other tools fail unexpectedly — it is not needed before normal calls.' This clearly states when to use and when not to use, effectively differentiating it from normal data access 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 and destructiveHint=false. The description adds meaningful behavioral guardrails: 'This tool never fetches arbitrary URLs or runs custom chart code; it only composes approved FXMacroData API surfaces.' This usefully constrains expectations beyond the annotations, though it does not discuss output format or error 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 description is compact and front-loaded. The first sentence states the core purpose, the second gives usage context, the third lists supported sources, the fourth provides a concrete example, and the final sentence states an important safety boundary. Every sentence earns its place.

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

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

For a complex tool with 19 optional parameters and no output schema, the description is adequately complete for tool selection and invocation. It covers what the tool does, when to use it, what sources it supports, and a representative multi-series example. It does not describe the returned artifact structure, but the visual-artifact nature of the tool makes that less critical.

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 input schema already covers all 19 parameters in detail, so the baseline is 3. The description adds value by giving a worked example of combining an announcements series with a predictions series using prediction_type=market_consensus, which clarifies how the series parameter should be structured. It also names the supported source families with concrete examples.

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 clear verb and resource: build a generic MCP Apps chart from FXMacroData endpoint families. It also distinguishes itself from sibling visual-artifact tools by emphasizing arbitrary plot requests, multi-series composition, and actual-vs-consensus views, with a concrete example.

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 explicitly states when to use the tool: 'arbitrary plot requests, multi-series charts, and actual-vs-consensus views that need to combine announcements with event_predictions.' It does not explicitly name sibling alternatives or exclusion conditions, but the positioning against single-family visual artifact tools is clear enough.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is known to be safe. The description adds no additional behavioral context beyond its purpose, such as output format, data sources, date handling, or edge cases. It merely restates what the tool does, offering no value beyond the annotations.

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

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

The description is a single, front-loaded sentence beginning with the verb 'Build.' It efficiently conveys the chart type, comparison elements, and purpose without extraneous words or 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?

Given the fully documented parameter schema and read-only annotations, the description provides sufficient context for a chart-building tool. However, it could elaborate on what constitutes a 'rate differential setup' or the output format, leaving a minor gap in completeness.

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% for all four parameters, including supported currency codes and date format examples. The description adds no new semantic meaning beyond the schema; it only mentions base and quote in passing, which is already fully documented.

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 tool builds a two-series chart comparing base and quote policy-rate history, which is a specific verb and resource. It distinguishes itself from sibling visual artifact tools by focusing on policy-rate differentials for FX pairs, making its purpose unambiguous.

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

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

The description implies a use case—visualizing policy-rate differentials—but does not explicitly state when to use this tool versus alternatives like forex_visual_artifact or rate_differentials. No exclusions or alternative tool mentions are provided, leaving usage guidance implied rather than explicit.

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

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

Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds behavioral context by clarifying that the tool uses a heuristic elasticity assumption ('not a forecast guarantee') and supports async execution, which goes beyond the annotations without contradicting them.

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

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

Two concise sentences: the first states the core functionality, the second notes the async capability. No redundant phrasing or filler; information is front-loaded and easily parsed.

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

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

Given the complexity (8 parameters, no output schema), the description covers the tool's purpose and key behavioral aspect (heuristic elasticity). It does not describe the return format, but the extensive schema documentation and annotations compensate. For a task-based tool, this is reasonably complete.

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

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

Schema description coverage is 100%, with every parameter described. The main description does not add extra parameter semantics beyond the schema, and the schema adequately explains each parameter's meaning and 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 clearly states a specific action ('Run a policy-rate spread what-if scenario'), the resource ('FX pair'), and the outcome ('estimate directional spot impact'). It distinguishes itself from sibling tools like fx_backtest_task and event_impact_replay_task by emphasizing the policy-rate spread heuristic and elasticity assumption.

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 usage for task-augmented requests but does not explicitly contrast with alternative tools. It mentions async support via MCP Tasks, which is helpful context, but lacks explicit guidance on when to choose this tool over 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 establish readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the behavioral detail that MCP Tasks are supported for async execution, which goes beyond the annotations. It does not describe return format, but this is a minor gap given the annotation coverage.

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 two sentences, with the main purpose front-loaded and no filler. It is concise and well-structured, earning its place without redundancy.

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

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

Given the tool's complexity and the lack of an output schema, the description should explain what the tool returns or how the result is presented. It mentions async execution but does not clarify output behavior. The schema and annotations cover inputs and safety, but the missing return-value information leaves a clear 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%, with each parameter (positions_json, horizon_events, stress_shock_pct) having descriptions and examples. The description adds high-level context by linking the parameters to concentration, stress, and catalyst risk, but it does not provide any parameter-specific information beyond what the schema already contains.

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 tool analyzes a multi-position FX book for concentration, stress exposure, and event-driven catalyst risk. The specific verb 'Analyze' and the resource scope distinguish it from sibling task tools like fx_backtest_task or macro_briefing_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 description implies usage for FX portfolio risk analysis, but provides no explicit guidance on when to choose this tool over alternatives. The only usage-specific detail is 'Supports MCP Tasks for async execution when clients send task-augmented requests,' which addresses execution mode but not selection criteria.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by stating the tool returns raw data 'without adding derived sentiment or indicator classifications' and that it provides 'original official release rows', offering a clear picture of the output nature beyond the annotations.

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

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

The description is two sentences: the first clearly states the core function, and the second provides usage guidance. Every sentence earns its place; there is zero redundancy or filler.

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

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

Given the tool's simplicity (one required parameter, full schema descriptions, annotations, and an output schema), the description fully covers the necessary context. It explains what the tool does, how it differs from a sibling, and when to use it, without needing to explain return values since an output schema exists.

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 well-documented in the schema itself. The description does not add new parameter details or examples, but it does clarify the overall purpose of the 'currency' parameter. This aligns with the baseline for high schema 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 the specific verb 'Return' with a clear resource: 'public central-bank press-release archive for a currency'. It explicitly distinguishes itself from the sibling tool macro_news by stating the difference between raw releases and headline summaries, and also clarifies it does not add sentiment or indicator classifications.

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?

Explicit usage guidance is provided: 'Use macro_news when a headline summary is useful; use this tool when the original official release rows matter.' This directly tells the agent when to prefer this tool over an alternative, including a when-not-to-use condition.

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 discloses key computational behaviors: deterministic projection, stress percentiles, horizon assumptions, and async execution support. Since annotations already declare readOnlyHint=true and destructiveHint=false, the added context about computation methods and async capability provides value beyond the structured metadata.

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 two sentences totaling ~35 words, front-loaded with the core purpose and augmented by the async note. No redundant or filler 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?

With 9 parameters and no output schema, the description gives a high-level view of what the tool does but doesn't detail output structure or edge cases. It lists key outputs (projection, stress percentiles, horizon assumptions) but remains somewhat vague for a complex tool lacking an 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?

All 9 parameters are fully described in the schema, so the baseline is 3. The description adds minimal extra information about parameters, though 'horizon assumptions' hints at horizon_days. Overall, 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 clearly states the tool 'Run[s] an expanded quant-style policy scenario for an FX pair' with specific outputs (deterministic projection, stress percentiles, horizon assumptions). It uses a specific verb and resource, but doesn't explicitly differentiate from the similar sibling 'policy_scenario_modeler_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?

It mentions support for MCP Tasks for async execution when clients send task-augmented requests, providing a concrete usage context. However, it doesn't provide guidance on when to choose this tool over alternatives like 'policy_scenario_modeler_task' or 'fx_backtest_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 and destructiveHint=false, but the description adds meaningful behavioral disclosure beyond that: it is a subscriber-only tool and it 'preserves the endpoint's requested view and method metadata.' This gives the agent useful operational context about permissions and response fidelity.

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, both information-dense. The first sentence states the action and outputs; the second adds access and metadata context. Every word earns its place, with no filler or redundancy.

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

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

Given the tool's moderate complexity (6 parameters, 1 required) and the presence of an output schema and annotations, the description is mostly complete. It conveys the core functionality, access requirements, and output categories. It lacks a note about date handling or data availability, but these are covered by the schema and output schema, so the description is sufficient.

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 baseline is 3. The description adds value by explicitly naming the view options ('nodes, slopes, or derived forward segments') and limiting to 'one currency,' which reinforces the 'view' and 'currency' parameters. It also mentions 'method metadata' which highlights the 'method' parameter's purpose.

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 verb 'return' and the specific resource: 'official government-nominal curve nodes, slopes, or derived forward segments for one currency.' This distinguishes it from sibling tools like rate_differentials by specifying the exact data type and scope. It is unambiguous and action-oriented.

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 clear context that this is a subscriber data tool, implying access restrictions, and specifies it returns data for one currency. However, it does not explicitly mention when to use this versus alternatives or provide exclusions, so it misses the highest bar for 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 indicate read-only and non-destructive behavior. The description adds that the differential may be 'stored or derived' and that the result includes metadata (measure, rate type, curve family, tenor), which is useful for interpreting the response and goes beyond the annotations.

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

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

Two focused sentences with no filler. The core purpose is stated first, and the guidance about returned metadata is kept minimal and relevant.

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 11 parameters and an output schema, and the description covers the essential purpose and result interpretation. Some relationships between parameters (e.g., curve_family only relevant for forward) are left to the schema, but overall this is adequate for a read-only query 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?

All 11 parameters have detailed descriptions in the schema, so the description adds little beyond mentioning that returned metadata should be used. There is no additional parameter-specific semantics beyond what the schema already provides.

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 action ('Return') and the resource ('stored or derived rate differential for one FX pair'). This distinguishes it from sibling tools like rate_curve and policy_rate_differential_visual_artifact, which focus on curves or visual outputs.

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 usage for retrieving FX pair differentials and instructs using the returned metadata when explaining results, but it does not explicitly state when to use this tool over alternatives or provide exclusions. Usage context is largely implicit.

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 substantially enriches the sparse annotations (readOnlyHint, openWorldHint, destructiveHint) by explaining the return format: ISO-8601 announcement_datetime values in UTC, market-local timestamps, release string, and currency code. It also discloses the future-only default behavior, the optional timezone-derived field, and specific agent guidance about not surfacing stale past rows or summarizing the tool as merely a row count.

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 guidance is front-loaded and high-value, but the description becomes bloated by repeating the full supported currencies and indicators lists that already exist in the input schema. The duplicated lists consume significant tokens without adding new information. Still, the behavioral and usage instructions are clearly structured and actionable.

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

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

With no output schema, the description carries the burden of explaining return values, and it does so thoroughly: row structure, timestamp formats, timezone behavior, default future-only filtering, and date-bound semantics. It also enumerates supported currencies and indicators, making the tool fully callable without external documentation.

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 each parameter's type and format. The description adds practical meaning beyond the schema: timezone produces an additional announcement_datetime_requested_timezone field, indicator narrows to a single series, and start_date/end_date should be used when the user mentions a month, week, day, or explicit date range. This goes beyond the schema's bare definitions.

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: 'Get upcoming scheduled macroeconomic release timestamps for a currency.' This clearly states what the tool does and differentiates it from related siblings like latest_announcements and release_calendar_visual_artifact by focusing on scheduled calendar data rather than news or visual presentation.

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 explicit use cases: 'Use this when the user asks "when is the next CPI/GDP/payrolls/policy decision", or to plan a trade around a known release.' It also provides guidance on when to pass timezone, indicator, and date bounds, and cautions not to show stale rows unless historical data is explicitly requested. It does not name alternative tools, so it stops short of a full when-not-to-use comparison.

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 read-only/non-destructive behavior, and the description adds meaningful context: it is a visual artifact whose payload matches release_calendar and triggers inline client rendering. It also discloses that raw/JSON output is not the intended use of this tool.

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

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

The actionable usage guidance is front-loaded and well structured. However, the two enormous supported-currency/indicator lists exactly duplicate the schema's parameter descriptions, consuming most of the tool description with redundant text.

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 description fully routes between this tool and its release_calendar sibling, explains the visual rendering behavior, and maps all optional parameters to user intents. With no output schema, a bit more about the returned artifact would help, but the description is adequate for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds situational guidance beyond the schema: when to pass indicator/start_date/end_date filters and when to pass timezone. The repeated supported lists add no new information over the schema, but the intent-to-parameter mapping is genuinely useful.

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 this is the visual/rendered variant of release_calendar and explicitly names the interactive Release Calendar App behavior. It is unambiguously distinguished from the plain release_calendar sibling, so an agent can select it correctly.

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 explicit default preference ('Prefer this by default') for show/display/visualize/render requests, and names the exact alternative condition ('Only prefer plain release_calendar') for raw/JSON/text output. This is model routing guidance, not just a vague 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 and destructiveHint=false, so the system knows this is a safe read operation. The description adds meaningful context about the heuristic approach (release-calendar proximity, indicator-level) and async MCP Tasks support, which goes beyond the annotations without contradicting them.

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

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

The description is a tight two sentences, with the core purpose front-loaded and the async support detail placed second. Every word earns its place; no filler or repetition of schema/annotation 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?

The tool is straightforward (3 params, read-only), but there is no output schema, and the description does not explain what the output looks like or how the risk score should be interpreted. The heuristic details are useful, but without return-value context, the description isn't fully 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?

The input schema fully documents all three parameters with descriptions, examples, and defaults, achieving 100% schema description coverage. The tool description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate; the schema carries the explanatory weight.

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 tool's function: score upcoming releases for a currency pair using release-calendar proximity and indicator-level heuristics. It names a specific resource (currency pair releases) and method, but does not explicitly distinguish it from sibling task tools like event_impact_replay_task or pair_intel_task, making it clear but not fully differentiated.

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

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

No guidance is provided on when to use this tool versus alternatives. The description mentions MCP Tasks support but does not specify appropriate contexts, prerequisites, or exclusions. Given the large sibling set, this lack of usage direction is a notable gap.

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 indicate a safe read operation (readOnlyHint=true, destructiveHint=false). The description adds value by listing what the result includes: composite score, regime label, component contributions, pagination, and data_quality metadata, which is beyond the annotations.

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

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

The description is three concise sentences: first states the action and resource, second lists output components, third gives usage guidance. Every sentence contributes without redundancy or fluff.

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 detailed. The description adequately covers purpose, usage context, and output components. Minor omission is series granularity/frequency, but this is likely handled by the 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 covers both parameters (start_date, end_date) with descriptions and examples, achieving 100% coverage. The description does not add parameter-specific details, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool returns a 'global risk-on/risk-off sentiment series' used for FX regime analysis, differentiating it from sibling tools that focus on specific asset classes or tasks. The verb 'Return' is specific and the resource is well-defined.

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 explicit usage context: 'Use this for cross-asset regime context before classifying high-beta, safe-haven, commodity, or USD-defensive FX conditions.' However, it does not mention when not to use or name alternatives, 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 mark readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by listing the exact computed metrics returned ('monthly average return, median return, win rate, sample size, dispersion, and per-year monthly returns') and noting the data source ('from stored FX or gold series'). No contradiction.

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 action, then usage triggers, then return metrics. Every sentence earns its place; no filler or repetition of schema 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?

With an output schema present and annotations covering side effects, the description provides enough information: what data is used, what metrics are returned, and when to use it. It covers the key aspects an agent needs to select and invoke the tool correctly.

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

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

Schema coverage is 100%: all four parameters have descriptions and examples. The description adds a minor semantic cue that the data is pre-stored seasonality, but doesn't extend beyond schema for parameter meaning. Baseline 3 applies since 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 opens with 'Get monthly return seasonality for an FX pair or XAU/USD', a specific verb+resource combination. The scope is clear and distinct from sibling tools like forex or commodities, mentioning seasonal patterns, month-of-year tendency, and win rate. It clearly states what the tool does.

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 second sentence gives explicit use triggers: 'Use this when the user asks for seasonal patterns, month-of-year tendency, historical monthly win rate, or XAUUSD/gold seasonality.' This is clear context for when to invoke the tool, though it doesn't explicitly name alternatives or exclusions.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds a behavioral detail by stating it 'Returns a direct checkout path,' clarifying the tool's output. It does not contradict annotations.

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

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

The description is a single sentence that front-loads the verb and resource, provides usage context, and states the return value. Every word earns its place with no redundancy.

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

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

Given the tool has no parameters, no output schema, and simple behavior, the description fully covers what an agent needs: when to invoke it and what to expect (a checkout path). No additional context is necessary.

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 has zero parameters, so the schema is fully covered. The description adds context about what the tool accomplishes, but parameter semantics are inherently minimal. Baseline 4 for zero-param tools 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 clearly states 'Open subscription options' with a specific verb and resource, and explains the purpose: 'when a user needs to unlock MCP app visuals, charts, and advanced analytical tools.' This distinguishes it from sibling data/analysis tools.

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

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

The description provides clear context on when to use it: 'when a user needs to unlock MCP app visuals, charts, and advanced analytical tools.' It doesn't explicitly mention alternatives or exclusions, but the trigger condition is specific enough for an agent to decide.

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