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, openWorldHint=true, and destructiveHint=false. The description adds valuable context beyond annotations: update schedule (every Friday 15:30 ET reflecting Tuesday cutoff), API key requirement, and the nature of the returned data (long/short open interest by trader category). This enriches the agent's understanding without contradicting 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 four sentences, front-loaded with the primary verb and resource, then covers usage, return content, update schedule, auth, and supported currencies without redundancy. Every sentence earns its place and no word is wasted.

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

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

With an output schema present, return values are already documented. The description provides all necessary operational context: what data is returned, when it updates, authentication requirements, supported currencies, and clear use cases. It is complete for the tool's complexity and its position among siblings.

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

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

Schema description coverage is 100%, so the schema fully documents all three parameters. The description does not add significant detail beyond the schema—it repeats the supported currency list and explains the data context, but no new parameter-specific semantics like format nuances or edge cases. 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 'Get weekly CFTC Commitment of Traders (COT) positioning data for a currency's FX futures contract on the CME' – a specific verb, resource, and scope that distinguishes this from sibling tools like 'forex' or 'commodities'. It clearly identifies the data source (CFTC), market (FX futures on CME), and frequency (weekly).

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: 'when the user asks about speculator positioning, non-commercial longs vs shorts, hedge-fund FX positioning, or wants to gauge sentiment extremes.' It does not provide explicit when-not-to-use or name alternatives, but the use cases are clear and sufficiently guide selection among 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 the read-only, non-destructive nature. The description adds useful context about the default metric and that output includes chart metadata. It does not detail what the chart artifact contains or any rate/format behavior, but this is acceptable 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?

Two concise sentences, front-loaded with the key relationship to cot_data and the default behavior. Every word earns its place, and the metric hint is efficiently integrated.

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 a small, well-documented schema, and the description leverages the sibling cot_data for payload details. It is clear enough for the agent to know what to expect, though a more explicit statement of return format or output structure would make it 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 schema already has full descriptions for all parameters (100% coverage), including default and examples for `metric` and currency codes. The description reinforces that `metric` selects which field to chart but does not add significant new 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 clearly states the tool produces a visual artifact of COT data, referencing cot_data for payload similarity and MCP Apps chart metadata. It distinguishes itself from cot_data by adding chart metadata and specifies the default plotting target (noncommercial net positioning).

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

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

It implies usage: use this tool when chart metadata is needed, versus cot_data for raw data. It also explains how to customize the chart via the `metric` parameter. However, it does not explicitly state when not to use it or mention alternatives like other visual artifacts, though the sibling context makes it 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?

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, and the description adds the async MCP Tasks behavior, which is useful context for invocation. There is no contradiction with annotations; side effects and auth requirements are not mentioned, but the safety profile is already covered.

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 two sentences covering purpose and async execution. Both sentences earn their place 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?

The tool has 7 parameters and no output schema, but the description only gives a high-level output concept. The schema covers parameters well, so the main gap is the lack of details about the resulting timeline structure and heuristic markers, making it adequate but not 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 provides 100% coverage with detailed descriptions for all 7 parameters. The tool description itself does not add parameter-level meaning, so the baseline 3 applies.

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

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

The description uses a specific verb ('Create') and resource ('point-in-time replay timeline') and indicates the mapping to FX context and heuristic impact markers. However, it does not explicitly differentiate from sibling task tools like fx_backtest_task or macro_briefing_task, so it's clear but not fully distinguishing.

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

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

The description implies use for creating replay timelines but does not explicitly state when to prefer this over alternatives. It does mention async execution via MCP Tasks as a usage condition, providing some context, but lacks exclusions or alternative comparisons.

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 does not contradict them. It adds non-obvious traits: rows are keyed by announcement_id/date/indicator and include prediction source metadata. It also enumerates supported currencies and indicators, though these are also in the schema.

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

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

The description front-loads purpose and usage but then repeats the full supported-currency and indicator lists already present in the schema. This duplication makes it long and redundant. The core description could be two sentences; the lists belong in the schema alone.

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

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

With an output schema present, the description need not explain return values. It provides a clear use case, keying structure, and source metadata context. It doesn't mention sorting or pagination, but those are in the schema. For a read-only forecast lookup tool, this 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?

