FXMacroData

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

Annotations declare readOnly and non-destructive, which the description complements by explaining the bounded polling mechanism. It adds context about being MCP-safe and cursor-based, though it does not disclose rate limits or authorization requirements, which are less critical 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 sentences with no unnecessary words. The first sentence states the action, the second explains the usage pattern. Information is front-loaded and every word 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?

The tool has an output schema, so return values are covered. The description covers core functionality and usage pattern adequately. It could mention that the tool only provides recently ingested changes, but that is implied by 'poll recently ingested'. Overall, 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 coverage is 100% with detailed descriptions for each parameter (limit, since, payload, currencies, indicators). The description does not elaborate further on parameters, so it provides no additional value beyond the schema, meeting the baseline for full 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 clearly specifies the tool polls for macro announcement changes with a resumable cursor, distinguishing it from unbounded streams. It explicitly contrasts with the release-event stream and mentions the pagination pattern, making the purpose distinct among siblings like 'latest_announcements'.

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

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

The description provides explicit guidance on using the returned next_cursor for polling, contrasting with unbounded streaming. It implies the tool is for resumable polling, but does not explicitly state when to avoid using it or compare directly to other sibling tools like 'release_calendar'.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds that an API key is needed, which is valuable behavioral context. No contradictions with annotations.

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

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

Two efficient sentences: first states purpose and slug guidance, second lists prerequisites and supported values. No wasted words, front-loaded with key info.

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 4 optional parameters, full schema descriptions, and an output schema, the description covers the tool's purpose, prerequisites, valid parameter values, and alias clarification. It is adequate for an agent to 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?

Schema coverage is 100% with descriptions. The description adds context: 'symbol' is a backward-compatible alias for 'indicator', and lists the exact supported slugs. This clarifies parameter 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 retrieves historical price series for commodity indicators, specifying the verb 'get' and resource 'historical price series'. It lists supported indicators, aiding identification. However, it does not explicitly differentiate from sibling tools like 'commodities_visual_artifact', so it's clear but not perfectly distinguished.

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 'Requires an API key' and instructs using exact slugs from the schema. It does not provide guidance on when to use this tool versus alternatives (e.g., when to choose commodities over cot_data or visual_artifact), leaving the agent to infer.

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, non-destructive, and open-world. Description adds that it packages chart metadata, but doesn't disclose other behavioral traits like data freshness, auth requirements, or error handling 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?

Single sentence, front-loaded with key distinction, 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?

No output schema, but description implies same payload as 'commodities'. Lacks details on return format or chart metadata structure. Adequate for a read-only tool with good annotations.

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 100% of parameters with descriptions. Description adds no extra meaning to parameters; baseline 3 for high schema coverage.

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

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

Description clearly states it is like 'commodities' but with MCP Apps chart metadata for inline rendering. Distinguishes itself from sibling 'commodities' by specifying the visual artifact aspect.

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

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

No explicit when-to-use or when-not-to-use guidance. Implies use for chart rendering, but doesn't compare with alternative 'commodities' or other 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 indicate readOnlyHint=true and destructiveHint=false. The description adds useful behavioral traits beyond annotations: 'Updated every Friday at 15:30 ET reflecting the Tuesday cutoff' and 'Requires an API key'. No contradictions.

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 with approximately 6 sentences. It front-loads the main purpose and usage context. Every sentence provides value, including update schedule, auth, and supported currencies. No waste.

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 an output schema, the description does not need to explain return values. It covers update schedule, auth requirements, supported currencies, and usage context. For a simple tool with 3 parameters, this is fully adequate.

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 description does not need to add much. It lists supported currencies, which is already in the schema. No additional 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 gets 'weekly CFTC Commitment of Traders (COT) positioning data for a currency's FX futures contract on the CME'. The verb 'Get' and specific resource 'CFTC COT positioning data' are precise. It distinguishes from siblings like commodities and forex by specifying CFTC data, and there is no direct COT data sibling.

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

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

The description explicitly says 'Use this when the user asks about speculator positioning, non-commercial longs vs shorts, hedge-fund FX positioning, or wants to gauge sentiment extremes'. This provides clear context. It does not explicitly list when not to use, but the usage guidance is strong.

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, open-world, non-destructive behavior. The description adds that the tool returns chart metadata (beyond raw data) and mentions the default metric. It does not contradict annotations and provides useful context, though it could detail what 'chart metadata' entails.

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 that are front-loaded with the core purpose and a clear instruction for customization. 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?

For a tool with 4 parameters all documented in schema and simple behavior, the description is nearly complete. It lacks an explicit statement about the return format (visual artifact), but the term 'chart metadata' implies it. Overall adequate.

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

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

Schema description coverage is 100%, so the schema already documents each parameter well. The description only adds that the metric defaults to noncommercial_net, which is already in the schema. It provides no additional 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 it charts COT data with MCP Apps chart metadata, distinguishing it from cot_data which returns raw data. It specifies the default chart and how to customize via the metric parameter.

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 indicates when to use this tool over cot_data (when a chart is desired) and how to customize the chart. However, it does not explicitly exclude use cases or compare to other visual artifact tools like commodities_visual_artifact.

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 indicate readOnlyHint and openWorldHint; description does not contradict and adds valuable context: warns about stale/partial data and instructs to check coverage. Adds behavioral detail 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?

Single paragraph of 4-5 sentences, front-loaded with main action, then specific instructions. No wasted words, every sentence earns its place.

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

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

Output schema exists, so return values are documented. Description covers purpose, usage, parameter behavior, and warnings. Complete for a catalogue tool.

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

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

Schema coverage is 100% with clear descriptions. Description adds practical usage guidance: currency lists supported codes, include_coverage is recommended true for usability checks, indicator optional to limit scope. Adds value beyond 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?

