Skip to content

Agent account bootstrap

Prepare work through MCP, connect Apple or Google once, and continue with the same agent.

Availability

This operational-account flow uses the opt-in stdio runtime and server-side activation flags, including in production. The regular account-first setup remains available. Use only the tools and connection action actually returned by the configured server.

Google with an existing account and Apple with a new account have been verified through real staging logins, followed by linked MCP reading and reversible writing. This is staging evidence, not certification of every production provider/device combination.

Instructions for agents

  1. Call bootstrap_agent_account to create or resume the runtime’s operational account. Every saved resource has an owner from creation; bootstrap does not create a verified human identity.
  2. In PREPARING, use ordinary catalog and routine tools to save one generic, inactive routine. Read it back before completing preparation. Do not collect health data, measurements, personal history or free-form personal information in this state.
  3. Call complete_agent_preparation with a stable UUID commandId. This durably changes the account to LINK_REQUIRED and blocks further preparation writes.
  4. If the server returns link.url, present that exact URL. The user connects Apple or Google and completes the permissions presented on that connection screen. Do not fabricate a URL or accept consent on their behalf.
  5. Poll get_agent_account_status at link.pollAfterSeconds. The runtime privately exchanges the key-bound continuation receipt and stores credentials. Never ask the user to copy tokens.
  6. At LINKED, continue the requested work through ordinary MCP tools within the granted permissions. No routine review, manual import, second MCP authorization or subsequent account-onboarding wizard is part of this flow.

The connection is the one normal human step. Revocation, changed permissions or provider challenges may legitimately require further user action. MCP does not supply missing personal information or authorization.

Preparation contract

Use name: "Generic routine", goal: "general_fitness", activate: false, trackSteps: false, and day names Day N. Use only public built-in exercise IDs from the catalog without a q search query. Use regular sets: 1–6 sets, RIR 3, 1–30 repetitions, 0–300 seconds rest, and one repSchemes entry per set. Omit notes, descriptions, arbitrary names, exerciseName, and custom exercises. Follow the registered input schema for each tool.

Reuse clientRequestId UUIDs for retried ordinary mutations and the same commandId for a retried preparation command. The fixed provisional lifetime is 72 hours; activity and process restarts do not extend it or reset budgets. Do not automatically create a replacement after EXPIRED or REVOKED.

Identity and recovery

A new social identity keeps the provisional owner ID. An existing compatible account receives the prepared inactive routine with its resource IDs preserved; existing personal data is not merged or overwritten. Activation remains a separate ordinary agent operation.

Keep the runtime’s private state directory across restarts. A linked runtime resumes with its stored authority; do not bootstrap another account or request another login just because the process restarted. If a connection URL is absent, report that linking is unavailable on this server. Use revoke_agent_account only before linking; afterward use normal installation controls.

Integration boundary

This flow currently uses the operational stdio runtime. A normal remote MCP connection does not automatically expose these bootstrap tools. WebMCP and desktop control are not required. See the machine-readable server card for the current discovery contract and deployment status.