MCP server for minia2a.uk — the x402 micropayment marketplace for AI agents.
🚀 Claude Code auto-mode ready (Aug 14, 2026). Let your AI agent discover, call, and pay for 1,680+ services using the x402 protocol with built-in USDC micropayments. 5 free trial calls per registered wallet (self-custody wallet + EIP-191 signature) — no API keys, no subscriptions, pay-per-call. .agent-budget v1.1 support for safe autonomous spending.
npm install -g minia2a-mcpRelated MCP server: Agoragentic
Add to your Claude Code MCP config (~/.claude/.mcp.json):
{
"mcpServers": {
"minia2a": {
"command": "npx",
"args": ["-y", "minia2a-mcp"]
}
}
}Add to claude_desktop_config.json:
{
"mcpServers": {
"minia2a": {
"command": "npx",
"args": ["-y", "minia2a-mcp"]
}
}
}minia2a_list_servicesBrowse available x402 services. Filter by category or search term.
minia2a_get_serviceGet detailed info about a specific service — price, endpoint, schema, docs.
minia2a_get_statsPlatform statistics — total services, agents, transaction volume, uptime.
minia2a_registerRegister with a self-custody wallet + EIP-191 signature — get 5 free trial calls to start. If you don't supply a wallet, one is generated for you and the private key returned.
minia2a_creditsExplain the V5 credit/trial model + platform stats. (V5 has no per-wallet balance endpoint — credits decrement automatically per call.)
minia2a_buy_creditsClaim credits from a completed USDC on-chain transfer by submitting your transaction hash.
minia2a_call_serviceCall any x402 service. Two access paths, in the order the gateway tries them:
Wallet trials — pass privateKey (or set MINIA2A_PRIVATE_KEY) for a registered wallet's
5 free trial calls. The key stays in this process; it only signs
the per-call message minia2a trial:<wallet>:<serviceId>:<unixSeconds>, and just the signature
goes over the wire. wallet= on its own reaches nothing — the signature is what does.
Payment — when the wallet's trials are spent the tool returns the 402 accepts[] array to settle.
The response reports trialMode (wallet / ip) and trialRemaining straight from the gateway's
headers, so you can see which path actually paid for the call rather than inferring it.
minia2a_check_endpoint ← NEW in v1.1.3Validate any x402 endpoint for Claude Code auto-mode readiness (Aug 14, 2026). Checks 9 signals: HTTP reachability, JSON content-type, 4 payment headers (amount/chain/token/recipient), trial info, registration path, and /api/agent-ready handshake. Returns a scored report with per-check PASS/FAIL detail.
minia2a.uk is a marketplace where AI agents buy and sell services from each other. Built on the x402 protocol (HTTP 402 Payment Required), every API call includes automatic USDC micropayment — no subscriptions, no API keys, no monthly bills.
1,680+ x402 services — crypto, web, AI, data, and more
USDC settlement across 8 chains — Base, Algorand, and more
5 free trial calls per registered wallet (self-custody wallet + EIP-191 signature)
Claude Code auto-mode ready — .agent-budget v1.1 support, machine-readable 402 body
Claude Code auto mode becomes the default on August 14. Agents can now autonomously discover, trial, and pay for APIs — with hard budget caps, classifier safety checks, and machine-readable payment headers.
minia2a is auto-mode ready:
/api/agent-ready — machine-readable handshake with payment info, registration endpoint, and quickstart
402 body: accepts[] array (amount/asset/network/payTo/scheme) — agent parses full payment instruction (x402 V2)
.agent-budget v1.1 — 7-field autonomous-purchasing controls (per-call / per-task / confirmation / dedupe / settlement / audit)
5 free trial calls per registered wallet — try any paid endpoint
{
"version": "1.1",
"daily_limit_usdc": 5,
"max_per_call_usdc": 1,
"per_task_limit_usdc": 3,
"confirmation_threshold_usdc": 0.5,
"idempotency_key": "required",
"verify_settlement": true,
"audit_trail": true
}x402 is an open protocol that extends HTTP 402 Payment Required for machine-to-machine micropayments. Services declare their price in HTTP response headers, and clients pay in USDC on Base. No intermediaries, no settlement delays. x402 Foundation launched July 2026 under the Linux Foundation with 40+ founding members including Visa, Mastercard, Stripe, and Cloudflare.
Learn more at x402.org.
minia2a offers multiple integration paths depending on your stack:
Package | Use Case | Install |
minia2a-mcp (this) | MCP server for Claude, Cursor, Codex |
|
CLI for @x402/express developers |
| |
ElizaOS agent plugin |
| |
General-purpose SDK |
|
minia2a.uk — the marketplace
MCP Registry — find this server on the official registry
MIT
Claim credits from a completed USDC transfer. Send USDC on a supported chain (Base, Algorand, etc.) to the minia2a platform wallet, then submit the transaction hash here to credit your wallet. V5 has no in-app balance purchase — top-ups are claimed from an on-chain transfer.
| Name | Required | Description | Default |
|---|---|---|---|
| txHash | Yes | The transaction hash of your USDC transfer to the platform wallet | |
| wallet | Yes | Your wallet address that sent the USDC | |
| agentName | No | Optional agent name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, and the description adds meaningful behavioral context: this is a claim operation tied to an on-chain transfer rather than an in-app purchase. It explains the required workflow and outcome, though it does not detail irreversibility, duplicate submission handling, or verification requirements beyond the transfer.
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 compact and front-loaded with the core purpose. Every sentence earns its place: the first defines the action, and the second explains the necessary on-chain workflow and product constraint. No filler or redundant restating of the tool name.
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's mutation-oriented nature and lack of an output schema, the description adequately covers the preconditions, action, and expected outcome. It could be even more complete with a note about what response to expect after submission or a pointer to verify resulting credits, but the essential information for correct invocation is present.
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 schema already provides 100% parameter coverage with clear descriptions for wallet and txHash. The description reinforces the workflow by connecting the transaction hash to the claiming process, but it does not add substantial new meaning beyond the schema for the parameters themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Claim credits') and the precise context: a completed USDC transfer whose transaction hash is submitted to credit a wallet. It also distinguishes this from a generic purchase by stating V5 has no in-app balance purchase, helping differentiate it from sibling tools like minia2a_credits.
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 explicit usage steps: send USDC on a supported chain to the platform wallet, then submit the transaction hash. It also states that there is no in-app purchase alternative. However, it does not explicitly mention when not to use the tool or point to a sibling for related actions like checking credit balance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call an x402 service on minia2a.uk. Three access paths: (1) omit everything for the paid 402 path (register a wallet for 5 free trial calls); (2) pass privateKey (or set MINIA2A_PRIVATE_KEY) for your registered wallet's own 5 trials — the key never leaves this process, it only signs the per-call trial message; (3) when both are exhausted the endpoint returns HTTP 402 with a machine-readable accepts[] array — pay in USDC and retry with a PAYMENT-SIGNATURE header (x402 V2). Set autoPay:true together with privateKey to have a 402 paid automatically in USDC on Base and the call retried — the wallet must hold USDC or the call still returns payment_required (never charges silently). Note that wallet= on its own does NOT reach the wallet bucket; the signature is what does.
| Name | Required | Description | Default |
|---|---|---|---|
| params | No | JSON parameters to send to the service | |
| wallet | No | Your registered self-custody wallet address (0x...). Without privateKey this alone does not draw on the wallet's trial bucket. | |
| autoPay | No | When true and a privateKey is available, a 402 Payment Required response is paid automatically in USDC on Base via x402 and the call retried. Default false — you get a payment_required response instead of any automatic charge. Empty wallet (no USDC) still returns payment_required. | |
| serviceId | Yes | The service ID (e.g., 'x402-gas') or full endpoint path | |
| privateKey | No | Private key of the registered wallet, used locally to sign the trial message (EIP-191). Never transmitted — only the resulting signature is sent. Falls back to the MINIA2A_PRIVATE_KEY env var. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses real behavioral details: the private key never leaves the process, only the signature is transmitted, automatic payment never silently charges, and a 402 response triggers manual or automatic payment handling. No contradiction with the annotations exists.
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 dense but well-structured with numbered access paths, followed by the autoPay caveat and a critical final note about wallet. Every sentence earns its place and there is no repetition of the 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?
The tool has a complex payment/trial model, and the description fully covers trial buckets, 402 handling, automatic payment, security, and failure conditions. A generic success return format cannot be defined since output depends on the called service, but the x402 flow is well specified.
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 already 100%, and the description adds essential meaning beyond the schema: the privateKey is used locally for EIP-191 signing, autoPay requires privateKey and USDC, and wallet alone does not access the wallet trial bucket. These details materially affect how parameters must be combined.
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 opens with a specific verb and resource: 'Call an x402 service on minia2a.uk', then explains three distinct access paths. This clearly separates it from sibling metadata, registration, and stats tools.
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 explicit guidance on exactly when to use each mode: omit everything for the paid path, pass privateKey for trial calls, and enable autoPay with privateKey for automatic 402 payment. It also states an important exclusion: wallet alone does NOT reach the wallet bucket.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate any x402 endpoint for Claude Code auto-mode readiness (Aug 14, 2026). Checks 9 signals: HTTP reachability, JSON content-type, 4 payment headers (x-402-amount/chain/token/recipient), trial info, registration path, and /api/agent-ready handshake. Returns a score (0-100%) with per-check PASS/FAIL detail. Use this before calling a paid endpoint to verify it works with autonomous agents.
| Name | Required | Description | Default |
|---|---|---|---|
| endpointUrl | Yes | The endpoint URL to validate (e.g., 'https://minia2a.uk/x402/gas') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses the nine validation signals, the return format (score 0-100%), and the per-check PASS/FAIL detail. This accurately sets expectations for behavior and output without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but every component adds value: purpose, check list, return format, and usage note. The date and parenthetical example are minor extras, but the text is generally tight and front-loaded.
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 validation tool with no output schema, the description adequately covers what it checks, what it returns, and when to use it. It does not mention failure behavior or network prerequisites, but these are not essential for correct selection and invocation.
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 already covers the single parameter (endpointUrl) with 100% description coverage and an example. The description adds no additional parameter semantics beyond the schema, so the baseline of 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 ('Validate'), a specific resource ('any x402 endpoint'), and a concrete purpose ('Claude Code auto-mode readiness'). It enumerates the exact checks, making it clearly distinguishable from siblings like minia2a_list_services and minia2a_call_service.
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 explicitly states 'Use this before calling a paid endpoint to verify it works with autonomous agents', which gives a clear when-to-use instruction. It does not mention when-not-to-use or alternatives, but the pre-call usage directive is actionable and sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain the V5 credit/trial model and report platform-level stats. Note: V5 has no per-wallet balance endpoint — credits decrement automatically when you call a service with ?wallet=. Remaining trials are surfaced per-call via X-Trial-* headers or the 402 body.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
This goes well beyond the readOnlyHint annotation by disclosing key non-obvious behavior: no per-wallet balance endpoint, automatic credit decrement via ?wallet=<your-wallet>, and trial visibility through X-Trial-* headers or the 402 body. This is exactly the kind of context an agent needs to avoid incorrect assumptions. No contradiction 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?
Three sentences with no wasted words. The main caveat about the missing per-wallet balance endpoint is front-loaded in the second sentence, and the final sentence adds useful headert/response details without padding.
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 informational tool, the description is largely complete and the V5-specific note is valuable. The main gap is that 'platform-level stats' is vague and the description does not specify which stats are returned or how they relate to minia2a_get_stats.
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 the baseline is 4. The description even enriches context by mentioning the ?wallet=<your-wallet> query parameter used in service calls, even though it is not an input to this tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a verb and resource: 'Explain the V5 credit/trial model and report platform-level stats.' It is unambiguous that this is an informational/read-only tool, but it does not explicitly differentiate from the sibling minia2a_get_stats, which may also report platform-level stats.
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 implies when to use it — for credit/trial model questions — and the note warns the agent that V5 has no per-wallet balance endpoint, which prevents a common misuse. However, it does not explicitly state when to prefer this over minia2a_get_stats or provide when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific x402 service on minia2a.uk, including its price, endpoint URL, input schema, and usage instructions. Use this before calling a service to understand what it needs.
| Name | Required | Description | Default |
|---|---|---|---|
| serviceId | Yes | The service ID or name to get details for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the read-only safety is covered. The description adds useful context about what information is returned (price, endpoint URL, input schema, usage instructions), similar to adding a scoping constraint. It does not go into deeper behavioral traits like rate limits or error behavior, but for a simple read-only lookup this is adequate.
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 filler. The main purpose is front-loaded, and the usage guidance is packed into a short second sentence. Every word 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 single-parameter, read-only tool with no output schema, the description is nearly complete: it states what the tool does, what it returns, and when to use it. It could mention that serviceId typically comes from minia2a_list_services, but that is a minor gap rather than a significant omission.
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 parameter serviceId is already documented as 'The service ID or name to get details for.' The description does not add additional meaning beyond the schema, such as how to discover valid serviceIds or format expectations. This meets the baseline but does not exceed 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 clearly states the verb ('Get detailed information') and the specific resource ('a specific x402 service on minia2a.uk'), and lists the payload (price, endpoint URL, input schema, usage instructions). It distinguishes itself from sibling tools like minia2a_list_services (specific vs. list) and minia2a_call_service (preparation vs. invocation).
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 says 'Use this before calling a service to understand what it needs,' which is a clear when-to-use directive. It does not name alternative tools or provide when-not-to-use conditions, but the context is strong enough to guide an agent to the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current platform statistics for minia2a.uk — total services, registered agents, transaction volume, uptime, and more. Useful for understanding the marketplace's scale and health.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes that this is a read-only operation. The description adds context about the kind of statistics returned (services, agents, transaction volume, uptime) but does not disclose additional behavioral details such as data freshness, response format, or any limitations. This is acceptable given the annotation coverage but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no wasted words. The action and resource are front-loaded, followed by concrete examples and a use case. The only minor flaw is the vague 'and more', but it does not meaningfully detract from the clarity.
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 statistics tool, the description provides enough context for an agent to decide when to call it. However, the absence of an output schema means the agent is left guessing about the exact response shape, and the description does not specify return format or whether the stats represent a snapshot or aggregated totals.
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, and the schema coverage is effectively 100%, so there is no parameter semantics burden on the description. The description appropriately clarifies what the tool returns rather than parameter details, which would be irrelevant here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get'), a specific resource ('current platform statistics for minia2a.uk'), and enumerates the kinds of data included. This differentiates it from sibling tools like minia2a_list_services or minia2a_get_service without requiring the agent to open schemas.
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 'Useful for understanding the marketplace's scale and health' provides clear context for when this tool should be used. It does not explicitly name alternatives or exclusion conditions, but the purpose is distinct enough that an agent can infer the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available x402 services on minia2a.uk — the micropayment marketplace for AI agents. Returns service name, description, price, and endpoint for each service. Use this to discover what capabilities are available before calling them.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max number of results to return (default 20) | |
| search | No | Search term to filter services by name or description | |
| category | No | Filter by category (e.g., 'crypto', 'utility', 'data', 'ai') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true, the safety profile is already disclosed. The description adds useful behavioral context by stating this is a pre-call discovery step and enumerating what the listing returns (name, description, price, endpoint), reinforcing that it is non-mutating and informational.
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 with no filler. The main action is front-loaded, the return contents are summarized, and the usage intent is stated in a single clause.
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 read-only list operation with fully documented parameters and no output schema, the description fully covers what the tool does, what it returns, and when to use it. Nothing essential 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 description coverage is 100%: limit, search, and category each already have meaningful descriptions. The tool description adds no parameter-specific semantics beyond the schema, 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 begins with a specific verb and resource: 'List available x402 services on minia2a.uk'. It clearly distinguishes itself from siblings like call_service or get_service by framing this as the discovery/listing operation that precedes invocation.
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 says 'Use this to discover what capabilities are available before calling them', giving a clear when-to-use signal. It does not mention when not to use it or contrast with get_service, but the intended usage context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register for minia2a.uk with a self-custody wallet + EIP-191 signature and get 5 free trial calls. If you don't provide a wallet+signature, this tool generates a fresh wallet, signs 'minia2a register: ' with EIP-191, registers it, and returns the private key — store it, the platform never holds it. 5 free trial calls per registered wallet across all services.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | A name for your agent (e.g., 'my-trading-bot') | |
| wallet | No | Your existing self-custody wallet address (0x...). Omit to have a fresh wallet generated for you. | |
| signature | No | EIP-191 signature of 'minia2a register: <wallet>'. Required if you supply a wallet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the destructiveHint annotation by explaining side effects: wallet generation, private key return, platform non-custody, and per-wallet trial limits. It does not describe every possible failure mode, but it reveals the key behaviors an agent should know before invoking it.
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 compact and front-loaded. The first sentence gives the core purpose and reward; the second explains the optional-input behavior and security implications; the last clarifies the trial scope. Every sentence contributes, with 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?
For a tool with no output schema, the description covers the main behaviors well: registration, trial calls, wallet generation, private key return, and custody. The only notable gap is that the return value for the supplied-wallet path is not specified, but the provided information is sufficient for correct invocation in the common cases.
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?
Input schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics by explaining the EIP-191 signature content, the dependency between wallet and signature, and the fallback behavior when wallet/signature are omitted. This is genuinely useful 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 states a specific verb and resource: register for minia2a.uk using a self-custody wallet and EIP-191 signature, with a concrete outcome of 5 free trial calls. This clearly distinguishes it from sibling tools like minia2a_credits or minia2a_call_service, which serve different purposes.
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 clearly explains the two usage modes: provide an existing wallet+signature, or omit them and have the tool generate a fresh wallet. It does not explicitly state when not to use the tool or name alternatives, but the conditional guidance is strong and actionable.
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. Dates show when Glama detected each change.
v1.0.0minia2a_buy_creditsminia2a_call_serviceminia2a_check_endpointminia2a_creditsminia2a_get_serviceminia2a_get_statsminia2a_list_servicesminia2a_registerThe tools mostly target distinct actions—listing services, getting details, registering, buying credits, calling services, and checking endpoints—so an agent can usually select correctly. The main overlap is that minia2a_credits also reports platform-level stats like minia2a_get_stats, and the payment-related paths in buy_credits and call_service could cause mild confusion.
Six of eight tools follow a clear minia2a_<verb>_<noun> pattern, and all names share a consistent prefix and snake_case style. minia2a_register is a verb-only name and minia2a_credits is a noun-only name, which breaks the otherwise predictable pattern.
Eight tools is well within the ideal range and each one covers a meaningful part of the x402 marketplace workflow. The size feels intentional: discovery, registration, payment, calling, and validation are all represented without unnecessary duplication.
The set supports the full consumer loop: discover services, inspect them, register a wallet, understand credits, buy/claim credits, call services, and validate endpoints. The only notable gap is the lack of a direct balance or transaction-history view, but the V5 design intentionally surfaces that state through call responses and 402 headers.
Marketplace where AI agents buy datasets and API access, pay per call in USDC over x402.
A machine-to-machine agent superstore -- paid API services for autonomous agents via x402 on Base.
Pay-per-use tool API for AI agents. Free tier, x402 USDC micropayments, or API key.
Pay for HTTP APIs and charge for your own: x402 micropayments in USDC on Base.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/minia2auk/minia2a-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server