The schema covers 100% of parameters with descriptions, examples, defaults, and explicit constraints (e.g., 'Currency-wide prediction reads are not supported'). The description adds marginal meaning by mentioning 'stored forecasts' and 'prediction source metadata' that relate to prediction_type/source, but it largely duplicates the schema's indicator and currency lists. 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 ('Return stored forecasts...') and enumerates the exact prediction types (consensus, central-bank, survey, IMF, nowcast, FXMacroData). It further distinguishes itself from siblings like release_calendar and indicator_query by noting it serves actual-vs-consensus and event-surprise contexts. Rows keyed by announcement_id/date/indicator clarifies the resource structure.

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 explicitly states when to use: 'Use this with release_calendar and indicator_query when a report needs actual-vs-consensus, prior-vs-forecast, or event-surprise context.' This connects the tool to sibling tools and specific report needs. It doesn't explicitly state when not to use, but the context is strong 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, 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 tool as read-only and non-destructive. The description adds valuable behavioral context beyond that: it mentions async execution via MCP Tasks and reveals that the tool combines data types (series data, analytics, release timing). This goes beyond what annotations alone convey, though it does not cover pagination or rate limits.

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

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

The description is two sentences and every clause earns its place: the first sentence defines the deliverable and its components, the second covers the async execution nuance. It is front-loaded with the core purpose and avoids 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 complexity (no output schema, 4 parameters, task-based) the description adequately explains what the tool produces by listing the combined data sources. It does not describe the exact return format, but the absence of an output schema and presence of sibling 'intelligence pack' tools mitigate that gap. The async execution note also adds useful 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?

The input schema provides 100% description coverage, so the schema already tells the agent what each parameter means. The description does not add extra parameter-level semantics beyond tying the indicator to 'one indicator' and mentioning chart-ready series data. Baseline 3 is appropriate 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 uses a specific verb ('Build') and resource ('intelligence pack for one indicator') and clarifies what the pack contains: chart-ready series data, derived analytics, and release timing context. This clearly differentiates it from siblings like indicator_query (raw data) and indicator_visual_artifact (visual output), while also noting async MCP Tasks support.

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 by describing the tool's purpose ('Build an intelligence pack...'), but there are no explicit when-to-use or when-not-to-use instructions, nor any alternative tools named. Given a large sibling toolset with other task-oriented tools (e.g., pair_intel_task, macro_research_pack_task), this lack of explicit guidance is a noticeable 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?

Beyond the annotations (readOnlyHint=true, destructiveHint=false), the description discloses the row return shape, pagination metadata fields, official-source filtering behavior, and always-removed private aggregator rows. It also explains the point-in-time intent of `announcement_datetime`, which is valuable behavioral context not present in the annotations or schema.

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

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

The opening sentences are efficient and front-loaded, but the description becomes needlessly long by duplicating the full supported-currency and supported-indicator lists that already exist in the schema property descriptions. A significant portion of the text is redundant with structured fields, making it less concise than it should be.

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?

Despite the verbosity, the description is contextually complete: it covers purpose, use cases, return row semantics, pagination, data provenance filtering, authentication, prerequisites, and the sibling alternative. The presence of an output schema reduces the need to explain return values in the description, and the description still adds enough workflow context to be fully actionable.

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

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

Schema coverage is 100% and each parameter already has a rich description. The description adds practical usage semantics on top, such as how to combine `limit`, `offset`, and `page` for pagination and how to interpret `pagination.next_offset`. It also reinforces the `official_only` default. This exceeds the baseline for a fully described schema.

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

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

The description opens with a specific verb and resource: 'Get a paginated historical time series of a single macroeconomic indicator for a currency.' It names common use cases (CPI, GDP, unemployment, etc.) and explicitly distinguishes itself from the sibling tool `indicator_visual_artifact` by saying this 'plain tool returns raw rows for data workflows.'

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 when-to-use guidance ('Use this for CPI/inflation, GDP...'), an explicit alternative (`indicator_visual_artifact` for chart rendering), a required prerequisite ('Always call data_catalogue(currency) first'), and an authentication caveat (USD free, non-USD requires API key). This leaves little ambiguity about when to choose 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 and destructiveHint=false, so the description adds context beyond that by mentioning the rendering metadata, client compatibility, and pagination.next_offset behavior. It doesn't contradict annotations and provides useful behavioral details, though it omits any discussion of rate limits or auth.

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 clear usage guidance but becomes excessively long by repeating the full supported currencies and indicators lists that are already present in the schema. This redundancy violates the principle of not repeating structured fields. The core prose is efficient, but the overall length is not appropriately sized.

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

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