Clearly states it lists every macroeconomic indicator for a currency with metadata. Distinguishes from siblings by mentioning it returns indicator slugs for use with indicator_query, release_calendar, indicator_visual_artifact. Verb 'list' is specific and actionable.

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 'ALWAYS call this first when the user asks about a country's macro data' and instructs to check coverage before calling indicator_query. Provides list of supported currencies. Does not explicitly mention when not to use or alternatives, but the context makes it 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, openWorldHint=true, and destructiveHint=false. The description adds that it supports MCP Tasks for async execution, which is useful but does not elaborate on other behaviors like authentication, rate limits, or data freshness. 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 very concise (two sentences, 23 words) and front-loaded with the primary purpose. The second sentence about MCP Tasks is relevant but could be integrated for slightly better flow. 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?

Given the tool's complexity (7 parameters, no output schema) and the presence of many sibling tools, the description is too brief. It does not describe the output format or structure (e.g., what a 'replay timeline' looks like), nor does it explain how this tool differs from alternatives like macro_war_room_task or macro_heatmap_task. Lacks sufficient detail for an agent to use it confidently.

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 descriptions for all 7 parameters (100% coverage), so the baseline is 3. The description does not add any additional context or meaning beyond what the schema already offers, such as explaining how parameters like 'indicator' or 'currency' interact in the replay timeline.

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 creates a 'point-in-time replay timeline mapping macro announcements to FX context and heuristic impact markers'. It names the verb ('create') and the resource ('replay timeline'), but does not explicitly differentiate it from sibling tools like indicator_query or macro_heatmap_task, which might also involve macro events.

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 no direct guidance on when to use this tool versus its siblings. It only mentions MCP Tasks support for async execution, which is a technical detail, not a usage recommendation. There is no when-not or alternative advice.

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, so the read-only nature is known. The description adds value by specifying that rows are keyed by announcement_id/date/indicator and include prediction source metadata. No contradictions.

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 purpose and usage context, but it includes lengthy lists of supported currencies and indicators that are also present in the schema, making it unnecessarily verbose.

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 not detailing pagination, the description covers when to use, what it returns, key structure, and supported values. With an output schema present, it is sufficiently complete for a tool with 9 parameters and many 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 coverage is 100%, so baseline is 3. The description adds marginal value beyond schema, such as noting that currency-wide prediction reads are not supported, but much of the list is redundant with the schema.

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

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

The description opens with a specific verb+resource: 'Return stored forecasts, consensus-style predictions...' and explicitly distinguishes from sibling tools by stating when to use it with release_calendar and indicator_query.

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: 'Use this with release_calendar and indicator_query when a report needs actual-vs-consensus, prior-vs-forecast, or event-surprise context.' It implies when to use but lacks explicit exclusions or when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds behavioral context: data is from 'official central-bank reference rates' with 'daily granularity', and the indicators parameter is detailed. No contradictions 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 well-structured: front-loaded with primary purpose, then usage guidelines, supported currencies, and indicator details. Every sentence adds value, and it avoids redundancy 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?

Given the tool's moderate complexity (5 params, 100% schema coverage, output schema present), the description fully covers data source, granularity, supported inputs, and provides usage guidance. No gaps apparent for agent understanding.

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

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

Schema coverage is 100%, and the description adds beyond schema by explaining default date ranges and the purpose of indicators parameter. It also lists supported values and clarifies the comma-separated format, aiding proper parameter construction.

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 'raw historical FX spot-rate rows for a currency pair', specifying the verb, resource, and scope. It distinguishes from the sibling tool forex_visual_artifact by contrasting plain-text tables vs charts.

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 provides when-to-use vs alternatives: 'Prefer this tool when the user explicitly wants a plain-text table... If the user asks more generally... prefer forex_visual_artifact instead.' It also lists supported currencies, guiding the agent on valid inputs.

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 clear. The description adds that the tool packages the payload 'with MCP Apps chart metadata so compatible clients render an interactive spot-rate chart inline.' This explains the output format but does not disclose other behavioral traits (e.g., rate limits, authorization needs). With annotations covering the safety baseline, a score of 3 is appropriate—the description adds some value but not extensive behavioral context.

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

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

The description consists of two concise sentences. The first sentence defines the tool's functionality, and the second provides clear usage guidance. No extraneous information; every word adds value. Front-loaded with the most critical information.

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

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

Given the tool's moderate complexity (5 parameters, no output schema, but annotations present), the description is fairly complete. It explains the relationship to forex, usage context, and output format (interactive chart). However, it does not explicitly describe what the return format looks like (though it is implied to be a visual artifact). The presence of sibling tools makes the guidance crucial, and the description handles that well. A score of 4 reflects that it covers most needs but could be slightly more explicit about the output 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%, so the schema already documents all 5 parameters thoroughly. The description only mentions 'same payload as forex' without adding any additional meaning beyond what the schema provides. Baseline 3 is correct as the schema handles the parameter documentation fully.

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 it is the same payload as forex but packaged for chart rendering, specifying 'interactive spot-rate chart inline' and distinguishing from plain forex by use case. It precisely defines the tool's purpose as returning a visual artifact for FX pair time-series requests.

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' with concrete examples like 'show me AUD/USD', and clearly states when to use plain forex instead (explicit requests for tables, raw values, JSON, CSV, or row-by-row data). This is excellent disambiguation.

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

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

Annotations declare readOnlyHint, openWorldHint, and destructiveHint. The description adds that the backtest is transparent and rule-based, and supports async execution via MCP Tasks. No contradiction with annotations, and adds useful context beyond 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 long, front-loaded with the core purpose, and adds the async task support detail concisely. No unnecessary 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?

Given 10 parameters, no output schema, and annotations that already provide safety context, the description adequately explains the tool's function but does not describe return values or output format. Somewhat complete for the complexity level.

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?

Input schema has 100% coverage with descriptions for all 10 parameters. The description does not add significant parameter-specific meaning beyond what the schema already provides, so 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?

