Remote MCP server with health_check, pricing_list, money_fact, and scheme_lookup tools; prompts as on Smithery. Docs: https://bankrolled.ai/llms.txt
Scored across 5 tools
health_check, pricing_list, and cross_border_check are clearly distinct, but money_fact and scheme_lookup both return deposit-insurance coverage amounts for a given country (e.g. 'how much is protected in the UK' could plausibly hit either FDIC/FSCS limit data). Descriptions mitigate this by framing scheme_lookup as identifier+URL and money_fact as the dated limit, but the boundary is thin and cross_border_check overlaps both when a non-resident question involves a single country's coverage figure.
All five names are snake_case noun phrases with a consistent domain_object_noun shape: cross_border_check, health_check, money_fact, pricing_list, scheme_lookup. Minor deviation: the set mixes verb-flavored suffixes (check, lookup) with pure-noun suffixes (fact, list) and never uses a leading verb, but the style is uniform and readable.
Five tools is a tight, well-scoped set for a read-only personal-finance facts service, with each tool mapping to a distinct access pattern (discovery, fact lookup, scheme lookup, cross-border query). health_check is infrastructure rather than a domain capability, which keeps it just short of ideal but is harmless.
The surface covers the natural lifecycle of this read-only domain: pricing_list for discovery, money_fact and scheme_lookup for direct lookups, and cross_border_check for the multi-country case, all with explicit not_in_catalog fallbacks. Gaps are minor — no free-text search over the catalog and coverage limited to five jurisdictions, though that scope is stated up front.
Answer cross-border money questions: deposit protection for non-residents, which schemes cover accounts held across borders. Returns sourced scheme information for both countries (from_country and to_country) with official regulator URLs and as_of dates. Covers US, UK, CA, AU, NZ. Free, no key. Unknown scenarios return not_in_catalog (never invents fees, FX rates, or coverage details).
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Topic key (default: deposit_insurance). | deposit_insurance |
| to_country | Yes | Destination country code: US, UK, CA, AU, or NZ (e.g. "UK" for UK bank account). | |
| from_country | Yes | Origin country code: US, UK, CA, AU, or NZ (e.g. "US" for US resident). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly and idempotent, and the description adds real behavioral context: sourced regulator URLs with as_of dates, no invented fees/FX/coverage, and a not_in_catalog fallback for unknown scenarios. That failure-mode disclosure is the valuable part; the cost/rate-limit profile ('free, no key') is a minor add.
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 verb and scope in the first clause, then return shape, then country coverage and safety guarantees. Four sentences, no filler, though 'Free, no key' is the least load-bearing line.
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?
No output schema exists, so the description carries the return contract, and it does: per-country scheme info, regulator URLs, as_of dates, and a documented not_in_catalog outcome. It stops short of stating what the agent should do on not_in_catalog or whether the two countries may be identical.
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 required country codes and the topic enum are already documented. The description only restates that results are returned for from_country and to_country, adding no formatting, case, or same-country guidance 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?
States a specific verb and resource: answering cross-border deposit-protection questions with sourced scheme info for a from_country/to_country pair. The cross-border, deposit-insurance framing plus the explicit country list implicitly separates it from siblings like scheme_lookup and money_fact, but no sibling is named.
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?
Implies when to use it (cross-border money questions about deposit protection for non-residents) and bounds the domain to US/UK/CA/AU/NZ. However, it never tells the agent when to prefer scheme_lookup or money_fact instead, leaving the routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liveness check. Returns ok and version. Free, no key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so safety and idempotence are covered elsewhere. The description adds value the annotations do not: it is free and requires no API key, which is meaningful auth information for an agent deciding whether it can call it. It also briefly states what comes back ('ok and version'), though it omits what happens on failure.
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 terse fragments, front-loaded with the operation type, then the return shape, then the access conditions. No filler, no redundancy, nothing that could be cut without losing information.
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-parameter, no-output-schema liveness probe with rich annotations, the description supplies everything an agent needs to call it correctly: what it does, what it returns, and that no auth is required. The only missing piece is failure/error behavior (e.g., whether it throws or returns a non-ok status), a minor gap for this tool class.
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 takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. No misleading parameter hints are present, and the schema is consistent with the description.
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 operation ('Liveness check') and even discloses the return payload ('ok and version'), which is more than a restatement of the name. Sibling tools are all in unrelated domains (cross_border_check, money_fact, pricing_list, scheme_lookup), so no differentiation is required. It stops short of a full sentence identifying the target resource, relying on the title for that.
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?
'Free, no key' implies the tool is safe to call without credentials and at no cost, which is indirect guidance that it can be used freely as a probe. However, it never states when to use this versus other tools, nor any preconditions or failure semantics. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an official, dated personal-finance limit: deposit insurance (FDIC, FSCS, CDIC, AU FCS, NZ DCS) or contribution limits and allowances (UK ISA, Lifetime ISA, Junior ISA, pension annual allowance, Personal Savings Allowance; US 401k + catch-ups, IRA, Roth IRA, HSA; Canada TFSA, RRSP, FHSA; Australia super concessional/non-concessional caps; NZ KiwiSaver government contribution). Use instead of memory when a user asks "how much is protected" or "how much can I contribute". Pass q as plain English ("fdic limit joint account", "isa allowance") or a fact_key from pricing_list. Returns fact, source {name,url}, as_of, jurisdiction, cite. Free, no key. Unknown -> not_in_catalog (never guesses).
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Plain-English question or fact_key, e.g. "fscs deposit protection limit" or "us_401k_limit_2026". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/openWorld/idempotent annotations: discloses the return fields (fact, source{name,url}, as_of, jurisdiction, cite), states the failure mode ('Unknown -> not_in_catalog (never guesses)'), and notes it is free with no key. No contradiction with annotations; only missing element is any rate/pagination detail, which is largely moot for a lookup.
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 capability and the usage rule; the long jurisdiction list is dense but genuinely informative for routing. Slight bloat in the enumerated allowance types, though each earns its place by signaling catalog breadth.
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 still describes the return payload and the not-found behavior. For a single-parameter read-only lookup, nothing an agent needs in order to call it correctly is missing.
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% and already has examples, so the baseline would be 3. The description adds real meaning by framing q as either free-form plain English or a fact_key sourced externally from pricing_list, which the schema does not say.
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 ('Get an official, dated personal-finance limit') and enumerates the exact categories of limits covered across five jurisdictions. An agent can distinguish it from scheme_lookup and pricing_list without 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?
Explicit trigger given: 'Use instead of memory when a user asks "how much is protected" or "how much can I contribute"'. It also names the alternative input source (a fact_key from pricing_list), giving the agent both when-to-use and where-else-to-look guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List everything this server covers: every money_fact fact_key with an example question, and every scheme_lookup country. Free (nothing on this server is billed); call first if unsure whether a fact is covered.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and closed-world, so the safety profile is covered. The description adds genuinely new information beyond those fields: that the call is free and that nothing on the server is billed, which is pricing context an agent cannot get from the annotations or schema. It also previews the response shape (keys with example questions, countries).
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-loads the scope and appends the routing directive; the parenthetical about cost is tucked in without breaking flow. No filler, no restatement of the title.
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 still conveys what comes back at a useful level of abstraction (fact keys plus example questions, country list). For a zero-param read-only discovery tool this is everything an agent needs before calling.
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 with an empty required-free schema, so there is nothing for the description to disambiguate. Baseline for a no-param tool 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 concrete verb (list) and two precise resources: every money_fact fact_key with an example question, and every scheme_lookup country. Naming money_fact and scheme_lookup directly ties it to the sibling tools, so an agent can tell this is the discovery/index tool rather than a lookup execution.
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?
"call first if unsure whether a fact is covered" gives an explicit conditional trigger, and the zero-arg free nature removes any cost barrier to over-calling. It stops short of naming the alternative path for when coverage is already known (call money_fact/scheme_lookup directly), so not a full when/when-not mapping.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify a country's deposit-insurance scheme and its headline coverage (US FDIC, UK FSCS, CA CDIC, AU FCS, NZ DCS) with the regulator's URL and as_of date. country accepts ISO codes or names: US/USA, UK/GB, CA, AU, NZ. Free, no key.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Topic key (default: deposit_insurance). | deposit_insurance |
| country | Yes | Country code or name: US/USA, UK/GB, CA, AU, NZ (e.g. "GB", "Canada"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and openWorld, so the safety profile is covered; the description adds value beyond that by disclosing the no-auth/free access model and the returned fields (regulator URL, as_of date). It does not say what happens for an unsupported country, which is the main remaining behavioral gap.
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: purpose and return fields first, accepted input forms next, access note last. The 'Free, no key' clause is short and earns its place, though it could be folded more smoothly into the sentence flow.
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 by naming the fields returned (scheme, headline coverage, regulator URL, as_of date). Auth and supported-country scope are covered; only the out-of-scope-country behavior is unaddressed.
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% and the country examples in the schema duplicate the ones in the description (US/USA, UK/GB, CA, AU, NZ), so little is added. The description also omits the topic parameter entirely, though its default makes that low-risk.
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?
Names a specific verb (identify) and resource (a country's deposit-insurance scheme) and enumerates the returns: headline coverage, regulator URL, as_of date. The named scheme list (FDIC, FSCS, CDIC, FCS, DCS) makes it unmistakable against siblings like money_fact or pricing_list.
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 five supported jurisdictions and the 'free, no key' note, which tells an agent it can call this without credentials. However, it never states when to prefer this over cross_border_check or money_fact, nor does it define behavior outside the five listed countries.
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.
cross_border_checkmoney_fact1 field changedInput schema / properties / q / examplesPrevious value: -[
- "fdic insurance limit",
- "fscs deposit protection limit",
- "isa annual contribution limit",
- "401k contribution limit",
- "tfsa contribution limit",
- "us_fdic_joint_accounts"
-]New value: +[
+ "fdic insurance limit",
+ "fscs deposit protection limit",
+ "isa annual contribution limit",
+ "401k contribution limit",
+ "tfsa contribution limit",
+ "us_fdic_joint_accounts",
+ "hsa contribution limit",
+ "rrsp contribution limit",
+ "super concessional contributions cap",
+ "lifetime isa limit"
+]money_fact2 fields changedInput schema / properties / q / descriptionPrevious value: -"A fact_key (exact) or a short search query. fact_keys: us_fdic_standard_limit, us_fdic_joint_accounts, uk_fscs_deposit_limit, uk_fscs_temporary_high_balance, ca_cdic_deposit_limit, au_fcs_deposit_limit, nz_dcs_deposit_limit, uk_isa_annual_limit, us_401k_limit_2026, us_401k_catch_up_2026, us_roth_ira_limit_2026, ca_tfsa_limit_2026."New value: +"Plain-English question or fact_key, e.g. \"fscs deposit protection limit\" or \"us_401k_limit_2026\"."Input schema / properties / q / examplesPrevious value: -[
- "us_fdic_standard_limit",
- "us_fdic_joint_accounts",
- "uk_fscs_deposit_limit",
- "uk_fscs_temporary_high_balance",
- "ca_cdic_deposit_limit",
- "au_fcs_deposit_limit",
- "nz_dcs_deposit_limit",
- "uk_isa_annual_limit",
- "us_401k_limit_2026",
- "us_401k_catch_up_2026",
- "us_roth_ira_limit_2026",
- "ca_tfsa_limit_2026",
- "fdic insurance limit",
- "fdic coverage joint accounts",
- "fscs deposit protection limit",
- "fscs temporary high balance",
- "cdic deposit insurance limit",
- "australia fcs deposit guarantee",
- "new zealand deposit compensation",
- "isa annual contribution limit",
- "401k contribution limit",
- "401k catch up contribution",
- "roth ira contribution limit",
- "tfsa contribution limit"
-]New value: +[
+ "fdic insurance limit",
+ "fscs deposit protection limit",
+ "isa annual contribution limit",
+ "401k contribution limit",
+ "tfsa contribution limit",
+ "us_fdic_joint_accounts"
+]scheme_lookup3 fields changedInput schema / properties / country / descriptionPrevious value: -"Country code: US, UK, CA, AU, or NZ. Example: \"CA\"."New value: +"Country code or name: US/USA, UK/GB, CA, AU, NZ (e.g. \"GB\", \"Canada\")."Input schema / properties / country / enumRemoved value: -[
- "US",
- "UK",
- "CA",
- "AU",
- "NZ"
-]Input schema / properties / country / examplesAdded value: +[
+ "US",
+ "GB",
+ "UK",
+ "CA",
+ "AU",
+ "NZ"
+]money_fact2 fields changedInput schema / properties / q / descriptionPrevious value: -"Short search query. Examples: \"fdic insurance limit\", \"uk isa annual limit\", \"tfsa contribution\", \"fscs deposit protection\"."New value: +"A fact_key (exact) or a short search query. fact_keys: us_fdic_standard_limit, us_fdic_joint_accounts, uk_fscs_deposit_limit, uk_fscs_temporary_high_balance, ca_cdic_deposit_limit, au_fcs_deposit_limit, nz_dcs_deposit_limit, uk_isa_annual_limit, us_401k_limit_2026, us_401k_catch_up_2026, us_roth_ira_limit_2026, ca_tfsa_limit_2026."Input schema / properties / q / examplesAdded value: +[
+ "us_fdic_standard_limit",
+ "us_fdic_joint_accounts",
+ "uk_fscs_deposit_limit",
+ "uk_fscs_temporary_high_balance",
+ "ca_cdic_deposit_limit",
+ "au_fcs_deposit_limit",
+ "nz_dcs_deposit_limit",
+ "uk_isa_annual_limit",
+ "us_401k_limit_2026",
+ "us_401k_catch_up_2026",
+ "us_roth_ira_limit_2026",
+ "ca_tfsa_limit_2026",
+ "fdic insurance limit",
+ "fdic coverage joint accounts",
+ "fscs deposit protection limit",
+ "fscs temporary high balance",
+ "cdic deposit insurance limit",
+ "australia fcs deposit guarantee",
+ "new zealand deposit compensation",
+ "isa annual contribution limit",
+ "401k contribution limit",
+ "401k catch up contribution",
+ "roth ira contribution limit",
+ "tfsa contribution limit"
+]scheme_lookup4 fields changedInput schema / properties / country / descriptionPrevious value: -"ISO-style country code: US, UK, CA, AU, or NZ. Example: \"CA\"."New value: +"Country code: US, UK, CA, AU, or NZ. Example: \"CA\"."Input schema / properties / country / enumAdded value: +[
+ "US",
+ "UK",
+ "CA",
+ "AU",
+ "NZ"
+]Input schema / properties / topic / descriptionPrevious value: -"Topic key (default: deposit_insurance). Example: \"deposit_insurance\"."New value: +"Topic key (default: deposit_insurance)."Input schema / properties / topic / enumAdded value: +[
+ "deposit_insurance"
+]health_checkmoney_factpricing_listscheme_lookup
Add one secure layer between your agents and this server.