Given the tool's complexity (many parameters, sibling variants, optional output format) and the lack of an output schema, the description thoroughly answers when to use it, what it returns, and how to handle pagination. It also names the alternative tool for raw data needs, making it contextually complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining how to combine limit, offset, and page for broad histories and by mentioning pagination.next_offset, which goes beyond the schema's per-field descriptions. It also lists supported currencies/indicators, though these duplicate schema fields.

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

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

The description clearly states the tool returns the same payload as indicator_query but with MCP Apps metadata for interactive chart rendering, distinguishing it from its sibling. It also specifies the exact resource (indicator time-series data) and the verb (returns/renders).

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 says to prefer this tool by default for indicator time-series requests, lists specific user intents (show, tell, explain, compare, inspect a trend, review a recent window), and gives fallback conditions for when to use indicator_query instead. It also advises using limit/offset/page controls for broad histories rather than arbitrary retries.

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 read-only and non-destructive behavior. The description adds meaningful context about the point-in-time logic (using announcement_datetime) and async execution support via MCP Tasks, which goes beyond the annotations. While it doesn't disclose return format or error conditions, it provides useful behavioral details for a read-only query tool.

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

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

The description is two concise sentences, front-loaded with the core action and key qualifier. The mention of async support is secondary and placed at the end. No redundant or filler content; every word contributes to understanding.

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 query tool with no output schema, the description adequately conveys the main behavior and context. The schema is rich enough to cover parameter details. The description does not explain what the returned 'slice' looks like, but the tool's name and domain context make it reasonably clear. Given the good annotations and schema, this is sufficiently 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 each parameter (as_of, currency, indicator, start_date, end_date) having detailed examples and semantics. The tool description does not add additional parameter information beyond what the schema already provides. Baseline of 3 is appropriate 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 clearly states the tool's purpose: returning a point-in-time slice of a macro series. It uses a specific verb ('Return'), identifies the resource ('macro series'), and adds the key qualifier ('known at a specific timestamp'). This distinguishes it from sibling tools like indicator_query or latest_announcements by highlighting the point-in-time integrity mechanism (announcement_datetime).

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 point-in-time correctness is needed (via 'announcement_datetime as the point-in-time integrity boundary'), but it does not explicitly state when to use it over alternatives or exclude other tools. It mentions async support for task-augmented requests, which is a usage context, but lacks direct comparison to sibling query 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, 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 need not restate that. It adds value by disclosing async execution support and the specific return matrix contents (latest values, recent changes, z-scores), which are behavioral details beyond what annotations provide.

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

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

The description is two sentences: the first states purpose and output, the second adds the async capability. No unnecessary words; it is front-loaded and every clause contributes meaning.

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

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

