Borro

Prepare: register a Zero Dark session key

darkroom_session_register

Read-onlyIdempotent

Register a session key for an agent, with caps: USDG notional per order and per UTC day (counted at each batch's price), the markets it may trade (symbols, comma separated, or all) and an expiry. The key consents by signing: without key_sig this returns the EIP-712 typed data for the session key to sign (its expiry fixed); call again with key_sig and that expiry, or with the Zero Dark kit's whole registration, for the owner's unsigned transaction, simulated from the wallet. The key can commit and cancel within its caps; it can never withdraw or change keys.

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": {
      "wallet": "<wallet>"
    },
    "name": "darkroom_session_register"
  }
}

Input Schema

Name	Required	Description
`key`	No	The session key's address (0x...)
`expiry`	No	With key_sig: the expiry (unix seconds) the earlier call fixed and the key signed
`wallet`	Yes	The wallet's address (0x...): the transactions are built for it to sign
`key_sig`	No	The session key's signature over sign_this (0x + 130 hex)
`markets`	No	Comma separated symbols, or all
`expiry_days`	No	Without key_sig: days until it expires (1 to 365, default 30)
`max_day_usdg`	No	Most notional per UTC day, USDG
`registration`	No	Instead of the fields above: the registration the Zero Dark kit printed ({ darkroomAgent, owner, key, maxOrderUsdg, maxDayUsdg, markets, expiry, keySig })
`max_order_usdg`	No	Most notional per order, USDG

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Despite annotations carrying the safety profile (readOnlyHint, idempotentHint, non-destructive), the description adds substantial behavior: the call only prepares an owner-signed transaction 'simulated from the wallet', expiry is fixed on the first round-trip, caps are counted at each batch's price, and the resulting key may commit/cancel but never withdraw or change keys. That capability boundary is exactly the context an agent needs and is not in any structured field.

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?

Purpose is front-loaded in the first clause and the signing round-trip follows logically. Sentences are clause-dense (three long sentences carrying caps, two-phase flow, and key authority), so some parsing effort is required, but nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter, nested-object tool with no output schema, it covers the critical unknowns: what each calling mode returns and what the resulting key may do. Missing are auth/wallet-signature prerequisites for the owner side and error conditions (e.g. bad key_sig, expiry mismatch), which leaves a modest gap.

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%, so the baseline is 3, but the description adds real meaning: markets accepts comma-separated symbols or 'all', key_sig must be paired with the expiry fixed in the earlier call, and 'registration' substitutes wholesale for the field set. It still doesn't clarify relationships such as whether max_order_usdg can exceed max_day_usdg.

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?

Opens with a specific verb+resource ('Register a session key for an agent') and immediately bounds scope with the caps it carries (per-order/per-day USDG notional, markets, expiry). An agent can distinguish it from darkroom_session_revoke or darkroom_order 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?

Explicitly lays out the two-step path: call without key_sig to get EIP-712 typed data, call again with key_sig plus the fixed expiry, or supply the Zero Dark kit's whole 'registration' instead. It does not name a prerequisite/alternative sibling (e.g. that registration must precede darkroom_order), so it stops short of full when-not guidance.

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

All Borro tools Inspect

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

Need Help?