Skip to main content
Glama

Renew an agent's mandate

renew_mandate

Extend or change an existing agent's spending limits and expiry without registering a new agent. Use it on MANDATE_EXPIRED or to raise or lower limits. It re-signs the mandate of an agent of your principal (you, unless target_agent_id names another) with new limits and expiry, under the same registration policy caps as register_agent. Needs your agent credentials and the principal_key (argument or X-Principal-Key header). The agent keeps its agent_id, agent_key and spend history. Use it on MANDATE_EXPIRED or to change limits instead of registering a new agent; an agent whose mandate had expired takes a slot again (PRINCIPAL_AGENT_LIMIT when none is free). Revoked agents cannot be renewed (AGENT_REVOKED).

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": {
      "mandate": "<mandate>"
    },
    "name": "renew_mandate"
  }
}

Input Schema

NameRequiredDescriptionDefault
mandateYesSpending limits this agent is bound by, in minor units (cents); see get_policies for the caps the store allows
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)
principal_keyNoThe principal's current principal_key (or X-Principal-Key header)
target_agent_idNoAgent whose mandate to renew (default: you)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • 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)"
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the idempotentHint=false / destructiveHint=false annotations: it discloses the credential requirements (agent credentials plus principal_key via argument or X-Principal-Key header), that the mandate is re-signed under the same registration policy caps as register_agent, that identity and spend history are preserved, and the concrete failure modes (AGENT_REVOKED, PRINCIPAL_AGENT_LIMIT). This is exactly the extra mutation/auth context annotations cannot carry.

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?

Front-loaded with the core action and scope, which is good, but it repeats itself: 'Use it on MANDATE_EXPIRED or to raise or lower limits' and the 'instead of registering a new agent' alternative are each stated twice in slightly different words. Tightening those duplicates would lose no information.

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 6-parameter mutation with a nested mandate object and no output schema, the description covers purpose, credentials, limits source, side effects, preservation guarantees, and error paths. Nothing an agent needs in order to call it correctly is missing.

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 100% and the nested mandate fields are already documented, so the baseline is met by the schema alone. The description still adds real meaning: target_agent_id defaults to the caller, principal_key may arrive as an argument or header, and the limits are bounded by the same policy caps as register_agent (pointing at get_policies).

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+resource (extend/change an existing agent's spending limits and expiry) and immediately distinguishes it from the sibling register_agent by saying it works 'without registering a new agent' and that the agent keeps its agent_id, agent_key and spend history. An agent can pick this over register_agent without opening either 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 triggers (on MANDATE_EXPIRED, or to raise/lower limits), an explicit alternative it replaces (registering a new agent), and an explicit exclusion (revoked agents cannot be renewed, returns AGENT_REVOKED). It even states the slot consequence (PRINCIPAL_AGENT_LIMIT when none is free), which tells the agent when this call will fail.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.