Click on "Deploy 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., "@hk-markets-mcp What's the HKMA base rate and USD/HKD peg status today?"
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 an AI agent live Hong Kong monetary data: the HKMA Base Rate, HIBOR fixings, and the USD/HKD peg band with the Aggregate Balance.
Data comes from the Hong Kong Monetary Authority's public Open API. No API key, no registration, no account.
> What is overnight HIBOR doing this week, and has the HKMA been defending the peg?
get_hibor { history_days: 5 }
get_peg_status {}
Overnight HIBOR is 2.03% as of 2026-09-16, having ranged 2.03% to 2.15%
over the last five business days. The Convertibility Undertaking band is
7.75 to 7.85 and the Aggregate Balance closed at HKD 56,167 million.Claude Desktop — add to claude_desktop_config.json:
{
"mcpServers": {
"hk-markets": {
"command": "npx",
"args": ["-y", "hk-markets-mcp"]
}
}
}Claude Code:
claude mcp add hk-markets -- npx -y hk-markets-mcpAnything else that speaks MCP over stdio: run npx -y hk-markets-mcp.
Related MCP server: mcp-cbr-rates
Each declares an input and an output schema, so results come back as structured data rather than prose a client has to parse back out.
get_base_rateThe HKMA Base Rate: the floor of the Discount Window and the anchor for Hong Kong dollar rates. Under the Linked Exchange Rate System it tracks the US federal funds target, so it usually moves only when the Fed moves.
Argument | Type | |
|
| Business day to report. Omit for the latest. |
Returns as_of, base_rate_percent, source.
get_hiborHong Kong Interbank Offered Rate. This dataset publishes two tenors, overnight and one month; other tenors are not in it.
Argument | Type | |
|
| Business day to report. |
|
| Also return that many recent business days, newest first. |
Returns as_of, overnight_percent, one_month_percent, optional history[], source.
History is where HIBOR is actually informative: overnight can swing several points around month and quarter ends.
get_peg_statusWhere the Linked Exchange Rate System stands.
Argument | Type | |
|
| Business day to report. |
Returns as_of, strong_side, weak_side, aggregate_balance_hkd_millions, trade_weighted_index, note, source.
This dataset does not publish the spot USD/HKD rate, so the tool reports the band the HKMA commits to trade at, plus the Aggregate Balance — which is the better intervention signal anyway. It shrinks when the HKMA buys Hong Kong dollars to defend the weak-side Convertibility Undertaking.
This is a free public service run by a central bank, so the client:
caches for 15 minutes, since the data is daily — an agent asking the same question ten times costs HKMA one request;
shares in-flight requests, so ten concurrent callers also make one;
serialises upstream calls with a minimum 250 ms gap;
sends a descriptive User-Agent pointing back here;
times out at 15 seconds rather than hanging.
Both are handled here, and both bite if you call the API directly:
from and to are silently ignored without choose. The filter only applies when choose=<field> names the column. Without it you get the most recent page and no error — real data for the wrong dates.
Once choose is set, both bounds are required. Half a range is rejected upstream; this client rejects it before the request goes out, with a message that says so.
HKMA publishes on business days, so weekends and Hong Kong public holidays have no rows. Every tool reports the as_of date it actually got, rather than letting an agent present Friday's figures as today's.
npm install
npm test # 22 tests, no network: the HTTP layer is faked
npm run build
npm run dev # run the server on stdioMIT © Harvey Singh
The Hong Kong Monetary Authority Base Rate: the floor of the Discount Window and the anchor for Hong Kong dollar interest rates. Under the Linked Exchange Rate System it tracks the US federal funds target, so it usually moves only when the Fed moves.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Business day to report, YYYY-MM-DD. Omit for the most recent published day. |
| Name | Required | Description |
|---|---|---|
| as_of | Yes | The business day these figures are published for, YYYY-MM-DD. |
| source | Yes | Where the figures came from. |
| base_rate_percent | Yes | HKMA Base Rate in percent, null if unpublished. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation. The description adds useful context about the rate's behavior (tracks US federal funds target, moves only when Fed moves), which is beyond the annotations. However, it doesn't disclose details like whether the rate is the current published rate or historical, or any rate limit considerations.
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-loads the core definition, and adds relevant context without waste. Every 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?
The tool has a simple parameter set (one optional date), an output schema exists, and annotations cover safety. The description provides enough context about the rate's behavior and significance. It could mention that the date parameter is optional and defaults to the most recent published day, but the schema already covers 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 100%, so the schema already documents the 'date' parameter well. The description doesn't add much about the parameter beyond what the schema provides, but the schema is sufficient. 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 identifies the tool as retrieving the HKMA Base Rate, explains its role as the Discount Window floor and anchor for HKD interest rates, and distinguishes it from siblings by focusing on the Base Rate specifically. The verb 'get' plus the specific resource makes the purpose 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 explains the economic context and when the rate typically changes (only when the Fed moves), which helps an agent understand when to call this tool. It doesn't explicitly name alternatives like get_hibor or get_peg_status, but the context of the Linked Exchange Rate System and the focus on the Base Rate implicitly differentiates it from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hong Kong Interbank Offered Rate. This dataset publishes two tenors, overnight and one month; other tenors are not in it. Optionally returns recent history, which is where HIBOR is actually informative, because overnight can swing several points around quarter and month ends.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Business day to report, YYYY-MM-DD. Omit for the most recent published day. | |
| history_days | No | Also return this many recent business days, newest first. |
| Name | Required | Description |
|---|---|---|
| as_of | Yes | The business day these figures are published for, YYYY-MM-DD. |
| source | Yes | Where the figures came from. |
| history | No | Recent business days, newest first, present only when history_days was given. |
| one_month_percent | Yes | One-month HIBOR fixing in percent. |
| overnight_percent | Yes | Overnight HIBOR fixing in percent. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds valuable behavioral context beyond annotations: the dataset only contains two tenors, and overnight HIBOR can swing around quarter and month ends. This helps the agent set expectations about data coverage and volatility without contradicting the 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?
Three concise sentences with no filler. The key dataset identity is front-loaded, followed by scope limitations and a focused usage tip. Every 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?
With an output schema present, no return-value explanation is needed. The description covers the dataset's identity, tenor scope, data caveat, and the value of the history option, which is sufficient for a simple read-only lookup tool.
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 both parameters are already documented in the schema. The description adds only general context about returning recent history, which maps to history_days, but does not provide additional detail beyond the schema. 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 identifies the resource (Hong Kong Interbank Offered Rate) and states the tool's behavior: it publishes two specific tenors and optionally returns recent history. It is distinct from siblings like get_base_rate and get_peg_status by naming a different financial rate and dataset scope.
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: the dataset covers only overnight and one-month tenors, and other tenors are explicitly excluded. It also advises that recent history is where HIBOR is actually informative, guiding use of the optional history parameter. It does not explicitly name sibling alternatives, but the exclusion alone provides useful when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where the Linked Exchange Rate System stands: the Convertibility Undertaking levels the HKMA commits to trade at, and the Aggregate Balance, which is the figure that actually shows whether it has been intervening. Note this dataset does not publish the spot USD/HKD rate, so this tool reports the band and the balance rather than guessing where spot sits.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Business day to report, YYYY-MM-DD. Omit for the most recent published day. |
| Name | Required | Description |
|---|---|---|
| note | Yes | What this dataset does and does not say. |
| as_of | Yes | The business day these figures are published for, YYYY-MM-DD. |
| source | Yes | Where the figures came from. |
| weak_side | Yes | HKMA buys HKD at this level, normally 7.85. |
| strong_side | Yes | HKMA sells HKD at this level, normally 7.75. |
| trade_weighted_index | Yes | Trade-weighted Hong Kong dollar index. |
| aggregate_balance_hkd_millions | Yes | Closing Aggregate Balance. It shrinks when the HKMA buys HKD defending the weak side. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating the tool is read-only and may return unexpected data. The description adds behavioral context by stating that the tool reports the band and balance rather than guessing spot, and clarifies the dataset's scope. It doesn't 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, information-dense, and front-loaded with the purpose. Every sentence adds value: it defines the tool's scope, explains what it reports, and clearly states its limitations. No wasted words.
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?
With an output schema present and a single optional parameter, the description covers the key functional aspects: what the tool reports, its limitation regarding spot rates, and the optional date. It could be more complete by mentioning what output fields to expect, but the output schema likely covers that, so a 4 is appropriate.
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 date parameter is fully documented with its pattern and meaning. The description reinforces the optional nature of the date but does not add additional semantic detail beyond the schema. Baseline 3 is appropriate since the schema does the heavy lifting.
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: to report on the Linked Exchange Rate System's Convertibility Undertaking levels and Aggregate Balance, specifically for the USD/HKD peg. It distinguishes itself from potential sibling tools that might report spot rates by explicitly noting that this dataset does not publish the spot rate.
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 explains what the tool does not do (report spot USD/HKD rate) but does not explicitly name alternative tools for getting the spot rate or when to use them. Sibling tools like get_base_rate and get_hibor are different, but the description doesn't guide the agent to use them for spot rates. It does imply usage by stating the dataset's limitation.
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.
v0.1.0get_base_rateget_hiborget_peg_statusScored across 3 tools
Each tool targets a distinct piece of HK monetary data: the base rate, HIBOR, and the Linked Exchange Rate System status. There is no overlap or ambiguity between them.
All three tool names follow the same get_<noun> pattern with clear, descriptive nouns. The naming is consistent and predictable.
Three tools is a tight, well-scoped set for the server's purpose of exposing HK money market indicators. Each tool earns its place and the count is not padded.
The set covers the core HKMA policy rates and the peg status, which are the main published indicators. Minor gaps exist, such as no direct USD/HKD spot rate or historical base rate data, but the tools explicitly note these limitations and the domain is well covered for a focused server.
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.
Crypto yield data for AI agents: lending, savings, staking, borrowing & stablecoin rates. 18 tools.
Real-time data API for AI Agents: stocks, weather, forex, logistics, search, scrape, news, IP.
