Skip to main content
Glama

boxLink

Links the box to an account, so the box's watch hits draw the account's units and its limits are the account's tier's. A box belongs to at most one account.

  • Cost: Free. Signed by the box over method POST, path /agent/v1/<address lowercased>/box/link and the body {"accountId": ...}, and authorized by the account: its key in ARCGATE-KEY, or the owner's AccountRequest over the same method, path and body in ACCOUNT-SIGNATURE, ACCOUNT-NONCE and ACCOUNT-EXPIRY. The box's signature alone is a 401 signature_required.

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

  • Returns: address, accountId, linkedAt and keyId, the id of the key that made the link, or null when the owner's signature did. A link made with a key sends a notice to the owner's box.

  • Errors:

    • 404 box_not_found: the address has no box. Create one with boxCreate.

    • 404 account_not_found: no account has that id.

    • 403 key_wrong_account: the key belongs to another account than accountId.

    • 409 box_linked: the box belongs to an account already. Unlink it first with boxUnlink.

    • 409 account_lapsed: the account has lapsed (its grace has ended), so no box can be linked to it.

    • 409 box_limit: the account holds as many boxes as its tier allows, or as the tier it has a downgrade scheduled to (accountTier), which the message names and the body carries as scheduledTier. Unlink one first.

    • 409 watch_limit: while the account has a downgrade scheduled (accountTier), the box holds more watches, screens or agent screens than the scheduled tier allows; the message names it and the body carries scheduledTier. Delete what is over, then link.

  • Next:

    • accountStatus: read the account's linked boxes.

    • boxStatus: read the box's linkedAccount.

    • boxUnlink: end the link.

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.
accountIdYesThe account's id, `acct_` and 22 base64url characters, as `accountCreate` and `accountStatus` answer 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. Omitting it is a 401 signature_required unless an ARCGATE-KEY of the account the box is linked to is sent (over MCP, on the connection), and it 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 authorizes the call in place of an ARCGATE-KEY of the account; one of the two is needed, and omitting both is a 401 signature_required, never a charge.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so thoroughly: cost is free, the exact signing scheme (method, path, body, EIP-712 typed data, required headers), authorization alternatives (ARCGATE-KEY vs owner signature), and the side effect of notifying the owner's box. Error states are enumerated with codes and remedies.

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?

Front-loaded one-line summary followed by labeled bullet groups (Cost, Inputs, Returns, Errors, Next) makes it scannable. It is long, and the signature/auth mechanics are restated from the schema, but each section is purposeful rather than 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?

For a 4-param, nested-auth mutation tool with no output schema and no annotations, the description supplies the missing layers: return fields (address, accountId, linkedAt, keyId), full error taxonomy, and navigation to related tools. Nothing an agent needs to invoke it correctly is absent.

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% with highly detailed nested-object docs, so the schema already explains address, accountId, and both signature objects. The description's 'Inputs' line restates path/body placement but adds no semantics beyond the schema.

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 ('Links the box to an account') plus the effect on behavior (watch hits draw the account's units; limits become the account's tier). It is trivially distinguishable from siblings like boxUnlink and boxCreate, and the cardinality constraint ('A box belongs to at most one account') sharpens the semantics.

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 'Errors' and 'Next' sections effectively encode when-to-use and when-not: link only when a box and account both exist, unlink first when already linked, and follow with accountStatus/boxStatus/boxUnlink. It never states an explicit exclusion ('do not use this if...'), but the failure modes convey the preconditions clearly.

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