Skip to main content
Glama
Sign In

Quartermaster eSIM

by io.github.dvirmimon123-tech
OverviewDiscussionsAdmin

Principal wallet

get_wallet
Read-only

Check the prepaid USD wallet of the principal you act for. Use it before get_quote or purchase to confirm funds, and after handing a top-up link to your principal to see it credited. Read-only. Returns balance, available funds (balance minus pending holds), open (unpaid) top-up links, top-ups awaiting confirmation, recent top-ups and recent ledger entries of the wallet of the principal you act for. Shared by all of the principal's agents. Amounts in minor units. topups_awaiting_confirmation: a payment was reported for these and is being confirmed with the payment provider; never send their links again, the balance updates once it is confirmed. frozen and debt: a top-up reversed by the payment provider (refund, cancellation, chargeback) is taken back from the balance; what the balance could not cover is a debt that blocks purchases until a top-up settles it. principal.partner_id: the partner the principal was attributed to at registration, if any.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_wallet"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoHow many recent top-ups and ledger entries to return, 1-100 (default 20)
agent_idNoYour agent id (or X-Agent-Id header)
agent_keyNoSecret returned by register_agent (or X-Agent-Key header)
principal_idNoThe principal you act for (or X-Principal-Id header)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / limit / description
      Previous value: -"Recent entries to return (default 20)"New value: +"How many recent top-ups and ledger entries to return, 1-100 (default 20)"
  2. Changed3 schema fields changed
    • addedInput schema / properties / agent_id / pattern
      Added value: +"^[A-Za-z0-9._:-]{3,128}$"
    • addedInput schema / properties / agent_key / maxLength
      Added value: +256
    • addedInput schema / properties / principal_id / pattern
      Added value: +"^[A-Za-z0-9._:@-]{3,128}$"
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true, but the description adds substantial context beyond that: the wallet is shared by all of the principal's agents, amounts are in minor units, topups_awaiting_confirmation must never have their links resent, and frozen/debt states block purchases until settled. These are non-obvious operational rules an agent could not infer from structured fields.

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?

Front-loads purpose and usage before the field-level semantics, and every sentence carries information. It is dense and long, but since no output schema exists the return-value explanations earn their place; minor tightening of the field glossary would be possible.

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

Completeness5/5

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

With no output schema, the description carries the full burden of explaining return values and does so thoroughly: balance, available funds, open top-up links, top-ups awaiting confirmation, recent top-ups, ledger entries, plus frozen/debt and partner_id semantics. Nothing an agent needs to interpret the response is missing.

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 description coverage is 100%, so all four parameters (limit, agent_id, agent_key, principal_id) are already documented in the schema. The description only indirectly implies that limit governs 'recent top-ups and ledger entries' and adds no format or default detail beyond the schema, so the baseline 3 applies.

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

Purpose5/5

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

States a specific verb and resource ('Check the prepaid USD wallet of the principal you act for') and immediately distinguishes itself from siblings by naming get_quote and purchase as downstream consumers. An agent can tell exactly what this tool returns without opening the schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use conditions: before get_quote or purchase to confirm funds, and after handing a top-up link to the principal to see it credited. It also implicitly excludes mutation by noting it is read-only, leaving no ambiguity about alternatives.

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

All Quartermaster eSIM toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources