Skip to main content
Glama

boxUnlink

Ends a box's link to its account. The box gets a fresh allowance from this moment, at least the deployment's box grant: it expires no sooner than the grant's days from now, and an allowance the box paid for that runs longer keeps its expiry. Its own units pay for its hits again.

  • Cost: Free. Any one of these authorizes it: the box's own signature over method DELETE, path /agent/v1/<address lowercased>/box/link and no body (the hash of no bytes); the linked account's owner's AccountRequest over the same, in ACCOUNT-SIGNATURE, ACCOUNT-NONCE and ACCOUNT-EXPIRY; or a key of the linked account in ARCGATE-KEY.

  • Inputs: address (path), the box. No body.

  • Returns: address, the accountId it was linked to and its fresh allowance.

  • Errors:

    • 404 link_not_found: the box is linked to no account.

  • Next:

    • boxStatus: read the allowance.

    • boxLink: link it again.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
addressYesThe box's address: the agent's own address (an EOA or an EIP-7702 account), any letter case. The box is keyed by it, and a signed request must be signed by it.
agentSignatureNoThe agent's EIP-712 signature over this request, as the AGENT-SIGNATURE, AGENT-NONCE and AGENT-EXPIRY headers carry it over HTTP. Sign the typed data `AgentRequest` with fields `address` (the box), `method`, `path`, `bodyHash`, `nonce` and `expiry`, under the domain {name: "arcgate", version: "1"} with no chainId (a wallet that can only sign with one, such as Circle's, may add the chainId of the chain this deployment serves, 5042 on Arc mainnet, and no other). The `path` is the request path with every parameter filled in and the address lowercased. The `bodyHash` is the keccak256 of the canonical JSON of the body you send (sorted keys, no whitespace), or of no bytes when there is none. It unlinks the box alone. Omitting it needs the owner's accountSignature or an ARCGATE-KEY of the linked account (over MCP, on the connection) instead, and is never a charge: the call is free.
accountSignatureNoThe account owner's EIP-712 signature over this same request, as the ACCOUNT-SIGNATURE, ACCOUNT-NONCE and ACCOUNT-EXPIRY headers carry it over HTTP: the same method, path and body the box signs, but the typed data `AccountRequest` (not `AgentRequest`) with `address` the owner's and `origin` first (the API's base URL with no trailing slash, for example `https://api.arcgate.dev`), under the same domain. A signature made for another deployment's origin is a 401 invalid_signature. Each nonce is accepted once per owner. It unlinks the box in place of the box's own signature or an ARCGATE-KEY of the linked account: any one of the three is enough, and omitting all of them is a 401 signature_required, never a charge.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and delivers: cost is free, three alternative authorization paths are enumerated, the allowance/expiry reset semantics are spelled out, and the error surface is documented. This is unusually rich behavioral disclosure for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded purpose sentence followed by clearly labeled Cost / Inputs / Returns / Errors / Next sections. Dense but every block earns its place; nothing is filler.

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 supplies returns (address, accountId, fresh allowance), the single error case, and follow-up tools. Combined with the schema's auth details, an agent has everything needed to invoke this correctly.

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% and all three parameters (address, agentSignature, accountSignature including nested nonce/expiry/signature) are fully documented in the schema. The description's 'Inputs: address (path), the box. No body.' mostly restates the schema, so 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 — 'Ends a box's link to its account' — and immediately distinguishes itself from siblings like boxLink ('link it again') and boxStatus. An agent can tell exactly what this operation does 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 Guidelines4/5

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

The 'Next' block routes the agent to boxStatus (read allowance) and boxLink (re-link), and the error case 404 link_not_found defines the condition under which the tool is pointless. It does not explicitly frame when-not-to-use, but the surrounding context is clear.

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.

Resources