Canada FX & Policy Rates MCP

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

With no annotations at all, the description carries the full burden, but it does disclose genuinely useful behavior: the rate is the 'latest BoC daily average', telling the agent the data source and that quotes are daily-averaged rather than live. It says nothing about auth requirements despite an access_token parameter, nor about error behavior for unsupported currencies.

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 with no waste, front-loading the verb and the CAD/BoC constraint. The 'PRO.' tag is cryptic but compact; the sentence earns its place.

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

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

For a 4-parameter tool with no annotations and no output schema, the description should say what comes back (converted amount and/or rate) and how access_token affects the call. Neither is covered, leaving the agent to guess at the response shape and auth path.

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 only 25% (just access_token), so the description must compensate. It does clarify the amount and that one leg must be CAD, but it never explains that 'from'/'to' are currency codes, what format they take, or whether CAD may appear in either position.

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

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

States a specific verb (convert), the resource (an amount between CAD and another currency), and the rate source (BoC daily average). The CAD/BoC scoping implicitly separates it from the ECB and 'global_fx' siblings, though no sibling is named explicitly.

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 is given; the CAD + BoC scope only implies that this is the domestic option versus global_fx_convert or ecb_reference_rates. The 'PRO' prefix hints at a paid tier but never states prerequisites for choosing this tool.

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

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

With no annotations, the description carries the load well: it discloses the paid x402 cost per call, the data source, the publication timing (~16:00 CET after the 14:10 concertation), and hard limits (20 currencies, 1-30 business days). It does not cover error behavior or whether non-business days are skipped, which keeps it below a 5.

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 dense sentence with the pricing signal front-loaded and no filler. Every clause (cost, source, timing, limits) earns its place, though the parenthetical timing detail adds some reading weight.

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 annotations and no output schema, the description covers source, freshness, cost, and input bounds, but says nothing about the shape of the returned data or how rates are keyed by date/currency, leaving the agent to guess the response format.

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 only 33% (only access_token is documented inline), so the description must compensate — and it does, supplying the valid range for days (1-30 business days) and the cap on currencies (20), while the schema covers access_token. Remaining gap is the expected currency code format (ISO 4217?).

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

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

States a specific resource: official ECB euro reference rates from the ECB Data Portal, with a concrete scope of up to 20 currencies over 1-30 business days. It is distinguishable from generic siblings like fx_rate or convert, though it never names those alternatives explicitly.

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 pricing note ('PRO ($0.01/call via x402)') and the 'official ECB' framing imply when to reach for this tool, but there is no explicit when-to-use or when-not guidance and no mention of how it differs from fx_rate, fx_table, or global_fx_rate.

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 burden. It does useful work: it discloses the cost model ('FREE'), the quote base (vs CAD), and the cadence (daily average, not intraday/real-time). It says nothing about failure modes for unsupported currencies or what metadata accompanies the rate, which is a real gap for a zero-annotation tool.

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

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

Two short sentences, both front-loaded with the information that matters — cost/freshness first, input contract second. No filler, nothing buried.

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 single-parameter, no-output-schema tool this covers source, base currency, cadence, and input format, which is essentially the whole contract. The remaining omission is the shape of the returned rate (e.g. whether an effective date accompanies the value) and error behavior on invalid codes.

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 0% — the schema only says 'string' — so the description must compensate, and it does: it specifies the 3-letter ISO format and gives four concrete examples (USD, EUR, GBP, JPY). It stops short of stating case sensitivity or behavior for a non-supported code.

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

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

States a specific verb (fetch latest) and a precisely scoped resource: Bank of Canada daily average rate for a currency quoted against CAD. Naming the Bank of Canada source is what separates it from siblings like ecb_reference_rates and global_fx_rate without the agent opening any schema.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no sibling is named. 'Latest' implicitly excludes historical use (global_fx_timeseries) and 'CAD' implicitly excludes cross-currency conversion (convert, global_fx_convert), but the agent has to infer all of that. 'FREE' is the only usage-adjacent signal.

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 carries the full behavioral burden. It usefully discloses the data source (Bank of Canada), update cadence (daily), scope (major currencies vs CAD), and subscriber/PRO context, but it does not describe authentication behavior beyond the schema, rate 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 compact sentence that front-loads the key scope and source information. The leading 'PRO.' is somewhat unexplained, but overall it is efficient and free of repetition.

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

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

For a simple one-parameter read tool this is nearly adequate, but with no output schema the description should clarify the return shape or at least resolve the ambiguity of 'vs CAD' (base/quote direction). The list of covered major currencies and rate timestamp behavior are also omitted.

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

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

Schema description coverage is 100%, and the sole optional access_token parameter is fully documented in the input schema. The description adds no additional meaning about the token or its source, so the baseline score of 3 is appropriate.

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

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

