Skip to main content
Glama

agent-transaction-control

by network.flint
OverviewDiscussionsAdmin

Issue Agent Passport

issue_agent_passport

Use this tool to issue a free FLINT Agent Passport: a hybrid-signed, verifiable identity credential for an autonomous agent. Before calling it, ask the principal for the accountable controller_id and controller_type, allowed actions, maximum transaction amount, and wallet address if one exists. Do not infer or invent authority. For the strongest available setup, authenticate first and mint with the principal-supplied identity and mandate. The zero-config path only needs agent.agent_name or agent.agent_id, but that result is identity-only and is not ready to transact until the missing authority is supplied. A missing controller requires a corrected remint because signed identity is immutable; a missing mandate can be added later. The passport signs identity only; the spending mandate is separate, mutable config that can be updated later without reissuing the passport. Pass session_token, from auth_verify_otp, to mint owned: the passport binds to your authenticated account immediately and there is no claim step or claim_url. Omit session_token to mint anonymously instead; that returns a one-time claim_url and the passport stays unclaimed until someone signs in and claims it. controller_id identifies who is accountable on the signed identity, which is not the same as the FLINT account that owns the passport; controller_name is a separate, optional, human-readable display label. Allowed actions must come from the FLINT mandate vocabulary: commerce_purchase, checkout.purchase, invoice.pay, subscription.renew, refund.request, quote.retrieve, x402_verification_purchase, stablecoin_transfer, paid_api_access, x402_request, agent_checkout, delegated_spending, project.read. Pass ["ALL"] as a preset to grant every action in one step; the stored mandate then expands to the full list and records the preset. Unknown strings are kept for backward compatibility but are reported back as unknown so the caller can fix them. The signed identity is immutable once minted, so a wrong agent_id, controller_id, or controller_type cannot be edited in place. Fix it by reminting with the corrected fields. A remint that reuses the same agent_id and controller_id supersedes a prior UNCLAIMED passport for that pair ONLY when this mint is authorized: either session_token proves the same controller (controller_assurance verified or command), or supersede_management_token matches that specific prior passport's own management token (the raw claim token from its claim_url). Without either, the prior is left alone, still indexed, and reported back as related_passports with a warning, so a stranger cannot anonymously remint someone else's controller_id and agent_id to burn their pending claim. A prior CLAIMED passport is never superseded automatically; it is listed back as existing_claimed_passports with a warning so you can review it by hand. Returns a public, resolvable passport URL and, when minted anonymously, a one-time claim link.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
agentYesAgent identity. Only agent_name or agent_id is required for an identity-only mint. Ask the principal for controller_id and controller_type before minting a Passport intended for transactions. Optional fields include controller_name, wallet_address, and attestations. Never invent principal authority.
mandateNoPrincipal-supplied mutable authority captured at issue (NOT part of the passport signature): allowed_actions, max_transaction_amount, notes. Ask the principal for these values and never infer them. Update later without reissuing the passport.
session_tokenNoOptional agent session token from auth_verify_otp. When present the passport is owned by that account at issuance and no claim step is needed.
supersede_management_tokenNoOptional. The management_token (raw claim token) of a specific prior UNCLAIMED passport with the same agent_id and controller_id. Presenting it authorizes superseding that prior passport even with no session_token, since it proves possession of that prior's own claim link.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / agent / description
      Previous value: -"Agent identity. Only agent_name or agent_id is required to mint. Optional fields include controller_id, controller_type, controller_name, wallet_address, and attestations."New value: +"Agent identity. Only agent_name or agent_id is required for an identity-only mint. Ask the principal for controller_id and controller_type before minting a Passport intended for transactions. Optional fields include controller_name, wallet_address, and attestations. Never invent principal authority."
    • changedInput schema / properties / mandate / description
      Previous value: -"Mutable spend authority captured at issue (NOT part of the passport signature): allowed_actions, max_transaction_amount, notes. Update later without reissuing the passport."New value: +"Principal-supplied mutable authority captured at issue (NOT part of the passport signature): allowed_actions, max_transaction_amount, notes. Ask the principal for these values and never infer them. Update later without reissuing the passport."
  2. Changed3 schema fields changed
    • changedInput schema / properties / agent / description
      Previous value: -"Agent identity. Only agent_name or agent_id is required to mint. Optional fields include controller_id, controller_type, wallet_address, and attestations."New value: +"Agent identity. Only agent_name or agent_id is required to mint. Optional fields include controller_id, controller_type, controller_name, wallet_address, and attestations."
    • addedInput schema / properties / session_token
      Added value: +{
+  "description": "Optional agent session token from auth_verify_otp. When present the passport is owned by that account at issuance and no claim step is needed.",
+  "pattern": "^flint_sess_[A-Za-z0-9_-]{40,}$",
+  "type": "string"
+}
    • addedInput schema / properties / supersede_management_token
      Added value: +{
+  "description": "Optional. The management_token (raw claim token) of a specific prior UNCLAIMED passport with the same agent_id and controller_id. Presenting it authorizes superseding that prior passport even with no session_token, since it proves possession of that prior's own claim link.",
+  "type": "string"
+}
  3. Changed1 schema field changed
    • changedInput schema / properties / agent / description
      Previous value: -"Agent identity: agent_id, agent_name, controller_id, controller_type (user or organization), wallet_address, and optional attestations."New value: +"Agent identity. Only agent_name or agent_id is required to mint. Optional fields include controller_id, controller_type, wallet_address, and attestations."
  4. First observed

TDQS

A4.9/5.0
Behavior5/5

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

The annotations only say this is a non-read-only, non-idempotent, non-destructive operation. The description adds substantial behavioral context: signed identity is immutable, wrong identity fields require a corrected remint, a remint supersedes a prior UNCLAIMED passport only under specific authorization conditions, a CLAIMED passport is never auto-superseded, and unknown action strings are preserved but reported back. This goes far beyond what annotations or schema communicate.

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 and densely informative, with each major behavior in logical order. However, it repeats the immutability and separate-mandate points multiple times (e.g., 'A missing controller requires a corrected remint' and 'The signed identity is immutable once minted' and 'The passport signs identity only'), making it slightly longer than strictly necessary.

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?

Despite there being no output schema, the description states the key return artifacts: a public resolvable passport URL and, for anonymous mints, a one-time claim link. It also covers warnings like related_passports and existing_claimed_passports, immutability, supersession rules, and both authenticated and anonymous paths. An agent has everything needed to invoke this tool correctly.

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

Parameters5/5

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

Even though schema description coverage is 100%, the description adds crucial semantics for all four parameters: session_token binds ownership immediately, omitting it returns a one-time claim_url, supersede_management_token is the raw claim token of a specific prior unclaimed passport, controller_id is distinct from the owning FLINT account, and mandate is mutable and outside the signature. It also enumerates the allowed-actions vocabulary and the ['ALL'] preset, which the schema does not.

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 opens with a specific verb and resource: 'issue a free FLINT Agent Passport: a hybrid-signed, verifiable identity credential.' It further distinguishes itself from siblings by explaining the separate mutable spending mandate (pointing toward update_agent_mandate) and the anonymous claim_url flow (pointing toward claim_agent_passport), so an agent can tell this tool apart from related ones.

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 explicit preconditions: ask the principal for controller_id, controller_type, allowed actions, max transaction amount, and wallet address; never infer authority. It also explains when the zero-config identity-only path is acceptable, when to use session_token versus anonymous minting, and when a mandate can be updated later rather than reissued, which routes the agent away from unnecessary remints.

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

All agent-transaction-control 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