Skip to main content
Glama
Sign In
BlindPay MCP Server

BlindPay MCP Server

by blindpaylabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Post Instances Customers Bank Accounts Offramp Wallets

PostV1InstancesCustomersBankAccountsOfframpWallets

Create an offramp wallet linked to a customer bank account, selecting the blockchain network and optional partner fee for stablecoin payouts.

Instructions

Create Offramp Wallet

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "instance_id": "<instance_id>",
      "customer_id": "<customer_id>",
      "bank_account_id": "<bank_account_id>",
      "requestBody": "<requestBody>"
    },
    "name": "PostV1InstancesCustomersBankAccountsOfframpWallets"
  }
}

Input Schema

NameRequiredDescriptionDefault
customer_idYesCustomer ID
instance_idYes
requestBodyYes
Idempotency-KeyNoOptional key to safely retry this request without performing the action twice. Retrying with the same key and an identical body replays the original response; reusing a key with a different body returns an error. Keys are kept for 24 hours.
bank_account_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.10.0
    • addedInput schema / properties / requestBody / properties / partner_fee_id
      Added value: +{
+  "description": "Partner fee charged on every payout created from a deposit to this wallet. Null means no partner fee.",
+  "example": "pf_000000000000",
+  "maxLength": 15,
+  "minLength": 15,
+  "type": [
+    "string",
+    "null"
+  ]
+}
  2. Addedv1.9.3

TDQS

C2.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered externally. The description adds no context of its own: it doesn't say what a created wallet enables, whether creation is reversible, or that a bank account must already exist. Note that the schema offers an Idempotency-Key header while idempotentHint=false; the description is silent on this tension, which it could have resolved.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three words contain no wasted text and the verb is front-loaded, so it satisfies the letter of conciseness. However, the brevity comes from omission rather than precision — there is no second sentence adding scope or behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a five-parameter creation tool with a required nested object containing an enum, no output schema, and only partial schema documentation, so the description carries the remaining burden. 'Create Offramp Wallet' leaves out which chain to pick, what the partner-fee field does, and what the call returns, making it inadequate for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 40%, so the description is expected to compensate, and it does not. It never mentions the required nested requestBody field 'network' (a 15-value enum of chains) or the optional external_id and partner_fee_id fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The phrase 'Create Offramp Wallet' does supply a verb plus a resource that separates it from the sibling Get/Put/Delete offramp-wallet tools. But it only restates what the name 'PostV1InstancesCustomersBankAccountsOfframpWallets' already conveys and omits the scoping detail visible in the path: the wallet is created under a specific instance, customer, and bank account.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Nothing says when to create an offramp wallet rather than, say, a blockchain wallet (PostV1InstancesCustomersBlockchainWallets) or a regular wallet (PostV1InstancesCustomersWallets), which are all present as siblings. There are no prerequisites, no mention of required bank-account state, and no exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools