How do I use boc-valet-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@boc-valet-mcp what's the latest USD/CAD exchange rate?" 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.

boc-valet-mcp

by Chatusvi-Karnati

Overview Schema Source Related Servers Discussions Admin

Python

Remote

🇨🇦 Bank of Canada Valet MCP Server

Python 3.10+ MCP License: MIT

An MCP server that gives LLM agents (Claude, and any other MCP-compatible client) live access to Canadian economic and financial data through the Bank of Canada Valet API — exchange rates, interest rates, inflation series, and thousands more.

The Valet API is free and requires no API key, so this server runs out of the box.

Ask "What's the latest USD/CAD exchange rate?" or "Chart CORRA over the last month" and the agent pulls the numbers straight from the source.

Why this exists

Large language models don't know today's exchange rate — their training data is frozen in the past. MCP closes that gap by letting a model call live tools. This server is a small, focused, production-shaped example of that pattern: clean tool design, input validation, actionable errors, and tests.

Related MCP server: Data360 MCP Server

Features

5 well-scoped tools covering discovery → metadata → data retrieval
No API key — the Valet API is public
Dual output — human-readable Markdown or structured JSON, per call
Search + pagination over the large series/group catalogue
Multi-series comparison — pull several series side by side in one call
Agent-friendly errors — every failure explains what to try next
Typed & validated — Pydantic Field constraints on every parameter
Tested — offline unit tests, no network needed for CI

Tools

Tool	What it does
`boc_list_series`	Search / list the available data series (start here)
`boc_list_groups`	Search / list curated groups of related series
`boc_get_series_info`	Fetch metadata (label, description) for one series
`boc_get_observations`	Core: get data points for one or more series, by date range or most-recent
`boc_get_group_observations`	Get every series in a group in a single call

Architecture

src/boc_valet_mcp/
├── server.py       # MCP tool definitions (the interface agents see)
├── client.py       # Async httpx client + centralized, actionable errors
└── formatting.py   # Markdown / JSON rendering (shared by every tool)

The separation keeps each layer testable: tools stay thin, HTTP concerns live in one place, and presentation logic is unit-tested offline against representative payloads.

Quickstart

git clone https://github.com/Chatusvi-Karnati/boc-valet-mcp.git
cd boc-valet-mcp
python -m venv .venv && source .venv/bin/activate   # Windows: .venv\Scripts\activate
pip install -e .

Run it directly (it speaks MCP over stdio):

boc-valet-mcp

Inspect it interactively

The MCP Inspector is the fastest way to click through the tools:

npx @modelcontextprotocol/inspector boc-valet-mcp

Use it with Claude Desktop

Add this to your claude_desktop_config.json (see examples/):

{
  "mcpServers": {
    "bank-of-canada": {
      "command": "boc-valet-mcp"
    }
  }
}

Restart Claude Desktop and ask it something like "Compare the USD/CAD and EUR/CAD rates over the past week."

Example

Calling boc_get_observations with series_names="FXUSDCAD", recent=1:

**Series:**
- `FXUSDCAD` — US dollar to Canadian dollar daily exchange rate

| Date       | FXUSDCAD |
|------------|----------|
| 2024-06-03 | 1.3654   |

_1 observation(s)._

Development

pip install -e ".[dev]"
pytest              # run the test suite
ruff check .        # lint

How it was built

Designed and built following Anthropic's MCP server best practices — comprehensive tool coverage, readOnly/idempotent annotations, Pydantic-validated inputs, and error messages written for an agent audience. Developed with an AI-assisted workflow using Claude Code.

License

MIT — see LICENSE.

Acknowledgements

Data is provided by the Bank of Canada Valet API. This project is not affiliated with or endorsed by the Bank of Canada. Please review the Bank of Canada's terms of use for the data.

Available Tools

5 tools

boc_get_group_observationsA

Read-onlyIdempotent

Retrieve observations for every series in a group in one call.

For example group_name='FX_RATES_DAILY', recent=1 returns the latest daily exchange rate for all published currencies at once.

ParametersJSON Schema

Name	Required	Description	Default
`recent`	No
`group_name`	Yes	Group name, e.g. 'FX_RATES_DAILY' for daily exchange rates.
`response_format`	No	'markdown' for readable output or 'json' for structured data.	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no new behavioral details beyond the example, missing context like pagination or data freshness.

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

Conciseness5/5

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

Two concise sentences with a front-loaded verb phrase and a helpful example. No unnecessary information.

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

Completeness4/5

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

With annotations covering safety, an output schema present, and a clear description of core functionality plus example, the tool is well-specified. Minor missing context about group source or data limits, but overall sufficient.

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

Parameters3/5

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

Schema covers two of three parameters (group_name, response_format) with descriptions. The description's example implies 'recent' usage but doesn't explicitly define it, leaving a gap. Coverage is adequate but not enhanced.

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