Description clearly states the tool runs rule-based FX backtests on historical spot data using carry/momentum signals. It distinguishes from sibling tools like 'fx_trade_setup_task' by focusing on backtesting, not trade setup.

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 mentions support for MCP Tasks via async execution but does not explicitly state when to use this tool over alternatives or provide when-not conditions. Usage context is implied from 'backtest' but lacks explicit guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that the tool returns observations for one pair and is subscriber-only, but does not disclose data freshness, rate limits, or behavior on missing pairs. Some additional context is provided, but not extensive.

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 consists of two sentences, with the purpose stated first and no extraneous information. Every sentence is essential and efficiently communicates the tool's function and prerequisite.

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 4 parameters, an output schema (not shown), and annotations, the description covers the key points: what it returns and the prerequisite call. It could mention time parameter constraints or subscriber restrictions, but the output schema likely covers the return format. The description is adequate for the tool's simplicity.

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 descriptions for all 4 parameters. The description adds only that the tool works 'for one pair' and advises verification via fx_reference_universe. This adds minimal meaning beyond the schema, 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 returns 'subscriber intraday official FX reference-rate observations for one pair,' specifying the verb ('return') and the resource ('intraday official FX reference-rate observations'). It distinguishes from siblings by limiting to one pair and referencing fx_reference_universe for pair verification.

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 instructs to call fx_reference_universe first to verify pair and source availability, providing a clear prerequisite. It does not specify when not to use this tool or mention alternatives, but the context is clear.

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

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

Annotations already declare readOnlyHint true and destructiveHint false. Description adds that it lists sources and policies, which is consistent and provides additional behavioral context about output.

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?

Single sentence that is concise and front-loaded with key purpose and usage guidance. 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?

Given zero parameters, read-only annotation, and existence of output schema, description is complete: it explains what is returned and why it should be used.

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; schema coverage is 100%. Baseline score of 4 is appropriate as description need not add 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?

Description clearly states the tool lists public official FX reference-rate sources and their source policy, with specific verb 'List' and resource. It distinguishes from sibling fx_intraday_reference_rates by noting it should be used before requesting pair-specific rates.

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 to use 'before requesting a pair-specific intraday reference-rate series,' providing clear usage context. Does not mention alternative tools or when not to use, but context is sufficient.

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. Description adds that the universe is public and optional filters, but no behavioral traits 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?

Two sentences with no wasted words. Purpose and usage are 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?

For a simple list tool with output schema present, the description adequately covers purpose, filtering, and prerequisite. No missing elements.

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 descriptions for both parameters. The description echoes filtering options but does not add 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?

Clearly states the verb 'list' and the resource 'public FX reference-rate pair universe'. Distinguishes from siblings by being a prerequisite for 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?

Explicitly advises to call this before requesting an intraday reference-rate series, providing clear usage context. Does not mention when not to use or 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 indicate readOnlyHint=true and destructiveHint=false, reinforcing safe usage. The description adds behavioral details: the tool uses spot context, macro differentials, and optional COT positioning, and supports async execution. No contradiction with annotations.

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

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

Two concise sentences efficiently communicate purpose and async capability without redundancy. Every phrase adds 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?

All parameters are documented in the schema, but no output schema is provided. The description's phrase 'trader-oriented FX pair setup' is vague regarding return structure, which may force the agent to infer response format from the tool's name and context.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by mapping parameters to concepts like 'upcoming catalyst risk' (horizon_events) and 'COT positioning' (include_cot), helping the agent understand parameter intent beyond schema 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 clearly states the tool builds a 'trader-oriented FX pair setup' specifying components like spot context, macro differentials, catalyst risk, and COT positioning. This differentiates from sibling tools like fx_backtest_task or pair_intel_task, though it could be more explicit.

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

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

The description mentions async execution via MCP Tasks, which gives a usage context. However, it fails to specify when to prefer this tool over similar task tools (e.g., macro_briefing_task, pair_intel_task) or provide 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 and destructiveHint. The description adds that it combines multiple data types and supports async, which is helpful behavioral context without 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?

Two sentences, no fluff. First sentence front-loads the core purpose; second adds async support context. Every word is meaningful.

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?

Adequately describes the tool's output (intelligence pack) and components, but lacks details on return format (e.g., JSON structure, task ID for async). Since no output schema exists, more completeness would help.

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

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

Schema description coverage is 100%, so the schema already explains parameters. The description adds no additional insight into parameter values or constraints 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 specifies a clear verb ('build') and resource ('intelligence pack for one indicator'), with components listed ('chart-ready series data, derived analytics, nearest release timing context'). This distinguishes it from sibling tools like indicator_query (raw data) and indicator_visual_artifact (visuals).

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?

Mentions async execution via MCP Tasks, indicating a specific use case. However, it does not explicitly state when to prefer this tool over siblings (e.g., for comprehensive pack vs raw data), leaving some ambiguity.

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

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

Annotations already declare readOnlyHint and destructiveHint. The description adds that results are paginated, return raw rows with specific fields (date, val, announcement_datetime), and always remove prohibited private aggregator rows. This is helpful 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 well-structured and front-loaded with the core purpose. It is somewhat lengthy due to listing many indicators and parameters, but every sentence adds value. Slightly verbose but clear.

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 with 9 parameters, 100% schema coverage, no output schema but inline description, the description covers output structure, pagination fields, data source, authentication requirements, and prerequisite calls. It is highly complete.

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

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

Schema coverage is 100%, so the schema already documents each parameter. The description mentions the slug format and date bounds but adds little new meaning beyond what is in the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool returns a paginated historical time series of a single macroeconomic indicator for a currency from official sources. It lists many supported indicators and explicitly distinguishes from the sibling tool indicator_visual_artifact, which is for rendering charts.

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 advises calling data_catalogue first to get the exact slug, specifies when to use this tool (data workflows) versus indicator_visual_artifact (chart rendering), and notes that USD indicators are free while non-USD requires an API key.

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. Description adds valuable context about returning visual metadata for rendering and pagination behavior, 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?

Description is well-structured and front-loaded with purpose and usage. The list of supported currencies and indicators is lengthy but useful.

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

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

For a tool with 7 parameters and no output schema, the description provides comprehensive usage context, fallback conditions, and pagination hints. Minor lack of mention of any date range limits.

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 descriptions for all 7 parameters. The description adds pagination usage guidance beyond schema, though it repeats supported values also in 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's purpose: same payload as indicator_query but returns MCP Apps metadata for visual chart rendering. It distinguishes from the sibling tool indicator_query by specifying the visual output.

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: 'Prefer this by default for indicator time-series requests' for visualization tasks, and fallback to indicator_query for raw data requests. Also provides pagination best practices.

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 value by explaining the point-in-time logic (announcement_datetime boundary) and async task support, which are behavioral traits not captured in annotations. It does not mention pagination or auth, but for a read query this is adequate.

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 consists of two sentences, front-loaded with the core purpose. Every sentence adds value—the first defines the tool's primary action, the second adds async execution context. There is no waste 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?

The description covers the essential logic and async capability. However, without an output schema, it could briefly mention the return format (e.g., 'returns macro series data points with announcement_datetime <= as_of'). For a 5-parameter tool with 3 required, this is mostly complete but lacking output details.

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 and examples for all 5 parameters. The description does not add further parameter-level meaning beyond restating the cutoff logic. Baseline 3 is appropriate since the schema already 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 returns a 'slice of a macro series known at a specific timestamp' using announcement_datetime, distinguishing it from sibling tools like indicator_query which likely return current data. The specific verb 'return' and resource 'macro series slice' make the 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 explains the tool's function but does not explicitly state when to use it versus alternatives or when not to use it. It mentions async execution support but provides no context on preferred scenarios or exclusions, leaving usage inference to the agent.

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's 'latest stored' adds no new behavioral insight. The description is consistent with annotations but does not elaborate on openWorldHint behavior. Acceptable given 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 concise sentences with zero wasted words. It front-loads the purpose and ends with usage guidance, making it efficient and scannable.

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

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

Given the tool's simplicity (single parameter, read-only, output schema exists), the description fully covers what the agent needs: purpose, usage context, and prerequisite. No gaps are evident.

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

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

With 100% schema description coverage for the only parameter (currency), the schema already provides meaning. The tool description adds no extra parameter details, so baseline score 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 it returns the latest stored macroeconomic value for every indicator in one currency, specifying a verb, resource, and scope. It also distinguishes from siblings by referencing the prerequisite use of 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 recommends using this tool for a compact current macro snapshot after data_catalogue confirms currency coverage, providing clear when-to-use guidance. It does not mention when not to use or alternatives, but the context is well-defined.

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. Description adds batch context but no further behavioral details (e.g., no mention of rate limits, auth beyond subscriber).

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, no wasted text.

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

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

With output schema present and good annotations, description sufficiently covers the tool's purpose and scope for a no-parameter 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?

No parameters, schema coverage 100%, so baseline 3. Description adds no parameter info as none are 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?

Description clearly states action ('Return') and resource ('latest stored value for every available commodity indicator') and distinguishes from sibling 'commodities' by calling it the batch counterpart.

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?

Indicates it is a subscriber tool and the batch counterpart to 'commodities', implying use when all indicators are needed. Could be more explicit about when not to use (e.g., single indicator), but provides clear context.

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

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

Annotations already mark the tool as read-only and non-destructive. The description adds that it supports MCP Tasks for async execution, which is a key behavioral trait. However, it does not discuss performance implications or internal request behavior.

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

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

The description is a single sentence followed by a note about async support. It is front-loaded with the purpose but could be more structured. Every part is relevant, but there is minor room for tightening.

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 (combines multiple data sources) and absence of an output schema, the description should hint at what the briefing contains or how it is returned. It lists components but omits output format or structure, leaving a gap for a composite task.

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

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

Schema coverage is 100%, and the description repeats the schema's information about the currency parameter. No additional semantic value is added beyond specifying case-insensitivity and listing supported codes, which is already 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 states the tool's action ('Build a compact macro briefing'), the resource ('for a currency'), and the scope by listing the combined sources. It distinguishes itself from sibling tools that focus on individual data types.

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 is for generating a comprehensive briefing, but does not explicitly state when to use it versus alternatives (e.g., calling individual data tools or other composite tasks). No when-not-to guidance is provided.

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 and destructiveHint. The description adds that the returned factor includes optional component scores and source references, which is useful. However, it does not disclose pagination behavior (limit, offset) or what happens when no data matches, leaving some gaps 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?

Two succinct sentences that front-load the core purpose. No unnecessary words or repetition. Every sentence adds 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?

While the description covers key aspects, it lacks details about the return format (e.g., array of objects) and pagination behavior. Given the complexity of 8 parameters and no output schema, a more complete description would clarify these points.

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 meaning by mentioning 'optional stored component scores and source references' (mapping to include_components and include_sources) and specifying 'for one currency', clarifying the required currency and factor parameters beyond their schema 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 clearly states the tool returns a precomputed macro factor for one currency, using specific verbs and resource. It distinguishes from siblings by warning against using it as a substitute for inspecting underlying macro releases, implying a different use case from other macro 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 explicitly states when to use ('for a documented factor value') and when not to ('not as a substitute for inspecting its underlying macro releases'), providing clear context. However, it does not explicitly mention alternative tools like macro_heatmap_task or macro_regime_classifier_task for other factor-related needs.

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 value by specifying the output (matrix with latest values, changes, z-scores) and async execution support, which are not in annotations. No contradictions.

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

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

Two sentences front-loaded with the core purpose. The mention of MCP Tasks adds some extra detail but could be considered slightly extraneous. Overall 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 4 optional parameters and no output schema, the description explains the return format (matrix with values, changes, z-scores). It is sufficiently complete for an agent to understand what the tool does and what it returns.

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 descriptions and examples for all 4 parameters. The description does not add extra meaning beyond the schema, so 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?

Description clearly states the tool builds a cross-currency macro heatmap from indicator time series and returns a matrix with latest values, recent changes, and z-scores. This specific verb+resource combination distinguishes it from sibling tools like commodities, forex, and indicator_intel_task.

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

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

No explicit guidance on when to use this tool versus alternatives. The mention of MCP Tasks for async execution hints at a specific context, but there is no direct comparison or exclusion of other 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 indicate readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds that it returns 'official-source headline rows and lightweight keyword-derived affected_indicators and sentiment fields when a headline is classifiable.' This provides some behavioral detail beyond annotations but does not significantly expand on the annotation-provided traits.

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

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

The description consists of two concise sentences. The first sentence clearly states the purpose, and the second adds usage context. Every word serves a purpose without unnecessary elaboration.

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

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

With an output schema present, the description does not need to explain return values. It covers the tool's scope, currency list, and narrative contexts. The description is sufficient for an agent to understand when and how to use the tool.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description lists supported currencies again but does not add new meaning or usage details beyond what the schema provides. 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 'recent official central-bank news and press-release headlines for a currency.' It specifies the verb (return) and resource (news headlines), and lists supported currencies. This distinguishes it from sibling tools like commodities, forex, and 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 explicitly says 'Use this when a report needs headline context for central-bank policy, inflation, employment, GDP, trade, fiscal, energy, or commodity narratives.' It provides clear context for when to use the tool, though it does not explicitly state when not to use it or compare to 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 indicate readOnlyHint=true and destructiveHint=false. The description adds value by revealing that the tool uses specific macroeconomic data and provides assumptions and confidence notes, plus notes it supports async MCP Tasks.

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

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

Two sentences with no wasted words. The first sentence covers core purpose and inputs, and the second explains execution mode. Every sentence earns its place.

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

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

The tool has no output schema, so the description should clarify what the classification result looks like. It mentions assumptions and confidence notes but not the format or possible regime categories, leaving some ambiguity for the 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?

Input schema covers 100% of parameters with descriptions, setting a baseline of 3. The description does not add additional semantic meaning to the parameters beyond what is already 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?

Clearly states the tool classifies a currency's macro regime using policy rate, inflation, GDP, and unemployment, with explicit assumptions and confidence notes. This distinguishes it from sibling tools like macro_heatmap_task or indicator_intel_task by specifying the exact inputs and the nature of the output.

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

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

The description explains the functionality but provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, cases to avoid, or why one might choose this over similar classification tasks.

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

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint. The description adds context about the tool producing a 'persistent-host-friendly research payload' and supporting async execution, which is valuable 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 concise sentences deliver all critical information: the bundle contents, payload nature, and async support. No redundant or 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?

Given the tool has 6 parameters with complete schema descriptions and no output schema, the description adequately covers the bundled research components and async execution context. It could mention the return format, but the absence is not critical.

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

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

Schema description coverage is 100%, so the schema already thoroughly explains each parameter. The description adds minimal extra meaning beyond mentioning 'optional FX pair context', which corresponds to base/quote parameters. 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 bundles catalogue, indicator history, next release timing, and optional FX pair context into a research payload for async execution via MCP Tasks. It distinguishes from sibling tools by specifying the bundled nature and async 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?

The description implies usage for async research pack tasks but does not explicitly state when to use this tool versus alternative task tools (e.g., indicator_intel_task, macro_briefing_task). No when-not or alternative guidance is provided.

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 the behavioral detail that it supports MCP Tasks for async execution, which is not in annotations. This extra information is valuable for understanding how the tool can be invoked. No contradictions.

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 that front-load the core purpose: first sentence describes what it builds, second adds async capability. No redundant or filler content. Efficient and clear.

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 6 optional parameters and no output schema, the description gives a high-level overview but fails to specify the return format (e.g., JSON object with panels, messages, or visual artifact). It leaves the agent to infer what 'build a cockpit' means in terms of output. Lacks sufficient detail for complete understanding.

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 good parameter descriptions. The description adds context that the parameters configure the different panels (e.g., base/quote for pair context, currency for release queue, indicator for alerts, dates for range). This adds meaning beyond the individual schema 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 clearly states it builds a 'multi-panel macro market cockpit' combining specific components (FX sessions, release queue, pair context, risk alerts). This distinguishes it from sibling tools which focus on individual aspects, and the verb 'Build' combined with the resource description gives a specific purpose.

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 does not provide guidance on when to use this tool over siblings. It doesn't mention alternatives or scenarios where this aggregation is preferable to using individual tools like forex, release_calendar, etc. No contextual cues for usage decisions.

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 and destructiveHint=false, so safety is clear. The description adds valuable context about accounting for weekends and holidays, and explains the optional timestamp parameter for specific moments.

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

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

Two concise sentences with key information front-loaded. No wasted words; parameter explanation is integrated naturally.

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

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

Given the output schema exists and annotations are provided, the description covers purpose, usage, parameter details, and behavioral nuances (weekends/holidays). It is complete for an agent 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?

Schema coverage is 100% and both description and schema explain the 'at' parameter's purpose and format. The description adds context for its use case beyond the schema's 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?

Clearly states the tool tells which FX sessions are open and when next opens/closes. The verb 'tell' and resource 'FX trading sessions' are specific. It does not explicitly distinguish from the sibling 'forex' tool, but the purpose is distinct enough.

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 when-to-use guidance with example user questions. Does not mention when not to use or suggest alternatives, but covers common use cases well.

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's mention of 'Explain' confirms read-only behavior. The description adds little beyond annotations, but does not contradict them, earning a baseline score.

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: first states purpose, second provides usage guidance. No wasted words, front-loaded with the most important information.

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

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

Given the tool's simplicity (no parameters, no output schema, clear annotations), the description fully covers what the tool does and when to use it. No further information 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?

The tool has zero parameters, so the description does not need to add parameter information. Schema coverage is effectively 100% (empty schema), and the baseline for 0 parameters is 4.

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

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

The description clearly states the tool's purpose: explaining authentication modes for FXMacroData MCP across major clients and platforms. It uses a specific verb ('Explain') and resource ('authentication mode'), and distinguishes itself from sibling tools (which are data or task tools) by focusing on authentication 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?