No output schema exists, so the description must explain return values, and it does (matrix with three value types). It also explains the async execution mode. However, it doesn't clarify default behavior for omitted date/currency/indicator parameters or the exact matrix orientation, which would have made it fully self-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 description coverage is 100%, so parameters are already fully documented. The description adds little beyond implying that indicators are time series and the matrix is cross-currency, which is already evident from the schema fields and examples. It does not clarify parameter formatting or interactions 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 opens with a specific action and resource: 'Build a cross-currency macro heatmap from indicator time series' and clearly defines the output as 'a matrix with latest values, recent changes, and z-scores.' This is a specific verb+resource that distinguishes it from sibling tools like indicator_query 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 clearly implies the primary use case (building a cross-currency heatmap) and adds a technical condition: 'Supports MCP Tasks for async execution when clients send task-augmented requests.' It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to understand when it applies.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral details: it returns 'official-source headline rows' and notes that affected_indicators and sentiment are 'keyword-derived' and provided 'when a headline is classifiable', indicating conditional heuristic output. 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 concise at three sentences, front-loaded with the core purpose in the first sentence, usage context in the second, and output details plus supported currencies in the third. Every sentence adds important information with no 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 a rich output schema present and fully described parameters, the description provides sufficient context: it states the tool's purpose, usage scenarios, output characteristics, and supported currencies. Given the tool's moderate complexity, the combination of annotations, schema, and description is complete and actionable.

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 has 100% coverage with descriptions for all four parameters, so the schema does the heavy lifting. The description adds minimal extra meaning beyond listing supported currencies, which the schema already includes. The baseline of 3 is appropriate since the description does not significantly enhance parameter understanding.

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 ('Return') and resource ('recent official central-bank news and press-release headlines for a currency'), clearly distinguishing it from sibling tools like 'press_releases' by emphasizing 'central-bank' and 'headline context'. It also specifies the output includes affected_indicators and sentiment, making the tool's function unmistakable.

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: 'Use this when a report needs headline context for central-bank policy, inflation, employment, GDP, trade, fiscal, energy, or commodity narratives.' This provides clear context for usage. However, it does not explicitly mention when not to use it or name alternative tools, so it falls just 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 cover read-only and non-destructive behavior, so the description adds value by disclosing that it is 'persistent-host-friendly' and supports asynchronous execution for task-augmented requests. This goes beyond the annotations and offers insight into how the tool behaves in execution contexts.

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 action verb 'Bundle,' and every phrase earns its place. The first sentence efficiently lists the payload components; the second clarifies async/task support 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 comprehensive schema and annotations, the description adequately explains the tool's output concept ('one ... research payload' containing catalogue, history, timing, and FX context). It lacks a detailed return structure, but with no output schema and a fairly simple bundling purpose, the description is complete enough for an agent to understand when and how to invoke it.

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

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

Schema description coverage is 100% with detailed descriptions for every parameter, so the description does not need to repeat parameter details. It adds general context by mentioning FX pair (base/quote) and indicator history, but no specific parameter-level 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 uses a specific verb ('Bundle') and names concrete resources: catalogue, indicator history, next release timing, and optional FX pair context. This clearly distinguishes it from sibling tools like indicator_query or data_catalogue by emphasizing the combined payload 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 it: when a consolidated research payload containing catalogue, history, release timing, and FX context is desired. It also mentions async execution via MCP Tasks, providing a clear usage context, though it does not explicitly state when not to use it or name alternative 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 openWorldHint=true. The description adds a meaningful behavioral trait: async execution via MCP Tasks, which is not conveyed by the annotations. It also implies output is a deliverable cockpit, but does not detail return format or error behavior, so it gets credit for the async disclosure.

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

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

Two sentences, each earning its place. The first states the primary purpose with specific components, the second adds the essential async usage note. No filler, redundant, or ambiguous 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?

The tool has 6 optional parameters, all documented in schema, but no output schema. The description explains what the tool builds but does not clarify output format, return behavior, or what happens when parameters are omitted. Given its complexity (multi-panel cockpit), a bit more detail on outputs and execution flow would improve 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?

The input schema already documents all 6 parameters with descriptions and defaults (100% coverage). The description adds high-level context like 'pair context' and 'release queue' which loosely maps to base/quote and currency, but provides no additional parameter-level details. Baseline of 3 is appropriate since schema does the heavy lifting.

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

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

The description states a specific verb ('Build') and a concrete resource ('multi-panel macro market cockpit'), and enumerates the panels (FX sessions, upcoming release queue, pair context, generated risk alerts). This clearly separates it from sibling dashboard tools like macro_briefing_task or macro_heatmap_task by emphasizing the multi-component cockpit 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 notes that it 'Supports MCP Tasks for async execution when clients send task-augmented requests', giving a conditional usage hint. However, it does not explicitly state when to prefer this over alternatives like macro_briefing_task, nor does it provide exclusions or scenarios where it should not be used.

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, so the safety profile is known. The description adds meaningful behavioral context beyond that: it 'never fetches arbitrary URLs or runs custom chart code' and only 'composes approved FXMacroData API surfaces.' This clarifies the tool's boundaries and is genuinely useful for an agent deciding on safe invocation. It does not contradict any 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 front-loaded with the core purpose, followed by use cases, supported sources, a worked example, and a safety constraint. Every sentence earns its place; the length is justified by the tool's complexity (19 parameters, multiple sources). It is concise enough to be read quickly while providing substantial guidance.

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

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

