Instant Base + Solana wallets, free and x402-payable. US bank account after a 2-min check.
Scored across 4 tools
Most tools are clearly distinct: create_account, check_status, get_wallets, and get_funding_details each have a unique purpose. There is slight overlap between get_wallets and get_funding_details since both expose a Base USDC address, but the descriptions clarify the verification and chain differences well.
All tool names follow a consistent verb_noun pattern: check_status, create_account, get_funding_details, get_wallets. No mixed naming styles or ambiguous verbs, making the surface highly predictable.
Four tools is well-scoped for the stated purpose of wallet creation, bank funding details, and verification status. Each tool earns its place with no redundant or missing core operations for the domain.
The surface covers account creation, wallet retrieval, funding details, and verification status, which are the core workflows. Minor gaps exist—there is no tool for initiating transfers, viewing transaction history, or closing an account—but these are outside the stated scope of wallets and funding details.
Where the person is in bank verification: awaiting_verification, in_review, approved or declined. Call this after they open the verification link — approval usually takes about two minutes. Their wallets already work regardless of what this says.
| Name | Required | Description | Default |
|---|---|---|---|
| onboarding_token | Yes | The token returned by create_account. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden and does add useful behavioral context: approval timing and the fact that wallets already work regardless of status. It does not explicitly state read-only behavior, but the status-oriented wording makes the non-mutating nature reasonably clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: status enumeration, when to call, and a practical caveat. It is front-loaded and has no redundant or filler language.
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 simple one-parameter status check with no output schema, the description adequately conveys the possible return values and operational timing. It could be slightly more explicit about the response shape, but the enumerated statuses make the tool fully actionable.
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?
Parameter schema coverage is 100%, so the schema already documents onboarding_token as 'The token returned by create_account.' The description adds timing context but no additional parameter-level detail, 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 clearly states the tool reports bank verification status with the exact possible values: awaiting_verification, in_review, approved, or declined. This distinguishes it from sibling tools like create_account, get_funding_details, and get_wallets, which all address different resources.
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 timing guidance: 'Call this after they open the verification link' and 'approval usually takes about two minutes.' It does not explicitly discuss exclusions or alternatives, but the guidance is clear for the primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a Glide account for a person. Returns their wallets immediately — Base and Solana, both able to receive USDC and both x402-payable — with no verification and no fee. Also returns a verification link, which is optional and only needed for bank rails (a US account, USD, EUR and other currencies); it is usually approved in about two minutes. Safe to call twice with the same email: it returns the same account rather than making a second one. Returns an onboarding_token — keep it, every later call needs it.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The person's email address. Their welcome letter and bank details are sent here. | ||
| phone | No | Optional phone number in E.164 form, e.g. +14155551234. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers: it discloses idempotency, immediate wallet provisioning, no-fee/no-verification behavior, the optional verification link's purpose, expected approval time, and the requirement to retain onboarding_token for later calls. These are behavioral facts not present in any structured field.
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 four sentences and front-loads the core action and immediate outputs. It is information-dense but mostly earns its length; a little trimming, such as the enumeration of currencies, would make it tighter, so it is not a 5.
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 two-parameter creation tool with no output schema or annotations, the description is unusually complete: it names the returned artifacts (wallets, verification link, onboarding_token), explains their significance, and covers idempotent retry. An agent has enough to invoke it correctly and know what to do with the result.
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 documents both parameters at 100% coverage, so the baseline is 3. The description adds context that the email is where the welcome letter and bank details are sent, but this is already stated in the schema, and it adds no new semantics for the phone parameter.
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 opening sentence uses a specific verb and resource: 'Open a Glide account for a person.' It clearly establishes this as the account creation/onboarding tool and is unmistakably distinct from siblings like check_status, get_funding_details, and get_wallets, which all describe read operations.
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 clear context for when to call it: it has no verification and no fee, and it explicitly says calling twice with the same email is safe and idempotent. It also scopes the optional verification link to bank-rails use. However, it does not name sibling alternatives or state when to prefer get_wallets instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The US bank account — account number and routing number — plus the USDC address on Base. This is the banking half, so it needs verification to be approved; before that it refuses. On and off ramps are free. For a wallet address that works right now, without verification, use get_wallets.
| Name | Required | Description | Default |
|---|---|---|---|
| onboarding_token | Yes | The token returned by create_account. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that the tool refuses to work until verification is approved, and adds useful context that on/off ramps are free. It could mention error behavior more explicitly, but the refusal behavior is clearly communicated.
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 content, followed by the verification behavior, cost context, and sibling alternative. Every sentence adds value and no space is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter retrieval tool with no output schema, the description explains what is returned, the verification prerequisite and refusal behavior, cost implications, and the correct alternative tool. An agent has enough context to select and invoke this tool appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter is already documented as 'The token returned by create_account.' The tool description adds no further detail about the onboarding_token parameter, so it neither enhances nor harms parameter understanding beyond the baseline.
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 what the tool provides: US bank account details (account and routing numbers) plus the USDC address on Base. It also distinguishes itself from the sibling get_wallets by framing this as the 'banking half' that requires verification.
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?
Explicitly states when the tool is appropriate: when banking details are needed and verification has been approved. It also gives a concrete alternative, get_wallets, for cases where a wallet address is needed without verification, leaving no ambiguity about which sibling to choose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The person's Base and Solana wallet addresses, plus the x402 endpoint on each chain that lets any agent pay them in USDC. Works from the moment the account exists: no verification, no fee, nothing to set up. Receiving is free and unlimited; moving the balance into a US or EUR bank account is the part that needs verification.
| Name | Required | Description | Default |
|---|---|---|---|
| onboarding_token | Yes | The token returned by create_account. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden and does well: it discloses zero setup, no verification requirement, free and unlimited receiving, and the verification needed for bank transfers. It does not mention error behavior or side effects, but for a simple retrieval-style tool this is substantial transparency.
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 concise sentences, each earning its place: the first defines the returned resource, the second establishes availability and prerequisites, the third clarifies limits. The most important content is front-loaded and there is no redundant phrasing.
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 tool with no output schema, the description is sufficiently complete: it states what the tool returns, when it works, and the key behavioral constraints. It could mention return format or error cases, but an agent has enough information to invoke and interpret 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 baseline of 3 applies. The description adds no meaning beyond the schema for onboarding_token, but the schema already fully documents that it is the token returned by create_account. No contradiction or gap in parameter understanding.
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 resource: the person's Base and Solana wallet addresses plus x402 endpoints. It lacks an explicit imperative verb like 'retrieves' and does not name siblings, but the tool name and content make the operation unambiguous and distinct from check_status, create_account, and get_funding_details.
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 provides clear context on when the tool is usable ('Works from the moment the account exists: no verification, no fee, nothing to set up') and explains the boundary between receiving USDC and moving funds to a bank. It does not explicitly name alternatives or state when not to use it, 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_statuscreate_accountget_funding_detailsget_walletsAgents-only x402 economy on Base + Solana testnets: identity, swaps, invoicing, streaming.
72 x402 endpoints: trading, AI inference, blockchain, escrow. USDC on Base+Solana.
320 AI models + 2,720 pay-per-call APIs. x402 USDC on Base or Solana, no API key.
Payment rails for AI agents. Pay merchants in USDC on Base. Dual-protocol: x402 + OKX APP.
Add one secure layer between your agents and this server.
