Skip to main content
Glama
Sign In
BlindPay MCP Server

BlindPay MCP Server

by blindpaylabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Post Instances Customers Virtual Accounts

PostV1InstancesCustomersVirtualAccounts

Creates a virtual account to automatically convert inbound USD deposits (ACH, wire, RTP) into stablecoins sent to a linked wallet, with deposit-based fees and optional partner fees.

Instructions

Creates a virtual account that automatically converts inbound USD deposits (ACH, wire, RTP) into stablecoins sent to the linked wallet. Fees on these automated payins depend on the deposit amount: deposits below $100.00 accrue the BlindPay fee to your billing cycle (charged at the end of the month via the payin's billing_fee_amount), while deposits of $100.00 or more are charged at the time of the transaction (deducted from the delivered amount via transaction_fee_amount). Every deposit is processed regardless of size and always delivers at least $0.01 on-chain; a partner fee (optional partner_fee_id) is collected only from what remains after that.

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>",
      "requestBody": "<requestBody>"
    },
    "name": "PostV1InstancesCustomersVirtualAccounts"
  }
}

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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.10.0
    • changedInput schema / properties / requestBody / properties / banking_partner / enum
      Previous value: -[
-  "jpmorgan",
-  "citi",
-  "hsbc",
-  "cfsb",
-  "portage",
-  "bre_b",
-  "spei"
-]New value: +[
+  "jpmorgan",
+  "citi",
+  "hsbc",
+  "cfsb",
+  "portage",
+  "bre_b",
+  "spei",
+  "portage_g"
+]
  2. Addedv1.9.3

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare this is a non-read-only, non-idempotent, non-destructive write with open-world effects, and the description goes well beyond them: it explains the fee timing split at the $100 threshold, which field (`billing_fee_amount` vs `transaction_fee_amount`) is affected, the $0.01 minimum delivery guarantee, and that partner fees only draw from the remainder. It omits permissions/auth requirements and what the created resource looks like, keeping it from a 5.

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?

The core action is front-loaded in the first sentence, but the remaining two-thirds of the text is dense fee arithmetic that is better suited to documentation and does not help an agent decide whether or how to invoke the tool. Nothing is padded with filler, but the balance of content is off.

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

Completeness3/5

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

For a mutation with a nested required request body (banking_partner, token, blockchain_wallet_id) and no output schema, the description covers downstream money flow well but leaves the agent guessing about required body semantics, the purpose of `bre_b`, and what the response returns. Annotations cover the safety profile, so the gap is moderate rather than severe.

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

Parameters3/5

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

Schema coverage is 50%, so the description needs to compensate and only partly does: it explains `partner_fee_id` semantics (optional, collected from the remainder after the $0.01 minimum) and hints at the linked wallet for `blockchain_wallet_id`. It says nothing about the required `token`, `banking_partner`, `bre_b`, or the sole-proprietor document fields, which have zero schema descriptions.

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

Purpose4/5

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

The first sentence gives a specific verb and resource ('Creates a virtual account') plus the defining behavior (converts inbound USD deposits into stablecoins sent to a linked wallet). This clearly separates it from the Get/Put virtual-account siblings, though no sibling is named explicitly.

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

Usage Guidelines3/5

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

Usage is only implied: it is evidently the creation endpoint for a virtual account tied to a customer and blockchain wallet. There is no explicit statement of when to choose this over, say, creating a bank account or wallet first, nor any prerequisite/ordering guidance for the linked wallet and partner fee.

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