FXMacroData

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

Annotations already provide readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering safety and scope. The description adds minimal behavioral context beyond this, only listing supported indicators. It doesn't disclose rate limits, authentication needs, or data freshness. With annotations doing heavy lifting, the description adds some value but lacks rich behavioral details.

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 extremely concise with two sentences that directly state the tool's function and supported indicators. It is front-loaded with the main purpose and wastes no words. Every sentence earns its place by providing essential information without redundancy.

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

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

Given the tool's moderate complexity (3 parameters, 1 required), annotations cover safety/scope, and an output schema exists (so return values needn't be explained), the description is reasonably complete. It clarifies the indicator parameter but misses date parameter details. For a read-only data retrieval tool with good annotations, it's mostly adequate but could be more thorough on 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 description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'Supported indicators: gold, platinum, silver', which clarifies the 'indicator' parameter semantics. However, it doesn't explain 'start_date' or 'end_date' parameters, their formats, or default behaviors. It partially compensates for the coverage gap but leaves key parameters undocumented.

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 commodity and energy indicator time series' specifies the verb (get) and resource (time series data). It distinguishes from some siblings by focusing on commodities/energy (vs. forex, market_sessions), though not explicitly compared. However, it doesn't fully differentiate from indicator_query which might 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?

The description implies usage by listing supported indicators (gold, platinum, silver), suggesting when to use this tool for those specific commodities. However, it provides no explicit guidance on when to choose this over alternatives like indicator_query or forex, nor any prerequisites or exclusions. Usage context is implied but not clearly articulated.

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?

Description adds value beyond annotations by clarifying the output is a visual artifact for rendering, and readOnlyHint is respected. No contradiction.

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

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

Single sentence, efficient, front-loads the key point (same payload, adds chart metadata). No superfluous content.

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

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

Adequately describes the tool's purpose and output format given the full schema and annotations. Could mention exact return type (e.g., URI, image) but not essential.

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 already provides 100% description coverage for parameters. Description adds no additional parameter info beyond referencing 'commodities' payload.

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 returns the same payload as 'commodities' but with chart metadata for inline rendering. Effectively distinguishes from sibling 'commodities' tool.

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

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

Implies usage when a visual chart is desired and a compatible client is available, but does not explicitly state when to use 'commodities' instead or mention any prerequisites.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, covering safety and scope. The description adds useful context about weekly data frequency and currency support, but does not disclose additional behavioral traits like rate limits, authentication needs, or data format. No contradiction with annotations exists.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by essential details in the second. Every sentence earns its place by specifying data type, scope, and constraints without redundancy. It is appropriately sized and efficiently structured.

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

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

Given the tool's moderate complexity (3 parameters, 1 required), annotations cover safety/scope, and an output schema exists, the description is mostly complete. It explains the tool's purpose and currency constraints well, but could improve by addressing date parameters or data format. The output schema reduces the need for return value 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 description coverage is 0%, so the description must compensate. It explains the 'currency' parameter by listing supported values (AUD, CAD, etc.), but does not address 'start_date' or 'end_date' parameters. This partial coverage meets the baseline for low schema coverage, as it adds some meaning but leaves gaps.

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

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

The description clearly states the specific action ('Get CFTC Commitment of Traders (COT) weekly positioning data'), identifies the resource ('currency's FX futures contract'), and distinguishes from siblings by specifying the exact data type (COT reports) and supported currencies. It avoids tautology by providing concrete details beyond the name/title.

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 context by listing supported currencies, but does not explicitly state when to use this tool versus alternatives (e.g., other data tools like 'forex' or 'commodities'). It provides some guidance on scope but lacks explicit when/when-not instructions or named 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. Description adds that it charts a specific field and returns chart metadata, which is consistent and minimally enhances 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?

Two sentences, front-loaded with key info (relationship to cot_data, default behavior, metric override). No redundant phrases; 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?

Despite no output schema and 4 parameters, the description effectively covers purpose and default behavior. It references cot_data for payload details, mitigating need for exhaustive explanation. Could detail what 'MCP Apps chart metadata' means but sufficient for selection and invocation.

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

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

Schema coverage is 100%, so baseline is 3. The description explains the default metric and its effect ('by default it charts noncommercial net positioning; pass metric to chart another COT field'), adding modest value beyond schema descriptions for other 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?

Description clearly states it provides a visual artifact (chart metadata) for COT data, identical payload to cot_data but with charting. It specifies default field (noncommercial net) and how to change it via metric. Differentiates from cot_data by 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?

Implies use when wanting a chart of COT data; explicitly mentions passing metric to change field. References cot_data as same-payload alternative but doesn't explicitly state when not to use or list other alternatives. Lacks explicit exclusions.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, covering safety and scope. The description adds value by specifying the supported currencies, which provides operational context beyond annotations. However, it doesn't disclose additional behavioral traits like rate limits, error handling, or response format, keeping the score at baseline with annotations present.

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, efficient sentence that front-loads the core purpose and follows with essential details (supported currencies). Every word earns its place with no redundancy or fluff, making it highly concise and well-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's low complexity (1 parameter), rich annotations (covering safety and scope), and the presence of an output schema (which handles return values), the description is reasonably complete. It specifies the tool's purpose and supported currencies, addressing key contextual gaps. However, it could improve by clarifying differentiation from siblings or adding minor usage nuances.

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

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

The input schema has 1 parameter with 0% description coverage, so the schema provides minimal semantic information. The description compensates by listing supported currency values (e.g., AUD, USD), which adds meaning to the 'currency' parameter. However, it doesn't fully detail parameter usage or constraints, resulting in an adequate but not comprehensive score.

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 available macroeconomic indicators for a currency.' It specifies the verb ('Get') and resource ('macroeconomic indicators') with a clear scope ('for a currency'). However, it doesn't explicitly differentiate from sibling tools like 'indicator_query' or 'forex', which prevents a perfect 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?

The description provides some usage context by listing supported currencies, which implies when to use it (for those currencies). However, it doesn't explicitly state when to use this tool versus alternatives like 'indicator_query' or 'forex', nor does it mention prerequisites or exclusions. The guidance is implied rather than explicit.

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

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

Annotations already indicate read-only, non-destructive, and closed-world behavior. The description adds value by specifying supported currencies and indicators, which provides context on data availability and optional features, though it doesn't detail rate limits or authentication needs.

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

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

The description is front-loaded with the core purpose and efficiently lists supported currencies and indicators. It could be slightly more structured, but every sentence adds value without redundancy, making it appropriately concise.

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

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

Given the tool's moderate complexity, annotations covering safety, and an output schema, the description is mostly complete. It covers key inputs and optional features, though it could benefit from more usage context or error handling 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 description coverage is 0%, but the description compensates by explaining the 'indicators' parameter with supported values and format. However, it doesn't clarify 'base' and 'quote' beyond listing currencies, or explain date parameters, leaving some semantic gaps.

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

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

The description clearly states the tool's purpose with specific verbs ('Get FX spot rates') and resources ('currency pair'), and distinguishes it from siblings by mentioning technical indicators. It explicitly lists supported currencies and indicators, making the scope unambiguous.

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

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

The description implies usage by specifying supported currencies and indicators, but does not explicitly state when to use this tool versus alternatives like 'commodities' or 'indicator_query'. No exclusions or clear alternatives are provided, 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 mark readOnlyHint=true. The description adds that output includes chart metadata for inline rendering, which is valuable beyond annotations. No contradictions or missing behavioral traits noted.

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 explains behavior, second gives usage guidance. No unnecessary text, 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?

Despite no output schema, the description explains the return format (chart metadata). It assumes familiarity with sibling 'forex' tool, which is reasonable given the server context. Lacks details about MCP Apps compatibility but sufficient for an agent.

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

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

Schema coverage is 100%, so baseline is 3. The description adds no additional parameter context beyond what the schema provides, so score remains 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 returns a visual artifact for forex spot rates, distinct from the raw data tool 'forex'. It specifies the purpose as plotting/visualizing a currency pair, making it 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?

Explicitly tells when to use: 'when the user asks to plot or visualize a currency pair.' This implies when not to use (raw data queries), though it could be more explicit about alternatives.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the agent knows this is a safe, read-only operation with limited scope. The description adds context by listing supported currencies and indicators, which helps set expectations about available data. However, it doesn't disclose rate limits, authentication needs, or data freshness, which would be valuable behavioral context 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 poorly structured and excessively long due to the massive list of indicators. The core purpose is buried in a single sentence followed by overwhelming detail. While the lists are necessary for parameter guidance, they make the description difficult to parse and not front-loaded effectively.

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 (4 parameters, comprehensive indicator list) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the core functionality and parameter constraints well. The main gap is lack of usage guidance relative to sibling tools, but overall it provides sufficient context for effective use.

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 0% schema description coverage, the description compensates well by providing comprehensive lists of supported values for 'currency' and 'indicator' parameters. This adds significant meaning beyond the bare schema. However, it doesn't explain the optional 'start_date' and 'end_date' parameters or their format, leaving some parameter semantics undocumented.

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 macroeconomic indicator time series for a currency.' It specifies the verb ('Get') and resource ('macroeconomic indicator time series'), and distinguishes it from siblings like 'commodities' or 'forex' by focusing on economic indicators. However, it doesn't explicitly differentiate from 'indicator_visual_artifact' which might provide similar data in visual form.

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 guidance on when to use this tool versus alternatives. It lists supported currencies and indicators but doesn't mention when to choose this over 'data_catalogue' for metadata, 'release_calendar' for upcoming data, or 'indicator_visual_artifact' for visualizations. Usage is implied through the parameter lists but not explicitly stated.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the agent knows this is a safe, non-destructive read operation with limited scope. The description adds value by specifying the intended output format ('interactive chart artifact') and listing supported currencies and indicators, which provides useful context beyond what annotations convey about 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?

The description is poorly structured with a massive, unformatted list of indicators that makes it difficult to parse. While the first sentence is clear and front-loaded, the lengthy indicator list (over 100 items) is excessive and doesn't earn its place in the description when a reference to available indicators would be more appropriate. This violates the principle that every sentence should earn its place.

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

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

Given the tool's complexity (4 parameters, no output schema, 0% schema coverage), the description is incomplete. While it covers the required parameters well with extensive lists, it completely ignores the optional date parameters. The description doesn't explain what the tool returns (beyond mentioning 'interactive chart artifact'), nor does it address potential limitations, error conditions, or data freshness considerations.

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 0% schema description coverage, the description carries the full burden of parameter documentation. It provides extensive lists of supported currencies and indicators, which directly correspond to the 'currency' and 'indicator' required parameters. However, it doesn't mention the optional 'start_date' and 'end_date' parameters at all, leaving them completely undocumented.

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 indicator time series data with MCP Apps metadata so compatible clients can render an interactive chart artifact.' This specifies the verb ('Get'), resource ('indicator time series data'), and intended outcome ('render an interactive chart artifact'). It distinguishes this tool from sibling 'indicator_query' by emphasizing the visual artifact generation 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?

The description implies usage context by listing supported currencies and indicators, suggesting this tool should be used when those specific data types are needed. However, it doesn't explicitly state when to use this tool versus the sibling 'indicator_query' tool, nor does it provide clear exclusion criteria or alternative recommendations for different scenarios.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's main addition is the async execution capability. This provides useful behavioral context beyond annotations, though it could disclose more about the briefing generation process.

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 core purpose, second adds context about async support. No wasted words, front-loaded with the primary action.

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

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

The tool has no output schema, and the description does not hint at the format or structure of the returned briefing. While the tool is relatively simple with one parameter, the absence of output details reduces completeness.

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

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

The input schema has 100% coverage with a detailed description of the currency parameter and supported codes. The description adds little extra meaning beyond stating the tool combines data types, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool builds a compact macro briefing for a currency by combining multiple data types (catalogue, policy rate, GDP, release-calendar). It distinguishes from sibling tools that focus on individual data types 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 async execution via MCP Tasks but does not provide guidance on when to use this tool versus the more specific sibling tools (e.g., when only one data type is needed). No explicit when-not-to-use or alternatives are 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?

The annotations already declare this is a read-only, non-destructive, closed-world operation. The description adds useful context about what information is returned (timetable, overlap windows) and the optional timestamp parameter functionality. However, it doesn't provide additional behavioral details like rate limits, authentication requirements, or specific format of returned data beyond what annotations cover.

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 perfectly concise - a single sentence that front-loads the primary functionality and includes the parameter option. Every word earns its place with no redundancy or unnecessary elaboration. The structure efficiently communicates both the default behavior and optional parameter usage.

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, comprehensive annotations (readOnlyHint, openWorldHint, destructiveHint), and the existence of an output schema, the description provides sufficient context. It explains what the tool returns and how to use the optional parameter. The output schema will handle return value details, so the description appropriately focuses on purpose and usage.

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 0% schema description coverage for the single parameter 'at', the description compensates well by explaining its purpose: 'request a snapshot for a specific UTC timestamp.' This clarifies that the parameter is optional (implied by 'or') and specifies the expected format (UTC timestamp). The description effectively adds meaning beyond the bare 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 with specific verbs ('Get', 'request') and resources ('FX market-session timetable', 'overlap windows', 'snapshot for a specific UTC timestamp'). It distinguishes itself from sibling tools like 'forex' or 'commodities' by focusing specifically on market session timing rather than price data or other financial information.

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

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

The description provides clear context for when to use this tool - to obtain market session timetables and overlap windows. It implicitly suggests using the 'at' parameter for historical snapshots versus current data. However, it doesn't explicitly state when NOT to use this tool or name specific alternatives among the sibling tools for 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 this as read-only, non-destructive, and closed-world, covering key behavioral traits. The description adds valuable context about what's being verified (both API and server reachability), which isn't captured in annotations. No contradiction exists between the description and annotations.

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

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

The description is a single, efficient sentence that immediately communicates the tool's purpose without any redundant information. Every word contributes to understanding, and it's perfectly front-loaded with the core functionality.

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, read-only operation), the presence of comprehensive annotations, and an output schema, the description provides exactly what's needed. It explains the purpose clearly without needing to cover behavioral details already in structured fields or return values handled by the output schema.

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

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

