2 minute readNewAgent-ready
Agents sign up from MCP and keep working in the same session
An agent connected to the MCP server with no key can now sign itself up with one tool call, register_agent, and the same MCP session uses the new key from then on: the call that needed a key works when retried, with no header to add and no client to reconfigure. An agent that already holds a saved key hands it to the session the same way, with use_api_key. A key a person keeps when claiming the agent's workspace now gets full access there, so it can change offer settings and other routing. Rolling out.
An MCP client sets its headers when it connects, not halfway through. So an agent that signed itself up with POST /api/agents/register held a key it had no way to send, and finished its job with raw HTTP calls instead of tools.
- One tool call to a key:
register_agentwith anamereturns a sandbox workspace, its key and a claim link, exactly as the HTTP endpoint does. - The session keeps it: every later call in that MCP session runs as the new agent. Retry the call that failed as it is.
- Bring a saved key: an agent that signed up on an earlier run calls
use_api_keywith that key, and the session runs as it from then on. The key is checked and never echoed back. - Pointed to it: a keyless call that needs a key now says to call
use_api_keywith a saved key, orregister_agentfor a new one. With?profile=starterboth tools are listed beside the starter tools. - Ends cleanly: the session drops the key when it ends, or when the key is revoked, rotated or not kept through a claim. One registration per session.
- Kept keys work after a claim: a person who claims the workspace and keeps the agent's key now gives it every scope a key can hold by wildcard, as the claim page promises, so
set_offer_settingsand other routing changes no longer answer 403. Scopes granted only by name are not included, and an agent's own key still cannot change a buyer spend policy.