The description explicitly says 'Use this when the user asks whether to use OAuth, an API key, a bearer token...' providing clear context for when to invoke the tool. While it doesn't include negative examples or alternatives, it is sufficient for a simple guide 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 provide readOnlyHint, openWorldHint, destructiveHint. The description adds value by detailing the scope of explanations (tools, public vs subscriber, etc.). No contradictions.

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

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

Two sentences with clear front-loading of purpose and usage guidance. Every sentence is essential and earns its place.

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

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

For a tool with no output schema and zero parameters, the description sufficiently covers the purpose and usage. It could optionally mention return format, but current completeness is adequate.

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, baseline 4. The description does not need to add parameter info as schema coverage is 100%.

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 that the tool explains the MCP server's capabilities, distinguishing it from sibling tools that perform specific tasks. It uses specific verb 'Explain' and resource 'MCP server capabilities'.

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 specifies when to use this tool: 'when a user asks what is available, why visuals are not showing, or how to get the same result in a different interface.' No alternatives are needed as it is a meta-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 safety profile is clear. The description adds useful behavioral context (metadata-first, grouped by endpoint type) and lists supported values, which aids understanding of the tool's behavior.

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

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

The description is two sentences plus a list of supported values, front-loaded with the primary purpose. Every sentence adds necessary context 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?

While the description covers the main selection logic, it does not mention the 'component' parameter, which is conditionally required for the bop dataset. The schema covers this, but for complete context, the description should note this dependency. Output schema exists, so return values are not required.

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%, giving a baseline of 3. The description adds value by explaining the role of endpoint_type and dataset in selecting the series family, and lists supported values, which goes beyond the schema's individual parameter 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 clearly states the tool's purpose (Get metadata-first official dataset payloads grouped by API endpoint type) with a specific verb and resource. It distinguishes itself from siblings by focusing on 'official dataset families' but does not explicitly contrast with any sibling tools.

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

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

The description explains how to use the tool by selecting endpoint_type and dataset, and lists supported values. However, it provides no guidance on when not to use this tool or mention of alternative tools for similar data retrieval (e.g., data_catalogue).

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 and destructiveHint=false. The description adds that it 'Supports MCP Tasks for async execution', which adds behavioral context beyond annotations. However, it does not fully disclose other behavioral aspects like data freshness 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, front-loaded with the core purpose. It is efficient but the second sentence about MCP Tasks could be considered non-essential for basic usage. Still, it's well-structured and not verbose.

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 lack of an output schema, the description should explain the output format or structure of the 'intelligence pack'. It does not, and it also does not clarify how the optional date parameters affect the result. This leaves significant gaps for the 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?

Schema coverage is 100% with clear descriptions for each parameter, including examples, types, and constraints. The description does not add supplementary meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states 'Build an intelligence pack for an FX pair' specifying the verb and resource. It mentions combining three contexts, which clarifies the tool's function. However, it does not explicitly differentiate it from sibling tools like macro_briefing_task or fx_trade_setup_task, which also build packs or intelligence.

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 lacks when-to-use, when-not-to-use, or references to sibling tools. The note about MCP Tasks is technical but not usage guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds quick health check context and reaffirms non-destructive nature. No contradictions.

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 purpose. Every sentence adds value; no filler.

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

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

Given zero parameters, annotations present, and output schema exists, the description fully covers the tool's role and usage 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?

No parameters; schema coverage is 100%. The description does not need to add param semantics. Baseline 4 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?

Clear verb 'Quick health check' specifies action, and 'confirms the FXMacroData API and MCP server are reachable' identifies the resource. Distinguishes from sibling tools by being a connectivity test.

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 'Use this only if other tools fail unexpectedly — it is not needed before normal calls.' Provides clear when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds value by confirming it only composes approved API surfaces and does not execute custom code, reinforcing safety and scope.

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 paragraphs, first defines purpose, second adds constraints and an example. No unnecessary words, front-loaded with key 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 19 parameters and no output schema, description covers scope, constraints, supported sources, and a usage example. Sufficient for an agent to determine when and how to invoke the tool.

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

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

Schema coverage is 100%, baseline 3. Description enhances with a concrete example showing how to combine announcements and predictions series, clarifying the series parameter's structure and purpose beyond schema 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?

Description clearly states verb 'Build' and resource 'generic MCP Apps chart', distinguishes from siblings by specifying use with FXMacroData endpoint families and providing an example combining announcements and predictions.

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

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

Explicitly states when to use ('arbitrary plot requests, multi-series charts, actual-vs-consensus views') and what it does not do ('never fetches arbitrary URLs or runs custom chart code'). Implicitly contrasts with single-series chart siblings but does not name them.

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 provide readOnlyHint, openWorldHint, and destructiveHint, so the safety profile is clear. The description adds only that it builds a chart, with no additional behavioral context (e.g., data latency, date range limits, or return format).

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 is front-loaded with the core action and result, with no wasteful 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?

While the tool is simple and annotations cover safety, the description lacks details about the output chart (e.g., series appearance, labeling) and any constraints on currency pairs or data availability. Given no output schema, some completeness is missing.

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

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

Schema coverage is 100%, with each parameter having a description. The tool description does not add extra semantics beyond the schema, meeting the baseline expectation.

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 for an FX pair. It uses a specific verb ('Build') and resource ('two-series chart'), and its purpose is distinct from sibling 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?

The description implies the use case (visualizing rate differential) but does not specify when to use this tool over siblings like forex_visual_artifact or cot_visual_artifact. No explicit when-to-use or when-not-to-use 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 indicate readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description aligns by stating it estimates directional impact and is a scenario assumption, not a guarantee. It adds context about async execution and non-forecast nature, enhancing transparency 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 two sentences, front-loaded with the core action and key qualifier (heuristic elasticity). Every part is purposeful, 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?

Given the tool's moderate complexity (8 parameters, no output schema), the description provides sufficient context: what the tool does, its async support, and the heuristic nature. It does not describe return values, but that is acceptable without output schema.

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

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

Schema coverage is 100% with descriptions for all 8 parameters. The description adds value by clarifying that elasticity_per_100bps is a heuristic assumption and that policy_shock_bps is an alias. This provides meaning beyond schema alone, though not extensive.

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 runs a policy-rate spread what-if scenario for an FX pair and estimates directional spot impact with a heuristic elasticity assumption. It distinguishes itself from siblings by specifying the scenario and elasticity approach, making the purpose specific and 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 explains the tool is for 'what-if' scenarios with an explicit elasticity heuristic, and mentions async execution support. While it implies comparison to other FX tools via sibling list, it lacks explicit 'when not to use' or named alternatives, reducing guidance slightly.

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 indicate readOnlyHint=true, openWorldHint=true, and destructiveHint=false, which the description complements by stating the tool analyzes risk and supports async tasks. It provides behavioral context beyond annotations (e.g., async execution), but does not detail what 'event-driven catalyst risk' entails or the output format.

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, front-loaded with purpose. Every sentence adds value. Highly concise for a tool with 3 parameters and no output schema.

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

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

Given no output schema, the description could mention the output format (e.g., 'returns a risk report'). It also lacks guidance on when to use this tool vs. similar sibling tasks. Adequate but incomplete.

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

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

Schema coverage is 100% with each parameter having a description and examples. The tool description does not add meaning beyond the schema; it only provides high-level context. Baseline 3 is appropriate as the schema already handles parameter semantics adequately.

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: 'Analyze a multi-position FX book for concentration, stress exposure, and event-driven catalyst risk.' The verb 'Analyze' and the specific resource 'multi-position FX book' precisely define its function, distinguishing it from sibling tools that handle data retrieval or other analyses.

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 mentions 'Supports MCP Tasks for async execution when clients send task-augmented requests,' which provides invocation context but does not explicitly guide when to use this tool over alternatives like fx_backtest_task or macro_briefing_task. No exclusions or comparative guidance is given.

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 confirm idempotent read-only behavior. The description adds value by specifying that the tool does not add derived sentiment or indicator classifications, and that it returns public data. No contradiction with annotations.

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

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

Two concise sentences: first states the purpose, second provides usage guidance. Every sentence earns its place with no unnecessary 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?

Given the presence of output schema, annotations, and 100% schema coverage, the description provides all necessary context: what the tool does, when to use it, and the nature of the output. No gaps identified.

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 adequate parameter descriptions. The description does not add additional information about parameters beyond what is in the schema, so 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 returns the public central-bank press-release archive for a currency, without added sentiment or indicator classifications. It distinguishes itself from the sibling tool macro_news by specifying that this tool provides original official release rows, not summaries.

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 tells when to use this tool (when original official release rows matter) versus the alternative macro_news (when headline summary is useful). This provides clear decision guidance for the agent.

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 description adds async execution context. However, it does not elaborate on the open world behavior (e.g., external API calls) or other side effects, leaving gaps 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 short (two sentences) and front-loaded with the main purpose. The second sentence adds value about async support. Every sentence earns its place, though it could be slightly more structured.

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

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

Given the tool has 9 parameters and no output schema, the description is too minimal. It fails to explain what the output looks like, the meaning of 'expanded quant-style', or how the returned data is structured, leaving the agent with insufficient context to use the tool effectively.

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 does not add any parameter-specific meaning beyond what is already in the schema, such as clarifying the shock or elasticity 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 clearly states it runs an expanded quant-style policy scenario for an FX pair, specifying deterministic projection, stress percentiles, and horizon assumptions. However, it does not explicitly distinguish from the similar sibling 'policy_scenario_modeler_task', so it loses the top score.

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 like 'policy_scenario_modeler_task' or 'fx_backtest_task'. The description fails to mention use cases, prerequisites, 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 and destructiveHint=false, so the description adds value by noting it is a subscriber data tool (implying access restrictions) and that it preserves endpoint metadata. This provides additional behavioral context 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 contains no unnecessary words. Every sentence adds 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 presence of an output schema, the description does not need to explain return values. It adequately covers the tool's purpose and subscriber data nature, but could briefly mention required authentication or rate limits.

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?

Input schema has 100% description coverage, so the baseline is 3. The description does not add new parameter-specific details beyond what the schema provides; it only summarizes the overall function.

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 official government-nominal curve nodes, slopes, or derived forward segments for one currency. It uses specific verbs ('Return') and resource types, differentiating it from sibling tools focused on other financial data 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 mentions it is a subscriber data tool but does not explicitly state when to use it versus alternatives or provide exclusion criteria. The context implies usage for government nominal curve data, but no direct comparison to siblings is made.

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

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint. The description adds minimal context ('stored or derived'), which implies possible computation but does not reveal further details like authentication 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?

Two concise sentences, front-loaded with the core action. No wasted words; structure is efficient and clear.

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 11 parameters, an output schema, and full schema coverage, the description is minimally complete. It hints at return fields but could better summarize the tool's role relative to its many parameters.

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 does not add meaning beyond schema; it mentions using returned metadata but does not clarify parameter roles or relationships.

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 it returns the stored or derived rate differential for one FX pair, using a specific verb and resource. However, it does not distinguish from sibling tools like `policy_rate_differential_visual_artifact`, which may overlap.

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

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

No guidance on when to use this tool versus alternatives (e.g., `policy_rate_differential_visual_artifact`). The description only hints at post-use behavior (explaining result) but lacks context for selection.

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

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

Annotations declare readOnlyHint=true, destructiveHint=false. The description adds behavioral details: returns ISO-8601 datetimes, market-local timestamps, optional timezone conversion, and the constraint that unbounded calls return only future releases. 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 well-structured with a clear purpose first, followed by usage guidelines and parameter details. However, it includes a lengthy list of supported currencies and indicators that are already present in the schema, which adds redundancy and reduces conciseness. While functional, it could be more streamlined.

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 parameters, no output schema, and annotations, the description covers the return format (ISO-8601 datetimes, row structure with release and currency), behavioral constraints (future-only), and parameter usage. It does not mention pagination or rate limits, but the openWorldHint annotation suggests possibly unbounded results, and the description addresses this with 'Unbounded calls return future releases only'. Overall, fairly complete for a read-only list tool.

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

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