Purpose5/5

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

Description clearly states the tool retrieves observations for all series in a group, with a concrete example illustrating use. It distinguishes from sibling tools like boc_get_observations which target individual series.

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

Usage Guidelines3/5

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

The description notes efficiency ('in one call') and gives an example, but does not explicitly state when to use this tool versus siblings like boc_get_observations or boc_list_series.

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

boc_get_observationsA

Read-onlyIdempotent

Retrieve observations (the actual data points) for one or more series.

This is the core tool. Supply a date range with 'start_date'/'end_date', or ask for the latest values with 'recent'. Multiple comma-separated series are returned side by side for easy comparison.

Example: series_names='FXUSDCAD', recent=1 returns the latest USD/CAD rate.

ParametersJSON Schema

Name	Required	Description	Default
`recent`	No	Return only the N most recent observations. Handy when you just want the latest value(s) and no date range.
`end_date`	No	End date, YYYY-MM-DD.
`start_date`	No	Start date, YYYY-MM-DD.
`series_names`	Yes	One series name, or several comma-separated (e.g. 'FXUSDCAD' or 'FXUSDCAD,FXEURCAD').
`response_format`	No	'markdown' for readable output or 'json' for structured data.	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. Description adds value by explaining that the tool returns actual data points and handles multiple series and date ranges, consistent with annotations. No contradictions.

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

Conciseness5/5

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

Extremely concise: three sentences and an example. The purpose is front-loaded, and every sentence adds value. No wasted words.

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

Completeness5/5

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

With an output schema present, the description need not explain return values. It covers the core functionality, parameter usage, and an example, fully capturing the tool's purpose for an agent.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. Description adds context beyond schema descriptions, such as explaining that 'recent' is for latest values and giving an explicit example of how to use series_names with recent. This enhances comprehension.

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

Purpose5/5

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

The description clearly states 'Retrieve observations (the actual data points) for one or more series,' which is a specific verb+resource. It positions itself as 'the core tool,' implicitly distinguishing it from sibling tools that list series or get metadata.

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

Usage Guidelines3/5

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

Provides usage patterns (date range vs recent, multiple series), but does not explicitly state when to use this tool versus its siblings (e.g., boc_list_series or boc_get_group_observations). The example helps but lacks direct differentiation.

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

boc_get_series_infoA

Read-onlyIdempotent

Get the label and description metadata for a single series.

Useful for confirming a series is what you expect before pulling its observations.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Exact series name, e.g. 'FXUSDCAD'.
`response_format`	No	'markdown' for readable output or 'json' for structured data.	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds minimal behavioral context (e.g., no mention of rate limits or authentication). It does not contradict annotations.

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

Conciseness5/5

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

Two sentences: first states purpose, second gives usage guidance. No unnecessary words or redundancy. Well-structured for quick comprehension.

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

Completeness4/5

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

Given the presence of an output schema, the description adequately covers purpose and usage. It does not address error handling or naming conventions, but these are minor omissions for a simple read-only tool.

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

Parameters3/5

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

Schema description coverage is 100%; both parameters (name, response_format) are well-described in the schema. Description adds no extra parameter details beyond what is already present.

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

Purpose5/5

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

Description clearly states 'Get the label and description metadata for a single series,' using a specific verb and resource. It distinguishes from sibling tools like boc_get_observations and boc_list_series, which handle observations or listing.

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

Usage Guidelines5/5

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

Explicitly advises use 'before pulling its observations,' providing clear context and implicit exclusions. Though alternatives are not named, the guidance is actionable and aligns with sibling tool purposes.

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

boc_list_groupsA

Read-onlyIdempotent

Discover available data groups (curated bundles of related series).

Groups collect related series — for example 'FX_RATES_DAILY' bundles the daily exchange rates for many currencies. Feed a returned group name into 'boc_get_group_observations'.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max results to return.
`offset`	No	Results to skip (pagination).
`search`	No	Case-insensitive substring to filter by name, label, or description (e.g. 'exchange rate', 'CORRA', 'inflation').
`response_format`	No	'markdown' for readable output or 'json' for structured data.	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds context about groups being curated bundles, but does not reveal behavioral traits beyond what the annotations convey.

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

Conciseness5/5

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

Two well-structured sentences, front-loaded with the core purpose, no fluff. Concise and informative.

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

Completeness5/5

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

Given the presence of an output schema, pagination parameters, and search functionality, the description is complete. It explains what groups are and how to use them, providing sufficient context for an AI agent.

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

Parameters3/5

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

Schema coverage is 100%, so the baseline is 3. The description mentions feeding a group name into another tool, which implies the output can be used as input, but does not add specific parameter-level details beyond the schema.

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

Purpose5/5

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

The description clearly states it lists data groups, gives a concrete example ('FX_RATES_DAILY'), and explains how to use the output with a sibling tool, distinguishing itself from other tools.

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

Usage Guidelines4/5

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

The description implicitly guides usage by suggesting to feed the result into 'boc_get_group_observations', but does not explicitly state when to use or not use this tool compared to alternatives like 'boc_list_series'.

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

boc_list_seriesA

Read-onlyIdempotent

Discover available data series in the Bank of Canada Valet API.

Use this first when you do not already know a series name. Filter with 'search' to narrow the (large) catalogue, then feed a returned name into 'boc_get_observations'. Returns a paginated list of series with their name, label, and description.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max results to return.
`offset`	No	Results to skip (pagination).
`search`	No	Case-insensitive substring to filter by name, label, or description (e.g. 'exchange rate', 'CORRA', 'inflation').
`response_format`	No	'markdown' for readable output or 'json' for structured data.	markdown

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds that it returns a paginated list with name, label, description, providing useful detail beyond annotations.

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

Conciseness5/5

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

Four sentences, each essential: purpose, usage order, search/next step, return structure. No redundant words.

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

Completeness5/5

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

Given the tool's purpose and the presence of output schema, description fully covers discovery workflow, pagination, and integration with sibling tools.

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

Parameters4/5

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

Schema coverage is 100% with good descriptions. Description adds strategic context: mentions filtering to narrow catalogue and pagination, but does not repeat schema details.

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

Purpose5/5

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

Description clearly states the tool lists/search Bank of Canada data series. It distinguishes from siblings by indicating this is the first step to discover series names.

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

Usage Guidelines5/5

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

Explicitly instructs when to use ('first when you do not already know a series name'), how to filter with 'search', and the next step ('feed a returned name into boc_get_observations').

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv1.0.0Jul 30, 2026
- First observedboc_get_group_observations
- First observedboc_get_observations
- First observedboc_get_series_info
- First observedboc_list_groups
- First observedboc_list_series

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-07-30 02:25 across 5 tools

Disambiguation5/5

Each tool has a clear, distinct purpose: listing series, listing groups, getting series metadata, getting observations for series, and getting observations for groups. No overlap.

Naming Consistency5/5

All tools follow a consistent 'boc_verb_noun' pattern (e.g., boc_list_series, boc_get_observations), making it easy to infer functionality.

Tool Count5/5

With 5 tools, the server is focused and each tool earns its place. The count is ideal for a read-only economic data API.

Completeness4/5

Covers discovery and retrieval for both individual series and groups. Missing a dedicated tool for group metadata, but the list tool provides enough context.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Market Intel MCP A
io.github.selflabbs
Live & historical FX rates and currency conversion for AI agents. No API keys.
Finance Cryptocurrency
2
Market Intel MCP A
com.datakoot
Live & historical FX rates and currency conversion for AI agents. No API keys.
Finance Open Data
51
Unit & Currency Converter A
io.github.guptaprakhariitr
60+ units, live FX, timezones, and date arithmetic for AI agents.
Finance Location Services
621
Tako A
io.github.TakoData
Give your agent web search and authoritative datasets: S&P Global, FRED, OECD, SimilarWeb & more.
Search Knowledge & Memory Research & Data
425

Related MCP Servers

Norges Bank MCP Server
Finance Open Data Government Data
mctar
A
license
Not graded
quality
D
maintenance
Enables AI agents to query Norges Bank's open data API for exchange rates, policy rates, government securities, money market data, bank liquidity, and regional network survey data.
Updated 5 months ago (2026-03-30 22:02 UTC)
MIT
Data360 MCP Serverofficial
Government Data Open Data Research & Data
worldbank
F
license
Not graded
quality
C
maintenance
Provides LLM agents direct access to World Bank development indicators, enabling search, validation, and retrieval of data on topics like GDP, poverty, and gender equality.
Updated 2 days ago (2026-09-10 19:53 UTC)
35
-
mcp-worldbank
Open Data Research & Data Government Data
pipeworx-io
A
license
Not graded
quality
C
maintenance
Enables AI agents to access and query World Bank data (free, no auth) through natural language or direct tools, wrapping the World Bank Data API v2.
Updated 18 days ago (2026-08-26 17:50 UTC)
6 npm
MIT
publicfinance
Finance Government Data
Leviai-ai
A
license
A
quality
D
maintenance
Enables AI agents to access SEC EDGAR filings, US Treasury rates, BLS labor statistics, and economic indicators without API keys.
Updated 5 months ago (2026-04-02 21:57 UTC)
6
44 npm
MIT

🇨🇦 Bank of Canada Valet MCP Server

Why this exists

Features

Tools

Architecture

Quickstart

Inspect it interactively

Use it with Claude Desktop

Example

Development

How it was built

License

Acknowledgements

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Data360 MCP Serverofficial