Skip to main content
Glama
Sign In
BlindPay MCP Server

BlindPay MCP Server

by blindpaylabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get Instances Customers Wallets Yield History

GetV1InstancesCustomersWalletsYieldHistory
Read-onlyIdempotent

Retrieve a customer wallet’s yield history by instance, customer, and wallet ID, with optional date-range and token filters.

Instructions

Retrieve Wallet Yield History

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": "GetV1InstancesCustomersWalletsYieldHistory"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
toNoLast day, UTC, inclusive. Defaults to today.
fromNoFirst day, UTC, inclusive. Defaults to 30 days before `to`. The window is capped at 366 days.
tokenNo
customer_idYesCustomer ID
instance_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.9.3

TDQS

C2.4/5.0
Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds no behavioral context of its own — no mention of pagination, the 366-day window cap, or what a yield history record contains.

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, front-loaded, zero waste — but the brevity is under-specification rather than discipline. There is no sentence that earns its place because there is essentially only the title.

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?

With 6 parameters (3 required), no output schema, and an undocumented token enum, an agent needs more to call this correctly. The description does not explain what a wallet yield history returns, whether results are time-bucketed, or how it differs from the related yield-transactions endpoint.

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%: the 'id', 'instance_id' and 'token' parameters carry no description, and 'id' is a required 15-char wallet identifier that is easily confused with the sibling paths. The description does nothing to clarify parameter meaning, so it fails to compensate for the coverage gap.

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 'Retrieve Wallet Yield History' names a verb and resource, so an agent can roughly tell what it returns. But it is essentially the title restated and does not distinguish it from sibling tools like GetV1InstancesCustomersWalletsYield or GetV1InstancesCustomersWalletsYieldTransactions, leaving the yield-history variant ambiguous.

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 guidance on when to call this versus the other wallet-yield endpoints (Yield, YieldTransactions, YieldEnable/Disable) or the plain wallet endpoints. The only hint at usage is the schema's from/to defaults, which is not in the description.

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