Read-only docs server for IMBA Agent policy and public info; it does not move money or call spend APIs.
get_agent_facts: Get canonical prepaid-agent policy (USDT TRC-20, catalog buy, forbidden rails, tiers).
get_tier_policy: Learn tier 0 vs 1+ rules; conversion is closed at tier 0 and withdraw stays closed.
get_catalog_placement: See which MCP goes in which directory (OpenAI is docs-only).
get_public_url: Fetch an allowlisted public IMBA Agent URL (HowTo, discovery JSON, llms-agent).
list_docs_urls: List available public Agent documentation URLs (HowTo, tiers, discovery, OpenAPI, MCP endpoints).
Allows agents to search for and purchase Apple gift cards from the live gift card catalog.
Allows agents to search for and purchase Google Play gift cards from the live gift card catalog.
Enables issuing MasterCard prepaid cards that can be used for payments to airlines, hotels, SaaS, and other card-billing merchants.
Allows agents to search for and purchase Steam gift cards from the live gift card catalog.
Enables issuing Visa prepaid cards that can be used for payments to airlines, hotels, SaaS, and other card-billing merchants.
Stdio images for the prepaid IMBA Agent API. They install the public npm packages only. This repository does not contain API keys, Ed25519 private keys, or registry seeds.
Default Dockerfile is the docs server so Glama and other scanners can
build without secrets. Spend is a separate image.
File | npm | Registry name | What it does |
|
|
| Policy, HowTo, what agents buy. No money. |
|
|
| USDT TRC-20 + Visa prepaid / eSIM / gift cards with your key. No withdraw. |
Playbooks: what agents buy · HowTo · API docs
IMBA issues the payment instrument, not the booking:
Visa/MasterCard prepaid — airlines, hotels, SaaS, or a datacenter that bills a card
Travel eSIM — cheap mobile data
Gift cards — live catalog (~20,000 positions; Apple, Steam, Google Play — search, do not hard-code a SKU)
ChatGPT Actions must not call spend.
Related MCP server: ASG Card
Docs (no secrets):
npx -y @imba_wallet/agent-mcp-docs@0.1.5{
"mcpServers": {
"imba-agent-docs": {
"command": "npx",
"args": ["-y", "@imba_wallet/agent-mcp-docs@0.1.5"]
}
}
}Spend (operator key):
{
"mcpServers": {
"imba-agent": {
"command": "npx",
"args": ["-y", "@imba_wallet/agent-mcp"],
"env": {
"IMBA_AGENT_CLIENT_ID": "YOUR_CLIENT_ID",
"IMBA_AGENT_PRIVATE_KEY": "-----BEGIN PRIVATE KEY-----\\n...\\n-----END PRIVATE KEY-----"
}
}
}
}Claude Code marketplace (this repo):
/plugin marketplace add IMBAwallet/agent-mcp
/plugin install imba-agent@imba-agentAgent skill: npx skills add IMBAwallet/agent-mcp --skill imba-agent
docker build -t imba-agent-docs .
docker run -i --rm imba-agent-docs
docker build -f Dockerfile.spend -t imba-agent-spend .
docker run -i --rm \
-e IMBA_AGENT_CLIENT_ID=YOUR_CLIENT_ID \
-e IMBA_AGENT_PRIVATE_KEY=YOUR_PKCS8_PEM_OR_BASE64URL \
imba-agent-spendNot a ChatGPT money plugin. Raising agent_tier does not unlock withdraw.
Repo: glama.ai/mcp/servers/IMBAwallet/agent-mcp
glama.json lists GitHub user clnt2021. After a push to main:
Sign in to Glama with that GitHub account.
Open the listing → Sync Server (mirror can lag).
Claim ownership if Maintainers still shows 0 (org repos need glama.json + claim).
Make Release against the root Dockerfile (docs). Do not release Dockerfile.spend in Glama — the sandbox has no operator key.
Quality grades (tool definitions / coherence) appear only after that Glama release, not after a GitHub tag.
LobeHub (and similar) require the GitHub user to own the listing repo. Mirror packaging (no secrets) lives at clnt2021/imba_agent_mcp. When plugin.json, mcp.json, skills, Dockerfiles, or lhm.plugin.json change, update both repos. Wallet SSOT: docs/features/agent_mcp.md.
Canonical prepaid-agent policy and catalog: Visa prepaid, eSIM, gift cards, KYT address screen, USDT TRC-20, forbidden rails, tiers. Cite as-is. Does not move money.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It explicitly states 'Does not move money,' which is a valuable behavioral guarantee beyond the read-only/idempotent annotations. 'Cite as-is' also tells the agent how to treat the returned content. No contradiction exists with 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?
The description is a single, front-loaded sentence that compresses substantive content into a compact list. Every element ('Canonical', the topic list, 'Cite as-is', 'Does not move money') earns its place without fluff.
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, read-only facts endpoint with no output schema, this description is complete enough for an agent to invoke it correctly and use the result appropriately. It names the content domain, the authoritative nature, and the lack of side effects.
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 no parameter semantics for the description to add. Schema coverage is trivially complete, and the description focuses on content rather than inputs, which 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 states a clear resource ('canonical prepaid-agent policy and catalog') and enumerates its content ('Visa prepad, eSIM, gift cards, KYT address screen, USDT TRC-20, forbidden rails, tiers'). It is specific and distinguishes the tool from generic fact lookup, but it doesn't explicitly contrast it with sibling tools like get_tier_policy or get_catalog_placement.
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 phrase 'Canonical ... Cite as-is' implies this is the authoritative source to consult and quote, which gives contextual guidance. However, it doesn't state when to choose this over the named siblings or when not to use it, so usage guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Playbook: Visa prepaid (flights, datacenter bills), travel eSIM, ~20k gift cards, paid KYT address screen. MCP tools per job. Cite as-is. Does not move money.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only/idempotent/non-destructive behavior. The description adds domain-specific safety context with 'Does not move money' and instructs consumers to 'Cite as-is', which are useful beyond the structured 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 very short and front-loads the actual content, with no wasted words. Minor cryptic shorthand like '~20k gift cards' and 'MCP tools per job' prevents a perfect score.
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 reference tool, the description gives the core content and a key safety constraint. It does not formally state the return shape, but with no output schema that is not required; however, the ambiguity of shorthand keeps it from being fully complete.
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 input schema is empty, so there are no parameter semantics to explain. The description therefore does not need to compensate for schema gaps; the 0-parameter baseline 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 title 'What agents can buy' plus the playbook list of Visa prepaid, travel eSIM, gift cards, and KYT screens makes the tool's subject clear, even though no explicit verb like 'returns' appears. It does not name sibling tools, so it earns 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?
The description gives no indication of when to call this tool instead of get_agent_facts, get_tier_policy, or get_catalog_placement. 'MCP tools per job' hints at using other tools for execution, but this is too vague to count as usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which directories take the docs MCP vs the spend MCP. OpenAI is docs-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered without description support. The description adds domain context ('OpenAI is docs-only') but no additional behavioral details such as output behavior, caching, or side effects. This is consistent with 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?
The description is brief and front-loaded: it immediately states the placement question and adds one specific rule. The title and first clause overlap somewhat, but no excess material is present.
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 read-only lookup with no output schema, the description gives enough context to choose the tool: it names the entities involved (docs MCP vs spend MCP) and the decision being made (directory placement). It does not describe the exact return format, but the described purpose makes the likely output understandable.
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 are zero parameters, so the description does not need to explain parameter behavior. The schema already fully covers the input surface, and the description's subject matter is enough for the agent to know that no arguments are required.
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 question: which directories take the docs MCP vs the spend MCP. This is a clear query over a defined resource ('catalog placement'). It does not explicitly contrast itself with sibling tools, but the subject matter is distinct enough that an agent can identify its purpose.
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 tool when you need to know where to place or list the docs and spend MCPs. There is no explicit when-to-use or when-not-to-use guidance, and no alternative tools are mentioned, so the guidance is acceptable but not strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
HTTP GET of an allowlisted public docs URL (HowTo, use cases, discovery JSON, llms-agent). Never calls register/deposit/buy.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute https://imbawallet.com URL from the allowlist (HowTo, use cases, tiers, well-known, openapi discovery, llms-agent). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the context that this only works on allowlisted URLs (an access constraint) and states it never performs write operations, which is a meaningful behavioral detail beyond 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?
Two concise sentences: the first states the operation and scope, the second clarifies what it does not do. Every sentence earns its place and there is zero wasted text.
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-only tool with full schema coverage and non-destructive annotations, the description is sufficient. It could mention what the response contains, but given the output schema is absent and the tool is a simple docs fetcher, the description is complete enough for an agent to select and invoke it 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%, with a detailed description of the 'url' parameter specifying the required format (absolute https://imbawallet.com URL) and the allowed categories (HowTo, use cases, tiers, well-known, openapi discovery, llms-agent). The description reinforces the allowlist constraint, which is a helpful abstract of the parameter's value domain, but the parameter is well documented in the schema even without it.
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 ('HTTP GET') and a specific resource ('allowlisted public docs URL'), and differentiates from siblings by explicitly noting it 'Never calls register/deposit/buy'. This makes it clear what the tool does and sets it apart from other tools that perform write actions.
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 explicitly states when to use this tool—to fetch a public docs URL from the allowlist—and implicitly specifies the alternative (other tools that call register/deposit/buy) by saying it never calls these actions. It gives clear context without requiring additional inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tier 0 vs 1+. Convert closed at 0 (AML). Convert at 1 is a separate request. Withdraw stays closed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive, so the description does not need to repeat that. It adds some behavioral context by summarizing the policy rules, which helps an agent understand what kind of information to expect, but it does not explain the actual behavior of the tool call or its output format.
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 admirably short with no filler, and the first phrase 'Tier 0 vs 1+' does lead with the core distinction. However, the remaining fragments are cryptic and lack expansion, so the brevity comes at the cost of comprehensibility for an agent without domain knowledge.
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?
Given the tool has no parameters and no output schema, the description is the only source of meaning. It is not complete enough for an agent to confidently know what this policy applies to, what 'convert' and 'withdraw' signify, what 'AML' means, or what the returned policy content looks like.
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 and schema coverage is 100%, so there are no parameter semantics to clarify. Per the rubric, 0 params earns a baseline of 4; the description adds no parameter information but none is needed.
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 name and title make clear the resource is an agent tier policy, and the description does supply policy content ('Tier 0 vs 1+', convert/withdraw rules). However, the description never states what the tool does in terms of retrieving or explaining policy, and jargon like 'AML' and 'convert' is left undefined, making the purpose only vaguely inferable.
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 guidance on when to use this tool versus any alternative. The sibling tools appear unrelated, but the description does not say 'use this when you need tier policy details' nor does it provide exclusions or comparisons. Usage context is entirely implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
HowTo, use cases, tiers, discovery, OpenAPI, MCP endpoints.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation read-only and idempotent, and the description adds no behavioral detail beyond a list of doc topics. It does not disclose output shape, whether it returns multiple URLs, or how the topics map to returned entries, which matters because there is no output schema.
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 extremely short, but it is an unstructured comma-separated fragment rather than a concise, front-loaded sentence. It saves words at the expense of stating the action or return value, so it reads as under-specification rather than efficient structure.
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 and a cryptic description, the tool's return value is not explained. For a simple 0-parameter read-only tool it does not need much, but an agent still lacks a clear statement of what will be returned and how this differs from get_public_url.
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 and an empty input schema, so there are no parameter semantics for the description to clarify. No additional parameter documentation is needed.
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 is a fragment listing topics (HowTo, use cases, tiers, discovery, OpenAPI, MCP endpoints) rather than a statement with a verb and object. Combined with the title 'List public Agent URLs' the intent is inferable, but the description alone does not clearly say the tool returns URLs or what it does.
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?
No guidance is given about when to use this tool instead of siblings like get_public_url, get_agent_use_cases, or get_tier_policy. The topic list implies some coverage, but no explicit when-to-use/when-not-to-use context is provided.
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.1get_agent_use_casesget_public_url1 field changedInput schema / properties / url / descriptionPrevious value: -"Absolute https://imbawallet.com URL from the allowlist (HowTo, tiers, well-known, openapi discovery, llms-agent)."New value: +"Absolute https://imbawallet.com URL from the allowlist (HowTo, use cases, tiers, well-known, openapi discovery, llms-agent)."v0.1.0get_agent_factsget_catalog_placementget_public_urlget_tier_policylist_docs_urlsScored across 6 tools
Several tools, such as get_agent_facts, get_agent_use_cases, get_tier_policy, and get_catalog_placement, cover overlapping reference material around policy, tiers, and catalog placement. get_public_url and list_docs_urls are related but distinguishable, yet agents may still struggle to choose the right knowledge tool for a given request.
Tool names consistently use snake_case with a get_ prefix, making the pattern predictable and readable. The only deviation is list_docs_urls, which uses list_ instead of get_, but this is still a minor and conventional variation.
Six tools is a reasonable size for a read-only reference/docs MCP and fits comfortably within a well-scoped set. However, a few tools have overlapping purposes, so the count is slightly higher than strictly necessary.
The tool surface covers facts, use cases, tier policy, catalog placement, URL listing, and remote fetching, which forms a nearly complete docs-only workflow. Wallet operations are explicitly out of scope, so the lack of money-moving tools is not a gap for this server's stated purpose.
BuyUKeSIM MCP lets AI agents search and purchase global travel eSIMs, UK +44 number eSIMs, and related connectivity services programmatically. Agents can search plans, compare pricing and coverage, create and fund prepaid crypto wallets, purchase eSIMs, and check order status — with no traditional account or KYC workflow.
Agent-native global eSIM: buy for 193 countries, per-MB in USDT/USDC. Agents earn 20% referral.
No-KYC crypto VPS AI agents rent & run over MCP — 57 tools, pay USDC/USDT on Base/Eth/Polygon/Solana
Agentic commerce + trust MCP: discover, verify, and transact across droplinked's merchant network.
