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., "@banking-access-index-mcp Check which US banks explicitly accept or restrict applicants from India"
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 over the Global Solo Banking Access Index: what 19 US business banking providers publish about applicants who are not US tax residents but own a US LLC, across 8 countries (India, China, UK, Canada, Pakistan, Nigeria, Turkey, Brazil).
Every cell carries the source URL it came from and the date that URL was read.
# from GitHub, no npm account involved
npx github:global-solo/banking-access-index-mcpA model answering "can someone in India open a Mercury account" is drawing on provider marketing pages absorbed at training time, undated. When the underlying index was built, an adversarial re-verification pass re-fetched every source and discarded the claims whose quotes were absent, misread, or overreached: 239 of 268 mined claims survived. The 29 that did not were not edge cases. They were provider statements that read as settled until someone opened the page again.
So the thing this server adds is not coverage. It is a date next to each claim, and a refusal to convert silence into a yes.
Related MCP server: Moon Banking MCP Server
Country cells are tri-state, plus unknown. The distinction the whole dataset rests on:
Status | Meaning |
| The provider publishes a statement that covers applicants in this country. |
| The provider publishes a restriction that covers this country. |
| The country is absent from the published restriction list, and no acceptance statement was located. Absence is not an answer. |
| No published position was located. |
Two discriminators travel alongside, because one label was hiding materially different evidence:
restrict_kind — named_on_prohibited_list · absent_from_closed_eligibility_list ·
blanket_rule_no_country_named. The outcome for the reader is identical across all three. The
provenance is not, and this dataset is about the provenance.
unknown_kind — no_policy_published · mentioned_for_other_purpose ·
absent_from_non_exhaustive_list · conflicting_sources.
Both are carried through the MCP boundary rather than flattened into the status.
Tool | What it returns |
| Per-provider published status for one country, with evidence URLs, access dates, and both discriminators. Optionally narrowed to one provider. |
| The full record for one provider across every dimension held in the index (entity, residency, rails, receive, card, phone/2FA, FDIC, onboarding, marketplace), each with its own evidence. |
| Filter by provider type, non-resident stance, SSN/ITIN handling, or by the status carried in a named country. |
| Scope, verification date, the methodology prose, evidence tiers, and |
Every response carries the status glossary, the limits below, and a provenance block.
The server fetches the live dataset from
https://www.globalsolo.global/data/banking-access-index.json at startup and falls back to the
snapshot bundled in this package if that fetch doesn't complete. Which one answered is reported in
every response as provenance.origin, rather than being hidden behind a single answer.
Each cell reports what a provider publishes, not what it does at underwriting. An application can be declined on grounds no published page covers.
A claim can go stale between its access date and now. The date is in the response for that reason.
Coverage is 19 providers × 8 countries. A provider or country absent here was not assessed, which is a different thing from assessed-and-negative.
dimension_provenance lists the dimensions added after the adversarial pass. Those are
single-pass research and do not sit at the same confidence as the core.
Dataset page: https://www.globalsolo.global/data/banking-access-index
Archived with a DOI: 10.5281/zenodo.21336392
Methodology: https://www.globalsolo.global/about/methodology
Licence: CC BY 4.0 — attribute as Global Solo Banking Access Index.
Server code: MIT. Dataset: CC BY 4.0.
Look up what each US business banking provider publishes about applicants resident in a given country. Returns the published status per provider with the source URL and access date behind it. A status of no_published_restriction means the country is absent from a published restriction list — it is not an acceptance statement.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Country of residence of the founder. | |
| provider | No | Optional provider id to narrow to one row, e.g. "mercury". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosure, and it does this well by stating the return shape (status per provider, source URL, access date) and by flagging the crucial semantic caveat that no_published_restriction is absence from a restriction list, not an acceptance statement. It does not mention data-freshness or failure behavior, but the access-date field mitigates freshness concerns.
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 sentences with no wasted words: the first states the action and scope, the second summarizes the return payload, and the third clarifies a potentially misleading status value. Each 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?
For a low-complexity lookup with no output schema, the description explains the return fields and the key status semantics sufficiently. Combined with a fully documented schema, an agent has everything needed to invoke the tool correctly.
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 both the country enum and the optional provider parameter. The description does not add parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Look up') and names a concrete resource: what US business banking providers publish about applicants in a given country. It clearly distinguishes itself from siblings like list_providers and get_provider by framing the operation as cross-provider, country-scoped lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to call this tool: whenever you need published banking-access information for a country across providers. It does not explicitly mention when-not-to-use it or name alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report what this dataset covers, when it was last verified, how many claims it holds, and where its methodology and DOI archive live. Read this before treating an absent claim as an answer.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does this well by surfacing a non-obvious caveat: an absent claim in the dataset should not be interpreted as a definitive answer without first checking this tool. It omits minor details like auth or return formatting, but those are less critical for a read-only metadata endpoint.
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 with no wasted words: the first enumerates exactly what the tool reports, and the second delivers a practical usage warning. The structure is front-loaded and 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?
For a tool with no parameters, no annotations, and no output schema, the description covers the essential return contents and the critical usage context. It could have explicitly described the response format, but the prose list of what the tool reports is sufficient for an agent to invoke it correctly and interpret its role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to explain. The baseline for a 0-parameter tool is 4, and the description appropriately focuses on the tool's purpose instead of inventing unnecessary parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Report') and names the exact resource (the dataset), then enumerates what the tool returns: scope, freshness, claim count, methodology, and DOI archive. This clearly differentiates it from the sibling tools about banking access and providers.
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 second sentence gives explicit guidance: call this before treating an absent claim as an answer, which tells the agent when its output is essential. It does not name sibling alternatives or state when not to use the tool, but the usage context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the full evidence-cited record for one provider across every dimension held in the index (entity, residency, rails, receive, card, phone/2FA, FDIC, onboarding, marketplace) plus its per-country statuses. Each claim carries its source URL and the date that URL was read.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes | Provider id, e.g. "mercury", "wise-business", "relay". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does well: it reveals the output structure (all ten dimensions plus per-country statuses) and the evidence-citation behavior (each claim carries its source URL and the read date). For a read-only fetch tool, this transparently communicates what the agent will receive.
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 with zero filler. The core purpose is front-loaded ('Return the full evidence-cited record for one provider'), followed by the dimension list and the citation format detail. Every clause earns its place; no redundant restatement of the title or schema.
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 single-parameter read tool with no output schema, the description is largely complete: it enumerates the returned dimensions, per-country statuses, and the evidence format (source URL + read date). The only gaps are error behavior for unknown provider ids and any access requirements, which are minor for a fetch operation.
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% — the sole 'provider' parameter is documented with format guidance and examples. The description adds no parameter-level detail beyond the schema, so the baseline of 3 applies. The evidence-cited framing in the description is about the output, not the input.
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 verb ('Return'), a precise resource ('full evidence-cited record for one provider'), and a comprehensive scope ('across every dimension held in the index' plus per-country statuses). It is clearly distinguished from siblings: list_providers returns many, check_banking_access is a narrow access check, and dataset_info is metadata — none overlap with a full single-provider record fetch.
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 singular focus ('for one provider') implies this is the tool for a single detailed lookup versus list_providers for a collection, but the description never explicitly states when to prefer this tool or names alternatives. The guidance is implied by the wording rather than stated, leaving the agent to infer the selection logic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the providers in the index, filtered by type, non-resident stance, SSN/ITIN handling, or by the status they carry in one specific country. Returns summary rows; use get_provider for the evidence behind any one of them.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Only meaningful together with `country`. | |
| country | No | Filter by the status carried in this country. Pairs with `status`. | |
| ssn_itin | No | ||
| provider_type | No | ||
| non_resident_stance | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it does disclose key behavior: it lists providers, supports filtering, and returns summary rows rather than full evidence. It also points to get_provider for deeper details character. It does not clarify whether filters combine with AND/OR or what happens with no filters, but the core output-granularity behavior is transparent.
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 tightly worded sentences with no filler. The first sentence states the operation and filter options; the second adds the return-granularity caveat and routes the agent to get_provider for details. All information 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?
For a list tool with 5 optional filters, no output schema, and no annotations, the description is largely complete: it specifies the action, the filter dimensions, and the summary-row return nature. It stops short of explaining whether filters can be combined or whether the result is paginated, but these are minor gaps for a straightforward list endpoint.
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 only 40% (status and country have descriptions) while ssn_itin, provider_type, and non_resident_stance lack schema descriptions. The tool description compensates partially by mapping 'type' to provider_type, 'non-resident stance' to non_resident_stance, and 'SSN/ITIN handling' to ssn_itin, but it does not explain the meaning of individual enum values or how parameters interact beyond what the schema already covers.
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 verb ('List'), a resource ('providers in the index'), and the filtering dimensions (type, non-resident stance, SSN/ITIN handling, status by country). It also differentiates from the sibling get_provider by explicitly saying this tool returns summary rows and get_provider provides the evidence behind any one.
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 a clear usage context: use this tool to list/filter providers, and use get_provider when you need the detailed evidence behind a single provider. It does not explicitly mention when to use/avoid the other siblings (check_banking_access, dataset_info), but their names and the stated purpose make the boundary clear enough.
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.0check_banking_accessdataset_infoget_providerlist_providersScored across 4 tools
Each tool has a distinct role: check_banking_access answers a specific country lookup, get_provider returns full evidence for one provider, list_providers filters/summarizes the provider set, and dataset_info explains dataset scope/methodology. There is no meaningful overlap or ambiguity between them.
Tool names follow a consistent verb_noun pattern (check_banking_access, get_provider, list_providers, dataset_info). The only minor deviation is dataset_info, which uses a noun phrase rather than a verb, but it is still clear and predictable.
Four tools is a reasonable, focused set for a read-only reference index. It is slightly on the smaller side, but each tool serves a distinct and necessary function, so the count feels appropriate rather than thin.
The tool surface covers the full user journey for this domain: discover dataset scope, list/filter providers, check a specific country's status, and retrieve full evidence for a provider. No obvious gaps exist for a read-only index; the dataset_info tool explicitly addresses the risk of treating absent claims as answers.
Query Bancadia's registry of US business checking account products with structured filters.
Citable US facts w/ curated query templates: SEC financials, bank call reports, nonprofits. No key.
Cross-border payment & banking intelligence for AI agents: SWIFT/BIC, IBAN, sanctions, FX, tracking.
Confirm a US business is real and find who controls it. 32.6M official registry records.