Schema description coverage is 100%. The description adds value beyond the schema by providing usage context: e.g., 'Pass `start_date` and `end_date` bounds when the user mentions a month, week, day, or explicit date range' and 'Pass `timezone` for an additional `announcement_datetime_requested_timezone` field'. This enhances understanding of 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?

The description clearly states 'Get upcoming scheduled macroeconomic release timestamps for a currency' and gives specific use cases like 'when the user asks when is the next CPI/GDP/payrolls/policy decision'. It distinguishes from sibling tools like release_calendar_visual_artifact by mentioning that consumer-facing clients should render the resource, implying this tool returns data, not visuals.

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 and provides guidance on parameters like start_date and end_date. It also says 'Unbounded calls return future releases only; do not show stale past rows unless the user explicitly asks for historical/past calendar data'. However, it does not explicitly mention when not to use this tool or compare with alternatives like indicator_query or macro_briefing_task.

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

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

The description repeats that it has the same payload as release_calendar, hinting at non-destructive read-only behavior, which aligns with annotations (readOnlyHint=true, destructiveHint=false). However, it does not disclose additional behavioral traits beyond what annotations already provide, such as rate limits or specific output format.

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 well-structured and front-loaded with the core purpose. It then provides usage guidelines and parameter tips. However, it repeats the full lists of currencies and indicators which are already in the schema, making it longer than necessary.

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 (5 parameters, all documented, read-only annotations), the description covers the purpose, usage, parameter guidance, and hints at output (visual artifact inline). It could be more explicit about the return type, but overall it is adequately complete.

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

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

Schema coverage is 100% and each parameter has a description. The description adds value by providing context on when to use each parameter (e.g., 'when the user names a specific series' for indicator, 'when the user asks for local times' for timezone). This goes beyond the schema's basic 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 clearly states the tool's purpose: it is a visual artifact version of release_calendar with the same payload. It distinguishes itself from the sibling release_calendar explicitly by noting it is for visual rendering in compatible apps.

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 guidance on when to use this tool over release_calendar (when user asks to show/display/visualize) and when to prefer the plain version (raw table/JSON). Also advises when to pass optional parameters like indicator, dates, timezone.

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 that the tool uses heuristics and supports async execution, which are useful beyond the structured annotations. No contradictions.

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: first defines the core purpose, second explains the async capability. No filler, front-loaded, and every word adds 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 no output schema, the description omits what the 'score' looks like (e.g., value range, format). For a task tool, this is a notable gap. Otherwise adequate for a simple read operation.

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

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

Schema coverage is 100%, with each parameter well-described via description and examples. The tool-level description does not add extra parameter details, so it meets the baseline of 3.

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

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

The description clearly states the tool 'scores upcoming releases for a currency pair' using specific methods (release-calendar proximity and indicator-level heuristics). This distinguishes it from sibling tools like release_calendar which lists events rather than scoring risk.

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 mentions async execution via MCP Tasks but provides no guidance on when to use this tool versus alternatives like event_impact_replay_task or macro_briefing_task. An agent would need to infer usage from the name alone.

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

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

Annotations already declare readOnlyHint and destructiveHint. The description adds details on output components (composite score, regime label, pagination, data quality), which provides useful behavioral context beyond annotations and does not contradict 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 with two sentences that front-load the core purpose and immediately follow with usage guidance. Every sentence adds value 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's simplicity (two optional date params, output schema exists), the description adequately covers purpose, usage context, and key output components. It is sufficiently complete 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?

Schema description coverage is 100% for both parameters. The tool description does not add any parameter-specific information beyond what the schema already provides, so it meets the baseline expectation.

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/off sentiment series for FX regime analysis, including specific output components. It also differentiates from siblings by specifying its use as a precursor to classification of FX conditions.

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 advises using this tool for cross-asset regime context before classifying certain FX conditions. While it lacks explicit 'when not to use' guidance, the context is clear enough to guide selection.

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

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

Annotations (readOnlyHint=true, destructiveHint=false) already indicate safe, non-destructive behavior. The description adds transparency by detailing the return fields (e.g., monthly average, median return, win rate, sample size), providing full context 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 concise at two sentences, front-loading the purpose and usage. It is well-structured but could be slightly more scannable, e.g., using bullet points for output 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 moderate complexity, the presence of an output schema (indicated true) reduces the need to detail returns. The description covers inputs and outputs adequately, though it lacks examples of parameter combinations.

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 baseline is 3. The description does not add new parameter semantics beyond what the schema provides; it only lists output data. Hence, no extra value for 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 clearly states the tool retrieves monthly return seasonality for FX pairs or XAU/USD. It lists specific use cases like seasonal patterns, month-of-year tendency, and historical win rate, which distinguishes it from sibling tools that likely provide other analytics.

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 advises usage when the user asks for seasonal patterns, month-of-year tendency, or gold seasonality. It does not, however, mention when to avoid this tool or suggest alternatives like other forecast tools, which would strengthen guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the non-destructive and navigational aspects. The description adds that it returns a checkout path, but does not elaborate on authentication requirements or potential side effects (e.g., opening an external site). The description adds marginal 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 two sentences, front-loaded with the action, and contains no unnecessary words. Every word serves a 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?

The tool is simple with no parameters, and the description covers its purpose and return value. It could mention if a user session is required or if the checkout path opens in a new window, but for a basic subscription access tool, it 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?

The tool has zero parameters, and schema coverage is 100% (no parameters to document). According to rubric, 0 params = baseline 4. The description does not need to add parameter information.

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 action ('Open subscription options') and its trigger condition ('when a user needs to unlock MCP app visuals, charts, and advanced analytical tools'). It also specifies the outcome ('Returns a direct checkout path'). This distinguishes it from the sibling tools, which are focused on data retrieval and analysis rather than subscription management.

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 describes when to use this tool: when a user needs to unlock premium features. It implies that for free features, other sibling tools (e.g., indicator_query) would be used. However, it does not provide explicit exclusions or a list of alternatives.

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