Neutral, cited central-bank rate decisions, calendars, inflation releases and bond auctions.
Scored across 7 tools
Each tool targets a distinct purpose: single-bank snapshot (bank_status), settlability check (check_question), data-quality overview (dataset_health), source metadata (resolution_sources), correction submission (submit_correction), auctions (upcoming_auctions), and decisions (upcoming_decisions). There is mild overlap between bank_status and dataset_health (both report freshness) and between bank_status and upcoming_decisions (both touch rate decisions), but the descriptions clearly scope past-facts vs. cross-bank trust vs. forward calendar.
All names use snake_case consistently, which is the dominant pattern. However the grammatical style varies across noun phrases (bank_status, dataset_health, resolution_sources), verb phrases (check_question, submit_correction), and adjective phrases (upcoming_auctions, upcoming_decisions), a minor deviation from a single predictable convention.
Seven tools is well within the ideal 3-15 range for a macro data index. Each tool has a clear, non-redundant role spanning read, meta, health, and write operations, so none feel padded or missing.
The surface covers the core lifecycle well: upcoming and observed decisions, auctions, source resolution, freshness, question settlability, and corrections. Minor gaps exist, such as no direct historical rate-series or bulk bank-listing operation, but agents can work around these via bank_status and upcoming_decisions.
One bank: the policy rate in force and since when, the last observed decision with its statement, the next meeting, past facts computed from observed decisions only (days since the last change, consecutive holds, counts of past move sizes), freshness and data warnings.
| Name | Required | Description | Default |
|---|---|---|---|
| bank | Yes | Bank id (e.g. "reserve-bank-of-india", "ecb", "cbrt"), name, common abbreviation (RBI, SNB, BoJ) or country |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuine behavioral context beyond that: derived facts are 'computed from observed decisions only' (a provenance/accuracy caveat) and the response includes 'freshness and data warnings', telling the agent to expect staleness signals rather than raw data.
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, front-loaded with the scope marker 'One bank:', with no filler. It is dense and slightly list-like, but every enumerated item corresponds to a real returned field, so nothing is wasted.
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 no output schema, the description carries the burden of previewing return contents and does so field-by-field. Gaps remain: nothing about behavior for an unknown or ambiguous bank id, or whether history beyond the last change is retrievable, but these are minor for a read-only one-param 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%, and the schema itself documents the accepted bank id forms (slug, name, abbreviation, country), so the baseline of 3 applies. The description's 'One bank:' phrasing reinforces cardinality but adds no format or matching semantics 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 names the resource (one bank) and enumerates exactly what the payload contains: policy rate and its start date, last observed decision plus statement, next meeting, derived past facts, and data warnings. That is specific enough to distinguish a single-bank snapshot from the list-oriented siblings like upcoming_decisions, though it never explicitly contrasts itself with 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?
There is no explicit when-to-use, when-not-to-use, or alternative named. The 'One bank:' prefix implies single-bank scope versus a cross-bank tool, but the agent must infer that on its own, and nothing explains overlap with upcoming_decisions (which also covers meetings).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Is a question about a rate decision or a government bond auction settleable, when, and on which source? Finds the bank (or the auction issuer, tenor) and the date in the text. Refuses a decision or auction that has not been observed: a decision settles only after its statement is observed on the bank's own page, an auction only once the issuer's result is recorded (it says when bidding closes, closeAt in UTC, and on which result page). Also says when the source has not yet met the reads bar (5 right, 0 wrong).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The question, e.g. "Will the RBI raise its repo rate on 7 Oct 2026?" or "Will the German 30-year Bund auction on 14 Oct 2026 have a bid-to-cover above 1.5?" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description then adds substantial behavior beyond that: it refuses unobserved decisions/auctions, explains the observation precondition for settlement, returns closeAt in UTC and a result page, and reports the 'reads bar' (5 right, 0 wrong). The jargon ('settleable', 'reads bar') is not fully defined, which keeps it from 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?
The purpose is front-loaded as a leading question, followed by extraction logic, settlement preconditions, and source health. It is dense but every sentence adds information; the main cost is a long, clause-heavy middle sentence that could be tightened.
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 no output schema, the description must convey return semantics, and it does: settleability verdict, timing, source, closeAt in UTC, and result page, plus a refusal case. It stops short of describing the exact response shape or fields, so it is strong but not exhaustive.
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?
There is a single required parameter with 100% schema description coverage, including examples, so the schema carries the documentation burden. The description adds that it extracts the bank/issuer, tenor, and date from the text, but no syntax or format guidance beyond that. Baseline 3 is appropriate for high-coverage schemas.
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 function: parse a natural-language question about a rate decision or bond auction and report whether it is settleable, when, and on which source. That is a specific verb+resource and goes well beyond the tautological title. It does not explicitly name a sibling (e.g., resolution_sources) to differentiate, which keeps it at 4 rather than 5.
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: call this when you have a question text and need to know if it can be settled and by what source. However, there is no explicit when-not guidance and no named alternatives among siblings like resolution_sources or bank_status, so the agent must infer routing. Adequate but with a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Freshness per bank (last observed decision, next meeting, days to it, whether its decision statement is resolvable) and the publisher-gate warnings. Use to judge how far to trust an answer.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that it returns publisher-gate warnings and freshness fields, which is useful, but it doesn't explain caveats like staleness thresholds or what a warning implies. Modest added context over 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?
Two sentences, front-loaded with what's returned, followed by the use case. Tight and readable, though the parenthetical field list is dense.
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 zero-param read-only tool with no output schema, the description gives a reasonable picture but leaves the return shape informal and doesn't clarify relationship to bank_status or how to interpret publisher-gate warnings in practice.
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?
Zero parameters, so baseline is 4. The description correctly implies no inputs are needed and instead describes the returned dimensions.
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 specific resource (dataset freshness) and enumerates the returned fields (last decision, next meeting, days to it, resolvability) plus publisher-gate warnings. It's clear what the tool surfaces, though it doesn't explicitly distinguish itself from the closest sibling, bank_status.
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 gives a clear usage context: 'Use to judge how far to trust an answer.' That's a strong when-to-use signal, but it doesn't name alternatives like bank_status or resolution_sources or state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The kinds of page a bank publishes (decision statement, calendar, rate history, press feed): where each URL is found, its pattern (for recognising a page, never for building one), a real example, the reads recorded on it, and whether it is resolvable.
| Name | Required | Description | Default |
|---|---|---|---|
| bank | Yes | Bank id (e.g. "reserve-bank-of-india", "ecb", "cbrt"), name, common abbreviation (RBI, SNB, BoJ) or country | |
| resolvable_only | No | Only sources that meet the reads bar |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safe read profile (readOnlyHint=true, openWorldHint=false), so the lower bar applies. The description goes beyond them by disclosing the return shape (location, pattern, example, recorded reads, resolvability) and the important constraint that patterns are for recognition only, never URL construction.
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 densely-packed sentence, front-loaded with the resource under discussion ('The kinds of page a bank publishes') and using a parenthetical list to carry the field enumeration efficiently. Every clause earns its place; no filler.
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 no output schema, the description carries the burden of describing the return value, and it does so field-by-field. For a two-parameter, read-only lookup whose schema is fully documented, an agent has enough to call it correctly; only the per-bank result shape (list vs. object) is left implicit.
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 baseline is 3. The description's mention of 'the reads recorded on it, and whether it is resolvable' loosely explains what the 'reads bar' in the resolvable_only schema means, but adds no syntax or format detail beyond the schema itself.
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 enumerates exactly what the tool returns for a bank: source kinds (decision statement, calendar, rate history, press feed), URL location, pattern, example, recorded reads, and resolvability. The resource is specific and distinct from siblings like bank_status or dataset_health, though the tool's own verb is only implied 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 rather than stated: the parenthetical 'for recognising a page, never for building one' warns how the pattern may be used, but the description never says when to reach for this tool versus siblings like dataset_health or bank_status, nor any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report a mistake with the URL of the bank's own page that proves it. The report is public and is checked like any other claim; it never changes the data by itself. Returns the report id and where to follow it.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | https URL of the page that proves the correction (ideally the bank's own) | |
| bank | No | Bank id, if the report is about a covered bank | |
| evidence | Yes | What is wrong and what is right, 10 to 2000 characters |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only mark it as a non-destructive, non-idempotent write with openWorldHint=false. The description goes well beyond that by disclosing that the report is public, is reviewed like any other claim, does not itself change the data, and returns a follow-up location – valuable context for a mutation tool. It does not mention permissions or rate limits, keeping it short of 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?
Three short sentences, front-loaded with the core action and evidence requirement, followed by behavior and return info. No sentence is filler, though the phrasing 'with the URL ... that proves it' is slightly tangled.
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 only 3 fully documented parameters and no output schema, the description covers the essentials an agent needs: what to supply, that the effect is a public, reviewed report rather than an immediate data change, and what it returns. Auth requirements and error cases remain unstated, so it is not exhaustive.
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 url, bank, and evidence with constraints (HTTPS, 10-2000 chars). The description only echoes that the URL should be the bank's own proving page, adding no syntax or format detail beyond the schema. Baseline 3 applies.
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 verb (report a mistake / submit a correction) and the resource it concerns (a bank page that proves it), so an agent immediately knows this files a correction report. It is self-evidently distinct from siblings like bank_status or resolution_sources, but it makes no explicit attempt to differentiate itself from 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?
Usage is implied: use this when you have a mistake to report plus a URL proving it. However, it gives no explicit when-to-use/when-not guidance and never points to alternatives (e.g. check_question for queries), so an agent must infer the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Government bond auctions in a date window, soonest first: US Treasury, the German Finanzagentur and the Italian Treasury, calendar and results. Each has the auction day, closeAt (the bidding deadline in UTC), instrument, tenor, CUSIP/ISIN and size once known, status (scheduled, announced, held, cancelled), the issuer's result page and its format, and the result (yield, bid-to-cover, allotted) only once the issuer has published it. Facts only, no forecasts.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End date YYYY-MM-DD; default from + 60 days | |
| from | No | Start date YYYY-MM-DD; default today | |
| issuer | No | us-treasury, de-finanzagentur or it-mef (or a name: "Treasury", "Germany", "Italy"); default all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true and openWorldHint=false; the description goes well beyond them by disclosing ordering, the closeAt bidding deadline in UTC, the status lifecycle (scheduled, announced, held, cancelled), and the fact that results appear only after issuer publication. It stops short of pagination limits, data freshness, or coverage caveats, so it is strong but not exhaustive.
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?
Front-loaded with the core scope and ordering, then a single dense sentence enumerating returned fields. Every clause carries information, though the long field inventory makes it read more like documentation prose than a crisp tool summary.
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 no output schema, the description carries the return-value burden and does so thoroughly, listing the auction day, closeAt, instrument, tenor, CUSIP/ISIN, size, status, result page/format, and result fields plus their availability timing. Combined with fully documented parameters, an agent has everything needed to call and interpret it.
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%, with each of from/to/issuer documented including defaults and accepted issuer codes, so the baseline is 3. The description adds nothing about parameter format or interactions beyond what the schema already states.
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 (government bond auctions) narrowed by issuer scope (US Treasury, German Finanzagentur, Italian Treasury) and a date window, and states the ordering (soonest first). An agent can distinguish it from siblings like upcoming_decisions or dataset_health without opening the 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?
Usage context is implied by 'date window, soonest first' and the closing 'Facts only, no forecasts', which signals a read-only calendar rather than an analytics tool. However, it never says when to prefer this over a sibling tool or what preconditions apply (e.g., what happens when no auctions fall in the window).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Policy-rate decisions in a date window, soonest first: decision day (local to the bank), announcement time in UTC where the bank publishes one, whether the date is on the bank's calendar, moved or unscheduled, the rate going in, and the decision once observed. Covers 21 central banks (Banco Central do Brasil, Bank Indonesia, Bank of Canada, Bank of England, Bank of Japan, Bank of Korea, Bank of Mexico, Central Bank of the Republic of Türkiye, Czech National Bank, European Central Bank, Federal Reserve (Federal Open Market Committee), Magyar Nemzeti Bank, Narodowy Bank Polski, Norges Bank, People's Bank of China, Reserve Bank of Australia, Reserve Bank of India, Reserve Bank of New Zealand, South African Reserve Bank, Sveriges Riksbank, Swiss National Bank) and 2 inflation release series.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End date YYYY-MM-DD; default from + 60 days | |
| from | No | Start date YYYY-MM-DD; default today | |
| banks | No | Only these banks; default all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: results are ordered soonest-first, decision day is local to the bank while announcement time is UTC where published, and 'the decision once observed' signals that future rows may lack an outcome — a meaningful data-completeness cue.
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?
Purpose and ordering are front-loaded in the first clause, and every field is listed compactly. The 21-bank enumeration is long but serves as an at-a-glance coverage signal for the unconstrained banks parameter; it is verbose but not filler.
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 no output schema, the description correctly compensates by enumerating the returned fields, coverage, ordering, and time-zone semantics. It stops short of stating pagination or result-size limits, which a window-based listing tool would benefit from.
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%, with from/to defaults and the flexible bank matching (id, name, abbreviation, country) already documented in the schema. The description adds time-zone framing ('local to the bank') but no extra parameter syntax or edge-case meaning, so baseline 3 applies.
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 and scope: 'Policy-rate decisions in a date window, soonest first.' It then enumerates exactly what each row carries (decision day, announcement time, calendar/moved/unscheduled flag, rate in, observed decision), which separates it cleanly from siblings like upcoming_auctions and bank_status.
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 by the date-window framing and the listed coverage (21 banks, 2 inflation series). It never says when to prefer this over upcoming_auctions, nor when a decision row is absent or not yet observable. An agent can infer the context but gets no explicit routing or exclusion guidance.
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.
bank_statuscheck_questiondataset_healthresolution_sourcessubmit_correctionupcoming_auctionsupcoming_decisionsFX macro context: CPI, NFP, PCE, ISM PMIs, Fed, ECB, BoE, BoJ, historical analogs, FX reactions.
Point-in-time macro, central bank rates and sentiment, COT positioning, from official sources.
Macroeconomic and market data for AI agents: rates, credit, volatility, calendars and screeners.
Official economic statistics, company filings, earnings calls and market data, with sources cited.
Add one secure layer between your agents and this server.