Given the tool's complexity, the description adequately covers the essential operational context: what the tool does, when to use it, which data sources are supported, a concrete usage example, and an explicit boundary for what it will not do. The rich input schema supplies parameter-level details, and the read-only annotations cover safety. No output schema exists, but for a chart-building tool the lack of return-type documentation is acceptable because the description frames it as an app composition rather than a data-fetching endpoint.

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 goes beyond the schema by providing a concrete example that shows how to structure the 'series' parameter for a multi-series chart (an announcements series and a predictions series with prediction_type=market_consensus). This adds practical semantic understanding that the bare property list does not convey, justifying a 4.

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

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

The description opens with a specific verb+resource combination: 'Build a generic MCP Apps chart from one or more FXMacroData endpoint families.' It clearly distinguishes itself from sibling visual artifact tools by emphasizing 'generic' and 'multi-series' capabilities, and lists the supported series sources (announcements, predictions, forex, commodities, cot). This is unambiguous and differentiates the tool's role.

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 this tool: 'for arbitrary plot requests, multi-series charts, and actual-vs-consensus views that need to combine announcements with event_predictions.' It also provides a clear limitation ('never fetches arbitrary URLs or runs custom chart code'). However, it does not explicitly name sibling alternatives (e.g., forex_visual_artifact) for when a simpler, single-source plot would suffice, so it falls short of a perfect 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 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?

Beyond the readOnly/announcement annotations, the description discloses default behavior ('Unbounded calls return future releases only'), return format ('ISO-8601 announcement_datetime values in UTC plus market-local timestamps'), row structure ('Each row has a release string...'), and the effect of the timezone parameter. This adds substantial transparency without contradicting 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 core content is front-loaded and concise, but the description includes very long lists of supported currencies and indicators that are already in the schema. This redundancy makes the description longer than necessary, though it does not bury the main purpose.

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

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

With no output schema, the description compensates by explaining the return format (ISO-8601, UTC, local timestamps), row contents, and default future-only behavior. It also gives presentation guidance for consumer-facing clients, making the tool's use and expectations clear.

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 adds meaningful guidance: timezone produces an additional field, indicator narrows to a single series, and start_date/end_date are used when the user mentions a month/week/day or range. This goes beyond the schema's field descriptions.

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 upcoming scheduled macroeconomic release timestamps for a currency', which is a specific verb+resource statement. It further clarifies with concrete use cases ('when is the next CPI/GDP/payrolls/policy decision') and distinguishes from siblings by emphasizing 'upcoming scheduled' and 'release timestamps'.

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 when-to-use guidance ('Use this when the user asks...') and a clear when-not ('do not show stale past rows unless the user explicitly asks for historical/past calendar data'). However, it does not explicitly name alternative sibling tools, so it misses the full 'alternatives' component for 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 context: it is a visual artifact that renders inline in MCP Apps, and shares the same payload as release_calendar. However, it does not elaborate on payload structure or output format, which would be useful but not critical given the reference to release_calendar.

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 instructions are front-loaded and concise, with clear guidance in a few sentences. However, the description repeats the full supported currencies and indicators lists that already exist in the schema descriptions, adding bloat. The redundancy is offset by the usefulness of having the lists inline, but it is not maximally concise.

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 complete for the tool's complexity: it explains the visual rendering behavior, when to choose this over the sibling release_calendar, how to use optional parameters, and lists all supported currencies and indicators. Annotations provide safety context, and the schema documents parameters, so the description fills in the remaining usage and behavioral gaps.

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

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

Schema coverage is 100%, so baseline is 3. The description goes beyond schema by mapping user intents to parameters: 'Pass optional indicator, start_date, and end_date filters when the user names a specific series, month, week, day, or date range. Pass timezone when the user asks for local times in a specific city or region.' This adds practical selection guidance not present in 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 identifies the tool as a visual rendering of release_calendar, with a specific verb+resource ('show, display, visualize, or render a macro release calendar'). It explicitly distinguishes itself from the plain release_calendar sibling by stating it renders an interactive app inline, 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 provides explicit when-to-use and when-not-to-use guidance: 'Prefer this by default when the user asks to show, display, visualize, or render' and 'Only prefer plain release_calendar when the user explicitly asks for a raw table, JSON, exact rows, or text-only output.' It also gives concrete examples and filter usage based on user phrasing.

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.