Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@bank-of-canada-mcp What's the Bank of Canada's current policy rate, and how has it moved this year?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives Claude and other LLMs live access to Canadian economic data via the Bank of Canada's free Valet API — ~16,000 time series covering exchange rates, the policy interest rate, CPI, bond yields, commodity prices, and more.
FRED, the World Bank, and the IMF all have MCP servers. Canada didn't — now it does.
No API key required.
Claude Code
claude mcp add bank-of-canada -- npx -y bank-of-canada-mcpClaude Desktop — add to claude_desktop_config.json:
{
"mcpServers": {
"bank-of-canada": {
"command": "npx",
"args": ["-y", "bank-of-canada-mcp"]
}
}
}The same npx invocation works in Cursor, Windsurf, and any other MCP client.
Related MCP server: mcp-server-fxmacrodata
Tool | What it does |
| Keyword search across the full series catalogue — find the series name for anything ("overnight rate target", "CPI", "5-year bond") |
| Time-series data for up to 5 series, by date range or N most recent |
| Today's official daily exchange rates vs CAD |
| Convert between any two supported currencies using today's rates |
"What's the Bank of Canada's current policy rate, and how has it moved this year?"
"Plot USD/CAD for the last 90 days."
"Convert 2,500 EUR to CAD at today's official rate."
"How does core CPI compare to headline CPI over the past two years?"
npm install
npm test # offline unit tests (vitest)
npm run build # tsc → dist/Architecture: src/valet.ts is a plain API client with pure, unit-tested logic (search, conversion math); src/index.ts is the MCP wiring. Errors from the Valet API (e.g. an unknown series name) are returned as MCP tool errors with the API's own message, so the model can self-correct by re-searching.
Rates are the Bank of Canada's indicative daily averages, published once per business day — not transactional quotes.
Data is © Bank of Canada, used under their terms. This project is not affiliated with or endorsed by the Bank of Canada.
Statistics Canada Web Data Service tools
Group browsing (lists/groups)
Streamable HTTP transport for remote deployment
MIT
Convert an amount between currencies using the latest Bank of Canada daily rates (cross-rated through CAD). Indicative daily averages, not transactional quotes.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ISO currency code, e.g. EUR | |
| from | Yes | ISO currency code, e.g. USD | |
| amount | Yes | Amount to convert |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the data source (Bank of Canada daily rates), the methodology (cross-rated through CAD), and the limitations (indicative daily averages, not transactional quotes). This is strong transparency for a simple read-only conversion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that states purpose and key caveats without fluff. It is front-loaded with the verb and noun phrase, and every clause 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?
For a simple three-parameter tool with no output schema, the description covers all essential aspects: what it does, the data source, and the limitations of the result. It could optionally mention the exact response format, but that is not critical for basic 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?
The input schema already covers all three parameters (amount, from, to) with clear descriptions, so 100% schema coverage is achieved. The description adds minimal extra parameter-specific context—only the 'cross-rated through CAD' hint, which is a general behavior note rather than a parameter clarification. 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 verb ('Convert'), the resource ('an amount between currencies'), and the data source ('latest Bank of Canada daily rates'), making the tool's purpose unambiguous. It also distinguishes itself from siblings like latest_fx_rates by focusing on conversion rather than just returning 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?
The description gives useful context—indicative daily averages, not transactional quotes—which implicitly tells users this is not for real-time trading or guaranteed quotes. However, it does not explicitly compare to alternatives like latest_fx_rates or explain when to prefer this tool over those siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch observations for up to 5 Bank of Canada series (find names with search_series). Defaults to the 10 most recent observations when no range is given.
| Name | Required | Description | Default |
|---|---|---|---|
| recent | No | Alternatively: just the N most recent observations | |
| series | Yes | Series names, e.g. ['FXUSDCAD', 'V39079'] | |
| end_date | No | End of range, YYYY-MM-DD | |
| start_date | No | Start of range, YYYY-MM-DD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the 5-series limit and the 10-recent-observations default, but does not mention return format, pagination, error handling, or what 'observations' include. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no filler or redundant information. Every clause adds meaningful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema, it covers key usage constraints (series limit, default recent count, how to find series). It does not describe the structure of returned observations, which would be useful, but is not severely 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 descriptions cover all parameters (100% coverage), so baseline is 3. The description adds value by explaining that when no range is given it defaults to 10 most recent observations, clarifying the relationship between recent and date-range parameters 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 states the specific action 'Fetch observations' for up to 5 Bank of Canada series, with a pointer to search_series for finding names. This clearly distinguishes it from siblings like latest_fx_rates and convert_currency by implying it is the historical time-series 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?
It provides clear context by mentioning search_series for finding names and describing the default behavior when no range is given. It lacks explicit exclusions for alternatives, but the purpose is distinct enough that usage is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest official Bank of Canada daily exchange rates, quoted as CAD per 1 unit of each foreign currency.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the data source (Bank of Canada), frequency (daily), and quote convention (CAD per unit of foreign currency), which adds context. However, it does not disclose the response format, whether all currencies are included, or any potential limitations. This is a read-only operation by nature, but the description does not explicitly state that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose and includes essential details (official, daily, CAD per unit). Every word contributes value, and there is no redundancy or 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?
Given the tool's simplicity (no parameters, no annotations, no output schema), the description is largely complete: it identifies the source, the type of data, and the unit convention. However, it does not specify the shape of the response (e.g., a list, a dictionary mapping currency codes to rates), which would be helpful since there is no output schema to clarify this. Still, for a simple no-parameter tool, the gap is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. The description does not need to explain parameters since there are none. This aligns with the baseline for 0-parameter tools, and the description adds no parameter-related information because none is required.
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 'Latest official Bank of Canada daily exchange rates' with a specific quote convention (CAD per 1 unit of each foreign currency). This distinguishes it from siblings like convert_currency (which converts amounts) and search_series/get_observations (which are about series data). The verb is implicit but the resource and scope are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus the sibling tools (search_series, get_observations, convert_currency). There is no mention of exclusions or alternatives, so the agent is left to infer usage context from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Bank of Canada's catalogue of ~16,000 economic time series (exchange rates, policy interest rate, CPI, bond yields, commodity prices...). Returns series names to use with get_observations.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return | |
| query | Yes | Keywords, e.g. 'overnight rate target' or 'USD exchange' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the core behavior—searching a catalogue and returning series names—and includes examples of typical queries. However, it does not detail search mechanics (e.g., fuzzy vs. exact matching, case sensitivity, or result ranking), but these are not critical for a simple search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the resource and scope, followed by the purpose of the search results. Every word earns its place without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the description covers the main purpose, input examples, and how the output is used (series names for get_observations). It does not describe the exact return format (e.g., array of strings vs. objects), but the stated purpose is sufficient for an agent to proceed, given the low complexity and absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full documentation for both parameters, including defaults, constraints, and examples. The description adds little beyond schema, but it reinforces that the query is for keywords and that results are series names. With 100% schema coverage, 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 uses a specific verb ('Search') and resource ('Bank of Canada's catalogue of ~16,000 economic time series') with examples of content. It clearly distinguishes this tool from siblings like get_observations and latest_fx_rates by focusing on discovering series identifiers rather than retrieving data.
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 states that the tool returns series names for use with get_observations, which implies a workflow of searching first and then fetching observations. It does not explicitly exclude alternatives like latest_fx_rates or convert_currency, but the workflow context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.1convert_currencyget_observationslatest_fx_ratessearch_seriesEach tool has a clearly distinct purpose: searching series, fetching observations, getting latest FX rates, and converting currency. Even though latest_fx_rates and get_observations both relate to exchange rates, the descriptions clarify scope (latest vs. historical series data), leaving no ambiguity.
All tool names use snake_case and are descriptive. Most follow a verb_noun pattern (search_series, get_observations, convert_currency), while latest_fx_rates is an adjective_noun deviation, but the style remains consistent and predictable.
Four tools is slightly lean but appropriate for the focused scope of a Bank of Canada data read server. Each tool has a clear role, and the count feels adequate rather than excessive or trivially small.
The server covers the core workflow: discover series, fetch observations, retrieve latest FX rates, and perform currency conversion. Minor gaps exist (e.g., no metadata endpoint or historical FX rate convenience method), but agents can work around them using get_observations with series names.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Bank of Canada Valet API MCP. Keyless. Dates are YYYY-MM-DD.
Macro indicators from World Bank, FRED, IMF, and OECD via unified query surface.
Live & historical FX rates and currency conversion for AI agents. No API keys.
Live & historical FX rates and currency conversion for AI agents. No API keys.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/arose26/bank-of-canada-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
