Skip to main content
Glama
Sign In
BlindPay MCP Server

BlindPay MCP Server

by blindpaylabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get Instances Customers Wallets Deposits

GetV1InstancesCustomersWalletsDeposits
Read-onlyIdempotent

Retrieve incoming stablecoin deposits for a managed customer wallet, sorted newest first, with filters for token, status, and pagination.

Instructions

Incoming stablecoin deposits to a managed wallet, newest first.

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>",
      "id": "<id>"
    },
    "name": "GetV1InstancesCustomersWalletsDeposits"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
limitNoNumber of items to return
tokenNo
statusNo
customer_idYesCustomer ID
instance_idYes
ending_beforeNoA cursor for use in pagination. ending_before is an object ID that defines your place in the list.
starting_afterNoA cursor for use in pagination. starting_after is an object ID that defines your place in the list.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.10.0
    • changedInput schema / properties / token / enum
      Previous value: -[
-  "USDC",
-  "USDT",
-  "USDB"
-]New value: +[
+  "USDC",
+  "USDT",
+  "USDB",
+  "EURC",
+  "EURB"
+]
  2. Addedv1.9.3

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description's only added behavioral fact is the 'newest first' sort order, which is genuinely useful. It says nothing about pagination behavior, default page size, or whether filters combine, leaving the mutation/read story fully to annotations.

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

Conciseness4/5

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

A single front-loaded clause with zero filler and the resource stated first. It is efficient, though the terseness is arguably part of why the gaps above exist.

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

Completeness2/5

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

For an 8-parameter list endpoint with three required IDs, half the schema undocumented, and no output schema, this one line is not enough. An agent can guess the intent but cannot confidently construct a correct call without knowing what `id` identifies or how the enum filters behave.

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

Parameters2/5

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

Schema coverage is only 50% across 8 parameters, and the description adds no parameter meaning at all. Most notably, the required `id` field has no schema description, so the agent cannot tell whether it is the wallet ID, a deposit ID, or something else; the `token` and `status` enum filters are also unexplained. With a coverage gap this large, the description should have compensated and does not.

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 description names a specific resource and direction ('Incoming stablecoin deposits to a managed wallet') plus an ordering ('newest first'), which is far more informative than the tautological tool name. It does not, however, distinguish itself from nearby siblings like GetV1InstancesPayins or GetV1InstancesCustomersWalletsYieldTransactions, so an agent must infer the boundary.

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?

There is no explicit when-to-use guidance, no mention of prerequisites (an instance, a customer, and a wallet id all appear required), and no named alternative for retrieving inbound vs. outbound money movement. The agent is left to infer that this is the deposit-listing endpoint from the one-line purpose alone.

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