IllustrativeConnect your own assistant, scripts or dashboard to your installation. Everything they do goes through the same permissions, approvals, spend caps and ledger as the team itself. There is no side door.
Seller identity and paid entitlement are separate from installation identity. No new public inference or provisioning endpoint is promised here.
Authenticate, verify and reserve eligible paid usage on the server before hosted inference.
Use a supported adapter and bounded structured output. Suggestions never silently overwrite a newer user edit.
Freeze the exact confirmed brief; validate imports and destination ownership.
Provision brand context, supported roles and tasks with resumable progress and one owner for each action.
Receive authenticated events; enforce scopes, approvals, caps and receipts. Never distribute our shared app secret.
Example stores illustrate the intended scoped API; public per-brand keys are planned.
Your installation runs a Model Context Protocol server. Connect Claude Code, Claude Desktop or any MCP client and it gains the same store awareness your team has: read tools that answer, and propose tools that queue work for you.
Read the proposal queue, the ledger and store snapshots. Approve or reject with a call. Approving records a decision; whether it executes is governed by the same gate as everything else.
Sample values for one of the example stores. Tool names and statuses follow the installed system's contract; the customer-facing endpoints are the planned shape.
// From Claude Code, Claude Desktop or any MCP client you connect
{ "tool": "catalog_drafts", "arguments": { "brand": "orbit-snacks" } }
// The store answers with what it can see
{ "drafts": [
{ "handle": "neapolitan-brick", "status": "draft", "price": "6.00" },
{ "handle": "mint-orbit-bar", "status": "draft", "price": "6.00" } ],
"brand": "orbit-snacks", "readAt": "2026-09-09T14:02:11Z" }
Your assistant asks the store, through the installation's MCP server.
The seven states a proposal can be in. "auto" is reserved for reversible, capped actions in a domain that has earned it.
What a dashboard of your own would show from the proposals endpoint, built from the workspace's own table. Approve a row and the ledger answers on its own clock.
| id | brand | action | status | decide |
|---|---|---|---|---|
| prop_7f3a | orbit-snacks | catalog.launch | queued | |
| prop_7f2c | marrow | reply.send | queued | |
| prop_7e90 | bell-jar | tracking.write | autoreversible, capped, earned | no decision needed |
// Approve a queued row. The receipt lands here.Each connection is supplied by you, per brand, with your own keys or authorization. Connecting one never authorizes spending or publishing by itself.
Connectors in the codebase today. Exposing one in your installation does not mean every provider operation is implemented or verified.
An MCP server the agents use, with read tools and guarded propose tools that all pass through the proposal boundary.
A loopback HTTP API behind the console for proposals, approvals, history and snapshots, plus a typed contract package shared with the console.
Connecting your own MCP clients to an installation, and API keys you issue per brand, each scoped by the same permissions as a team member.
Reference documentation for every tool and endpoint, versioned with each release like the rest of the docs.
