What works today
The Docs MCP server is read-only. It cannot see or change a Business, a Store, an Order, a Payment, or a deployment. Do not send it credentials.
The skills are Markdown. They run no code and hold no credentials, and installing one changes what an agent knows before it starts, not what it can reach.
Remote OAuth MCP, when it exists
Remote OAuth MCP is the planned transport for authorized product operations: OAuth authorization code with PKCE, short-lived scoped access tokens, rotating refresh tokens, revocation, and an actor identity that lands in the audit log. Its tools will call the same versioned Commands that 86d Console calls, so an agent and a person doing the same thing produce the same record. The shared wire contract and conformance digest live in the open-source package@86d-store/contracts (command, change-set, and conformance entry points). Both planes pin an exact package version and verify the embedded SHA-256 digest before serving Commands. A mismatch fails closed. Raw tRPC stays a private transport; it is not an agent or cross-plane interface.
There is no public Remote OAuth MCP endpoint, authorization flow, or tool catalog today. The /86d skill is planned as a thin guide over that Command contract, teaching a model how to find the connection and read a result. Product behavior lives in the Command layer, never in the skill. That planned skill is separate from the published agent skills, which teach an agent how to build on 86d and reach nothing at runtime.
The planned model
Three records carry the whole thing:
Each plane runs and audits the Commands for the facts it owns. The Control Plane handles managed work. The Store Runtime handles commerce Commands, drafts, and commerce audit facts.
A Workflow that fails partway says so. It reports
pending, running, completed, rolled_back, failed, or needs_attention, and it never reports success because one external step worked.
What you see before you approve
A Change Set shows you the whole picture before anything lands:- which Business and Stores it touches
- the revisions it was prepared against
- before and after values
- what Shoppers will see, and what changes operationally
- estimated charges and the spending authority it needs
- required permissions
- validation results and anything still blocking
- what can be rolled back
Three levels of human involvement
A Standing permission can cover bounded routine work, scoped by Business, Store, action, amount, time window, and spending ceiling. Buying shipping labels all week without a prompt each time is exactly what it is for. Anything outside that scope or over that cap goes back to Confirm now.
Four things never accept a standing permission, no matter what: accepting terms, making a KYC attestation, enabling automatic top-up, and deleting an account or Business. Those need a person, present, each time.
The product explains what the action does. It does not show you a risk score and ask you to trust it.
Rules an agent works under
An agent gets opaque Connection references and capability status. It never sees provider keys, OAuth tokens, webhook secrets, or managed credentials. An agent may generate descriptions, handles, collections, tags, alt text, and layout. It must not invent merchant facts: price, Inventory counts, weight, dimensions, ingredients, origin, regulated claims, tax treatment, or whether a provider approved something. Those are yours to state. A tool call that returned successfully proves the call succeeded. It does not prove the Workflow finished.Using the current tools
- Install the agent skills for the side you are working on.
- Connect an MCP-compatible client to the Docs MCP server.
- Search for the smallest page that answers the question.
- Read the whole page before acting on it.
- Check any implementation claim against the current source and tests.
- Use the CLI only against the working copy you mean to change.