The description names a specific resource (Bank of Canada daily FX rates), scope (major currencies vs CAD), and freshness (latest), which lets an agent distinguish it from ECB reference rates and generic conversion siblings. It is not a verb-first statement, but the implied retrieval purpose is 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 gives no explicit when-to-use guidance, no exclusions, and does not name alternatives such as fx_rate, global_fx_rate, or ecb_reference_rates. The only implied context is that this is a PRO/subscriber endpoint for Bank of Canada rates.

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 burden and does add real value: it discloses the x402 payment model ($0.01/call) and that rates are end-of-day rather than intraday, which materially affects interpretation of results. It does not disclose authentication requirements (the access_token parameter carries that in the schema), error behavior for out-of-range dates, or what the response contains.

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 tight sentences with no filler; the pricing note is front-loaded as a gate before the functional description. Nothing is wasted, though the '$0.01/call via x402' framing is arguably billing metadata rather than tool semantics.

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 5-parameter, no-annotation, no-output-schema tool, the description covers the core operation and the date parameter well. But with no output schema and no annotations, the agent is left guessing what the response shape is (converted amount, applied rate, timestamp) and what failure modes 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 only 20% (just access_token), so the description must compensate — and it partially does, documenting date format (YYYY-MM-DD), the historical range (back to 1999), and that from/to accept major currency codes. It leaves gaps on the expected currency code convention (ISO 4217 uppercase?), amount constraints, and the access_token acquisition flow beyond the schema hint.

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+resource ('Convert an amount between any two major currencies') that clearly distinguishes this tool from rate-lookup siblings like fx_rate, global_fx_rate, and global_fx_timeseries. It doesn't name those siblings explicitly, so the differentiation is implicit rather than stated.

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

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

Usage is implied by the phrase 'at the latest or a given historical end-of-day rate,' which tells the agent this tool serves both spot and historical conversion needs. However, there is no explicit when-to-use vs when-not guidance, and no mention of when to prefer the rate-only siblings over this conversion 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?

With no annotations, the description must carry the full load. It usefully discloses that the data is free, end-of-day (not live), sourced from Frankfurter/ECB reference rates, and limited to ~30 currencies — real behavioral context. It says nothing about authentication, rate limits, behavior for unsupported currency codes, or which date's rate is returned.

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 short sentences, front-loaded with the standout fact ('FREE'), then scope, then examples, then provenance. No filler; the only slight waste is the trailing source attribution, which is nonetheless routing-relevant.

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

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

For a 2-param read tool with no output schema, the description covers what the tool is, its scope, its data vintage, and its source. The remaining gap is the return shape — whether it returns a scalar rate, a rate plus effective date, or a currency pair object — which matters since no output schema exists to answer that.

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% — 'base' and 'quote' are bare strings with no format hints. The description partially compensates by showing examples (USD, EUR, GBP, JPY), which reveals the 3-letter ISO code convention and the base→quote direction, but never enumerates or points to the ~30 valid currencies, so an agent still cannot validate inputs.

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

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

States a specific verb+resource: 'end-of-day FX rate between any two ... currencies', with concrete examples (USD to EUR, GBP to JPY). The 'end-of-day' qualifier and 'global' scope meaningfully separate it from sibling tools like global_fx_convert or global_fx_timeseries, though the distinction from the plain 'fx_rate' sibling is never made 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?

Usage is only implied: 'end-of-day' signals this is not a real-time quote, and tennis-court examples show the base/quote direction convention. No statement of when to prefer this over fx_rate, convert, or global_fx_convert, and no conditions under which it should not be used.

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

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

With no annotations, the description carries the burden well by disclosing the paid tier and price ($0.01/call via x402), the 366-day maximum range, the 10-quote cap, and the end-of-day granularity. It omits auth requirements and any note about holidays/weekend gaps in the series.

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 tight sentence with no waste, front-loaded with cost and capability. The pricing prefix is slightly distracting but is genuinely decision-relevant for an agent choosing among tools.

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 annotations and no output schema, the description covers what is returned (a daily series) and the hard limits, which is solid. It still leaves date format, the optional end default, and auth/token flow unaddressed, so an agent could call it correctly in spirit but not in detail.

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 only 20% (only access_token is documented in the schema), so the description must compensate. It does add meaning for base, quotes, start, and end, but never specifies the date string format or the default for the optional end parameter, leaving real ambiguity for 3 required params.

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

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

The description states a concrete verb and resource: it returns daily end-of-day FX time series for one base currency against up to 10 quote currencies over a date range. The temporal, multi-quote scope separates it in practice from single-rate siblings such as fx_rate and global_fx_rate, though no sibling is named explicitly.

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

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

Usage is implied by the 'between two dates' and multi-quote framing, so an agent can infer this is for historical series rather than a spot lookup. However, there is no explicit when-to-use/when-not guidance and no pointer to convert, fx_rate, or global_fx_convert as 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?

No annotations exist, so the description carries the full disclosure burden, and it says nothing about read-only safety, data freshness/frequency, or that a subscriber token may be required (only the cryptic 'PRO' prefix hints at this). It only enumerates which series are covered, leaving mutation/auth/timing behavior entirely unstated.

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 dense, front-loaded sentence with zero filler; every clause names a distinct data series. It is efficient but arguably too terse for a tool with no annotations 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 a single optional parameter and no output schema or annotations, the description covers 'what data' adequately but omits 'what form and when' – snapshot vs. time series, refresh cadence, units, and the auth expectation implied by 'PRO'. For a rates-feed tool that is a meaningful but not fatal gap.

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

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

Schema description coverage is 100% and the single access_token parameter is fully documented at the schema level, so the baseline is 3. The description adds nothing about the token, the 'PRO' gating it implies, or what happens if it is omitted (it is optional per 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 names the specific resource precisely – BoC overnight target, prime rate, 5-year mortgage, 2/10-year GoC bond yields – which clearly separates it from the FX-focused siblings (fx_rate, convert, global_fx_timeseries). However, it is a bare noun phrase with no verb ('returns', 'get'), so the agent must infer that the tool retrieves these series rather than computing or converting them.

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 over the sibling FX tools, no mention of whether the data is a current snapshot or historical, and no stated prerequisites beyond the token that appears in the schema. The 'PRO' prefix hints at a paid/subscriber tier but that is never explained.

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