Quartermaster eSIM

Register agent and mandate

register_agent

Create your agent identity, bound to a principal (the wallet owner), with a spending mandate: the first call to make in this store. Use it when you have no agent_key yet, or to add another agent for a principal you already have. Returns agent_key once (store it and send it on every later call) and, for a brand-new principal_id, principal_key once. Example: {agent_id: "trip-planner-1", principal_id: "principal:acme", mandate: {max_per_tx: 3000, max_per_day: 6000, max_per_month: 20000, expiry: "2027-01-01T00:00:00Z"}} lets the agent spend up to 30.00 USD per purchase. Details: The first agent of a new principal_id also receives principal_key (once): the principal owns the wallet, and every later register_agent for that principal_id must present principal_key (argument or X-Principal-Key header), else PRINCIPAL_KEY_REQUIRED. New agents are capped by the registration policy (see get_policies); only active agents (not revoked, mandate unexpired) count toward max_agents_per_principal. To extend or change an existing agent's mandate, use renew_mandate. Agents brought by a partner of the store also send partner_id and partner_key (both or neither): a new principal is attributed to that partner for good. Invalid partner credentials give PARTNER_INVALID; an existing principal keeps the attribution it was created with (PARTNER_MISMATCH for another partner, PARTNER_ATTRIBUTION_LOCKED if it has none). Attribution changes nothing about prices or limits.

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": {
      "agent_id": "<agent_id>",
      "principal_id": "<principal_id>",
      "mandate": "<mandate>"
    },
    "name": "register_agent"
  }
}

Input Schema

Name	Required	Description
`mandate`	Yes	Spending limits this agent is bound by, in minor units (cents); see get_policies for the caps the store allows
`agent_id`	Yes	An id you choose for this agent: 3-128 characters, letters, digits and . _ : - (for example trip-planner-1)
`partner_id`	No	Only if a partner of the store brought you: its partner_id (send with partner_key)
`partner_key`	No	The partner's partner_key (send with partner_id)
`principal_id`	Yes	The wallet owner you act for: 3-128 characters (for example principal:acme); all of its agents share one wallet
`principal_key`	No	Required if the principal already exists (or X-Principal-Key header)

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedNov 9, 2026

addedInput schema / properties / agent_id / description

Added value: +"An id you choose for this agent: 3-128 characters, letters, digits and . _ : - (for example trip-planner-1)"

addedInput schema / properties / mandate / description

Added value: +"Spending limits this agent is bound by, in minor units (cents); see get_policies for the caps the store allows"

addedInput schema / properties / mandate / properties / allowed_categories / description

Added value: +"Product categories the agent may buy (default [\"esim\"], the only category sold)"

addedInput schema / properties / mandate / properties / currency / description
```
Added value: +"Currency of the limits (default USD, the wallet currency)"
```

changedInput schema / properties / mandate / properties / expiry / description

Previous value: -"ISO 8601; at most 365 days ahead"New value: +"ISO 8601 with offset, at most 365 days ahead, for example 2027-01-01T00:00:00Z"

addedInput schema / properties / mandate / properties / max_per_day / description
```
Added value: +"Most this agent may spend per day, in minor units"
```
addedInput schema / properties / mandate / properties / max_per_month / description
```
Added value: +"Most this agent may spend per month, in minor units"
```
addedInput schema / properties / mandate / properties / max_per_tx / description
```
Added value: +"Largest single purchase, in minor units (3000 = 30.00 USD)"
```

addedInput schema / properties / principal_id / description

Added value: +"The wallet owner you act for: 3-128 characters (for example principal:acme); all of its agents share one wallet"

Changed2 schema fields changedNov 6, 2026

addedInput schema / properties / partner_id

Added value: +{
+  "description": "Only if a partner of the store brought you: its partner_id (send with partner_key)",
+  "pattern": "^[a-z0-9-]{3,40}$",
+  "type": "string"
+}

addedInput schema / properties / partner_key

Added value: +{
+  "description": "The partner's partner_key (send with partner_id)",
+  "maxLength": 256,
+  "type": "string"
+}

Changed1 schema field changedNov 4, 2026
- addedInput schema / properties / mandate / properties / allowed_categories / maxItems
```
Added value: +10
```
First observedNov 3, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations, it explains one-time key returns, principal_key authentication requirements, registration-policy caps, active-agent counting, partner credential rules, and specific error codes. It also clarifies that partner attribution does not affect prices or limits.

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?

The description is front-loaded with purpose and usage, and most detail is relevant for a complex registration tool. It is somewhat dense and repeats the one-time principal_key return, but the length is broadly justified.

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?

For a complex tool with nested mandate parameters, authentication keys, partner attribution, and no output schema, the description covers the essential behavior an agent needs before calling it. Return values and major failure modes are disclosed.

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

Parameters4/5

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

Schema coverage is high, so the schema carries most parameter meaning, but the description adds the principal_key header alternative, partner_id/partner_key both-or-neither behavior, attribution locking, and a concrete mandate example with minor-unit conversion.

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?

The description states a specific verb and resource: create an agent identity with a spending mandate bound to a wallet-owning principal. It also explicitly positions this as the first call and distinguishes it from renew_mandate for mandate changes.

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?

It gives clear when-to-use guidance: when there is no agent_key yet, or to add another agent under an existing principal. It names renew_mandate as the alternative for extending or changing a mandate.

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

All Quartermaster eSIM tools Inspect

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.