With zero parameters and 100% schema description coverage, the schema fully documents the input requirements. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose. A baseline of 4 is appropriate for parameterless tools when the schema is complete.

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 specific verb ('verify') and resource ('FXMacroData API and MCP server'), distinguishing it from sibling tools like data retrieval or analysis functions. It precisely communicates the tool's role as a connectivity check rather than data processing.

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 implicitly provides usage context by stating it verifies reachability, suggesting it should be used to test connectivity before attempting data operations. However, it doesn't explicitly mention when NOT to use it or name alternative diagnostic tools, which prevents a perfect score.

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

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

Annotations already declare readOnlyHint=true, so the description adds no extra behavioral context. It correctly implies no destructive action but does not disclose details like data source or chart 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?

One sentence with 18 words, front-loaded with action, no unnecessary text. 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?

Given the complexity (4 params, no output schema) and annotations, the description is adequate but lacks guidance on output format or when to choose this over sibling tools.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema, only linking base/quote to the chart concept.

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 policy-rate histories for an FX pair, using specific verbs and resources. It distinguishes from sibling tools by focusing on policy rate differentials.

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 visualizing policy rate differentials but does not explicitly state when to use this tool versus alternatives like forex_visual_artifact or indicator_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 already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering safety and scope. The description adds no behavioral context beyond the supported values list—no mention of rate limits, authentication needs, or data freshness. With annotations providing basic safety info, this earns a baseline score for minimal added value.

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 poorly structured: it starts with a clear purpose but devolves into a massive, unformatted list of currencies and indicators. This overwhelms the agent with raw data that could be better handled via enums or external documentation, reducing readability and efficiency.

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 (2 parameters, one optional), annotations cover safety, and an output schema exists, the description is minimally complete. It defines the purpose and valid inputs but lacks usage context, error handling, or output examples, leaving gaps that could hinder effective tool selection.

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

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

Schema description coverage is 0%, so the schema provides no parameter details. The description compensates by listing all supported currencies and indicators, which clarifies valid inputs for both parameters. However, it doesn't explain parameter interactions or formatting, keeping it at a baseline level of adequacy.

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 upcoming release dates for a currency and optional indicator.' It specifies the verb ('Get') and resource ('upcoming release dates'), though it doesn't explicitly differentiate from sibling tools like 'indicator_query' or 'forex', which prevents a perfect 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?

The description provides no guidance on when to use this tool versus alternatives. It lists supported currencies and indicators but doesn't explain context, prerequisites, or how it differs from sibling tools like 'indicator_query' or 'data_catalogue', leaving the agent to guess based on tool names alone.

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