Market Intel MCP

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

With no annotations, the description must carry behavioral disclosure on its own. It does state the rate source (ECB reference rate) and the return payload (rate, converted result, rate date), which is good. But it omits potential nuances such as ECB rate lag or business-day staleness, and does not explicitly confirm the operation is read-only.

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

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

A single sentence leads with the action and resource, then summarizes the output. Every word carries information; there is no repetition of the tool name or schema descriptions.

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, and the description covers the core operation and return fields, which partially compensates for the missing output schema. However, it leaves out edge cases like unsupported currency codes, rate availability timing, or how 'latest' relates to ECB publication dates. These gaps are notable when no annotations or output schema exist.

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

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

Schema description coverage is 100%, so all three parameters (amount, from, to) are already documented in the input schema. The description adds no parameter-level meaning beyond the schema, so the 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 uses a specific verb ('Convert'), identifies the exact resource (amount between currencies), and names the data source ('latest ECB reference rate'). This clearly differentiates it from siblings like fx_historical and fx_timeseries, which serve different time-range purposes.

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 intended use is implied by the verb and resource: convert an amount at the current or latest rate. However, it does not explicitly tell the agent when to choose this over fx_historical, fx_rates, or fx_timeseries, and provides no '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?

With no annotations, the description carries the full behavioral burden. The simple read-only nature is clear from 'List', and the description adds that it returns full names, which is useful behavioral detail. For a simple listing operation, this is adequate transparency; it doesn't hide side effects or require prerequisite knowledge.

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

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

The description is a single, front-loaded sentence that states the purpose and a key output detail with no wasted words. Every element 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 is a simple zero-parameter list operation. The description explains what is returned (currencies and their full names), the output schema provides structure, and there are no prerequisites or edge cases to mention. Nothing an agent needs to invoke it correctly is missing.

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

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

The tool has zero parameters, so the description cannot add parameter meaning. The baseline of 4 applies because there are no parameters to document, and nothing is missing.

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

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

The description uses a specific verb ('List'), names a clear resource ('currencies supported for exchange-rate lookups'), and specifies the output includes full names. This clearly distinguishes it from sibling tools like fx_convert, fx_historical, fx_rates, and fx_timeseries, which all perform operations on rates rather than listing supported currencies.

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: this tool is for discovering which currencies are available for exchange-rate lookups. It doesn't explicitly name alternatives or exclusions, but the context is sufficient for an agent to understand when to call it versus the rate-operation siblings.

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

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

There are no annotations, so the description carries the behavioral disclosure burden. It explains the ECB source, the business-day publication model, and the fallback behavior for weekend/holiday dates. This is meaningful non-obvious behavior that helps an agent interpret results correctly. It could mention whether missing symbols returns all rates, but the output schema mitigates that gap.

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

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

Two sentences, no filler, and the essential action is front-loaded. The second sentence earns its place by disclosing the most important behavioral nuance. Nothing needs to be trimmed or reordered.

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 three-parameter tool with full schema coverage and an output schema, the description is close to complete. It states the date restriction, the base-currency concept, and the holiday fallback that could otherwise confuse an agent. The only missing piece is explicit routing among sibling tools, but that is not necessary for correct invocation.

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

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

Schema coverage is 100%, so the schema already documents base, date, and symbols. The description adds extra semantic value for the date parameter by specifying 'past date' and explaining weekend/holiday fallback. It does not add much for base or symbols, but the schema already covers those, so the description's added date semantics justify a slightly above-baseline 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 names a specific action (get foreign-exchange rates), a resource (base currency on a specific past date), and clearly distinguishes this single-date tool from historical ranges or conversions. The phrase 'specific past date' immediately signals the tool's scope without requiring the agent to inspect 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 clearly implies when to use this tool: for a single historical date rather than a range or current rates. It also provides important operational context about business-day publishing and weekend/holiday fallback. It does not explicitly name alternatives or state 'use fx_rates for current rates,' but the context is strong enough for an agent to select it correctly.

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?

No annotations are provided, so the description must carry the behavioral burden. It does state the operation is a 'get' and cites the European Central Bank as the data source, which signals a read-only, authoritative feed. However, it does not disclose details like update frequency, latency, or real-time versus reference-rate 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 compact sentences with no redundancy. The main action and resource are front-loaded, and the source attribution is relegated to the second sentence, making it easy to parse.

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

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

For a simple two-parameter rate retrieval tool with both parameters optional and an output schema present, the description covers the purpose, scope, and data source sufficiently. It could add a brief pointer to sibling tools for historical data, but it is not necessary for a correct call.

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 parameters are already fully documented. The description repeats the default USD and optional target-currency limitation without adding new meaning beyond what the schema provides.

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

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

The description clearly identifies the action ('Get the latest foreign-exchange rates') and the resource ('for a base currency'), and it signals current rather than historical data, distinguishing it from fx_historical and fx_timeseries. It also contrasts with fx_convert by focusing on rates rather than conversions.

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

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

The description gives clear context: call when you need the latest ECB reference rates for a base currency, optionally restricted to specific targets. It does not explicitly name sibling tools or say when not to use it, but 'latest' and the ECB source imply the scope 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It discloses the approximate one-year range limit and implies a series of exchange rates, but it does not cover other behavioral details such as output structure, rate limits, or handling of invalid date ranges. This is adequate but not rich.

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

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

The description is a single, front-loaded sentence that communicates the tool's purpose, its primary use case, the date range limit, and the input requirements without any filler or redundancy. Every part 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 simple read-only tool with fully documented parameters, the description covers the core operational details: purpose, date range, input formats, and target currencies. There is no output schema, so the response shape is not specified, but the phrase 'time series' gives a reasonable expectation of the return concept.

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 reinforces that start and end are YYYY-MM-DD and that one or more target currencies are needed, but it does not add meaning beyond what the input schema already documents, such as the comma-separated format or the default base currency.

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

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

The description clearly states a specific action: retrieving a time series of exchange rates for a base currency over a date range. It also adds the use case of trend analysis, which helps distinguish it from a simple conversion or currency-list tool, though it does not explicitly contrast with the similarly named fx_historical or fx_rates siblings.

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

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

The description gives clear context for when to use the tool: for trend analysis over a date range of roughly up to one year. It does not explicitly mention alternatives or exclusions, but the stated use case is sufficient for an agent to select it appropriately in most situations.

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