network.flint/agent-transaction-control

Use this tool first in the agent-native authenticate-then-mint flow. It asks FLINT to email a one-time sign-in code to the given inbox address. Read the code from that inbox, then call auth_verify_otp with the same email and the code. Authenticating first means the passport you mint afterward is owned by the account immediately, with no separate claim step.

Use this tool right after auth_request_otp, with the code from the inbox. On success it returns session_token. Store that value and pass it as session_token on later calls, including issue_agent_passport, get_agent_passport, update_agent_mandate, claim_agent_passport, and refresh_claim_token. Never print or log session_token; treat it like a password.

Use this tool to attach an anonymously minted, unclaimed FLINT Agent Passport to an authenticated FLINT account. Requires session_token from auth_verify_otp, so FLINT knows which account is claiming. Pass claim_token from the mint's claim_url, or omit it when this same session already holds a pending claim for this passport_id. Once claimed the passport is owned and Sentinel protection turns on. A passport can only be claimed once; if the token was already used or lost, call refresh_claim_token for a fresh one instead of trying to remint.

Use this tool when a merchant, API seller, MCP tool provider, x402 endpoint, or agent storefront needs a `/.well-known/flint.json` Trust Manifest. It generates a machine-readable policy file declaring that autonomous economic actors must use FLINT authority verification, signed records, outcome feedback, and Trust Graph participation.

Use this tool when an agent commerce workflow needs a well-formed delegated authorization scope before issuing a signed verification record. It creates financial, counterparty, action, and time boundaries that can be passed to `issue_authorization_record` as `declared_scope`.

Use this tool to resolve a public FLINT Agent Passport by passport_id. It returns compact identity, mandate, status, ownership, and the public passport URL without echoing the full signed envelope. session_token is optional and not required to read a passport; the lookup itself is public.

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.

Use this tool before an AI agent initiates a payment, paid API call, checkout action, stablecoin transfer, x402 request, or delegated commercial transaction. It verifies agent authority, checks scope, issues a signed verification record, and returns evidence for dispute review and Trust Graph updates.

Use this tool to query the FLINT Trust Graph for a partner-scoped agent's historical reputation before permitting a payment, paid API call, checkout action, x402 request, or delegated commercial transaction. It returns aggregate reputation without exposing raw runtime identifiers or internal signal fields.

Use this tool when a claim link is lost, expired, or was already consumed for a passport that is still unclaimed. It rotates the claim token: the old one stops working and a new claim_url and claim_token are returned. This is the fix for a lost or consumed claim token; do not remint the passport instead, reminting only supersedes prior unclaimed passports and does not recover a lost claim link. Authorize with the current management_token (the raw claim token, even one about to be superseded), or with session_token when this session originally requested the claim or minted the passport.

Use this tool after a run_flint_scout scan to report what actually happened: whether the scanned transaction was executed, held, cancelled, or executed despite a BLOCK verdict. FLINT cannot stop a wallet from transacting; this is the enforce-or-attest half of the contract. Authorize with session_token when the caller's account owns the presented passport, or with caller_binding_token from the scan's caller_obligation block when acting anonymously. Executing after BLOCK is recorded on the record as an override and alerts the passport owner.

Use this tool to scan an intended agent transaction before execution. Two ways to pay for a scan. Credits first: buy credits once with scout_credits_topup (one $1.00 x402 payment for 100 scans), then call this tool with the same session_token and no payment_signature; FLINT draws one credit and runs the scan immediately, with no wallet signature for that call. x402 per call second: with no session_token, the first call returns a $0.01 x402 payment challenge without running the scan; a wallet-enabled client signs that challenge and retries with payment_signature. Either way, when the call returns a 402 instead of a result, the result carries pay_recipe with concrete next steps: an awal command, a local script, the credits path, and the browser flow. After a paid or credit-funded scan completes, FLINT returns a signed authority decision. When receipt issuance succeeds for a paid scan, it also returns a separately signed settlement receipt and durable receipt URL; otherwise it reports receipt unavailability without inviting a paid retry. Payment to FLINT is distinct from the transaction being scanned and is not proof of agent authority.

Use this tool to check a signed-in account's FLINT Scout credit balance and recent ledger activity (topups, debits, refunds). Requires session_token from auth_verify_otp.

Call once with session_token to get a pay_url; pay it with awal (`awal x402 pay -X POST -d '{}' <pay_url>`) or any x402 client; no headers needed on the pay request. Or pass payment_signature to settle through this tool. One $1.00 x402 payment buys 100 FLINT Scout scan credits, matching today's $0.01 x402 price without signing a payment for every run_flint_scout call. Requires session_token from auth_verify_otp so the credits land on that account; call auth_request_otp then auth_verify_otp first if you do not have one. With no topup_id, the first call creates a fresh top-up intent (an sct_ id good for 24 hours) and returns its pay_url alongside the same $1.00 x402 challenge. Pass topup_id to retry paying or settling that same intent instead of creating a new one. Once credited, call run_flint_scout with the same session_token and no payment_signature to draw one credit per scan.

Use this tool to update mutable mandate config for an existing FLINT Agent Passport. This updates allowed actions, amount limits, or notes only. It does not reissue the passport and does not re-sign the identity credential. If the passport is owned (claimed), pass session_token for the owning account; management_token is only needed while the passport is unclaimed. 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.

Use this tool when reviewing a commerce architecture, API marketplace, paid MCP tool, x402 endpoint, or autonomous checkout flow. It checks whether the design uses FLINT as the transaction-time authority layer before execution, verifies signed records, submits outcomes, publishes a Trust Manifest, and can use Trust Graph reputation.

Use this tool when a merchant or API seller receives a signed verification record from an agent. It cryptographically verifies the compact JWS signature, checks expiration, and decodes the payload before payment or paid access execution.