MCP

Every environment is an MCP server: connect Claude, ChatGPT, Codex, Cursor or your own agent.

Every environment is an MCP server at https://<handle>.domainruntime.cloud/mcp. An agent connected to it can read your data and run your domain's actions, as the person or service it signed in as, with the same permissions and the same record as any other caller. There is no adapter to write per agent.

druntime mcp --env=prod-orders-main

prints the URL and what to paste in Claude Code, Codex, Cursor, Claude and ChatGPT (--client=codex for one, --json for scripts).

What the agent gets

Tool	What it does
`<domain>.<action>`, one per action of the active release	Runs the action as the caller, exactly like `POST /actions/{name}/invoke`: an execution is recorded, `runtime.auth` is the caller, the input is checked against the action's schema. The tool's description is the action's `description`.
`query`	Reads with InstaQL as the caller: `{"query": {"orders_order": {"$": {"where": {"status": "open"}, "limit": 20}, "items": {}}}}`. Your permissions decide what comes back.
`describe`	The release's domains, entities, links and actions, so the agent can find its way before it reads or acts. Also the resource `domainruntime://<handle>/schema`.

Write each action's description for the agent: what it does, when to use it, what it refuses.

placeOrder: defineAction({
  name: "orders.placeOrder",
  description: "Place an order for a customer. Refuses a customer on credit hold.",
  input: z.object({ customerId: z.string(), items: z.array(z.object({ sku: z.string(), qty: z.number().int() })) }),
  output: z.object({ orderId: z.string() }),
  async execute({ input, runtime }) { /* … */ },
}),

What the agent sees back

A finished function answers its output (as structuredContent when the output is an object).
A workflow answers once its run is admitted, with the execution to follow.
Every call names its execution in _meta["dev.domainruntime/execution"] (id, requestId, status, url): the same execution you see in the platform and with GET /executions/{id}.
A refusal is a tool error the model can read: an input that does not fit (with the part that does not), access_denied, a failed action with your message.

Actions carry no read-only hint yet, so clients ask the person before running one.

Signing in

A person connects from the client: the client reads /.well-known/oauth-protected-resource/mcp from the environment, registers with the DomainRuntime authority, and opens the sign-in page. The agent then acts as that person.

A server connects with a key, sent as a bearer:

# ~/.codex/config.toml
[mcp_servers.prod-orders-main]
url = "https://prod-orders-main.domainruntime.cloud/mcp"
bearer_token_env_var = "DOMAINRUNTIME_TOKEN"

An organization's service key acts as an administrator; a user token acts as that user of the environment. Keep keys in the environment of the process, never in a config file.

Interactive sign-in from clients that send an OAuth resource indicator (the official MCP SDKs do) is being enabled on the authority. Until then connect with a key.

Limits

One JSON message per request; no server-initiated stream (GET /mcp answers 405).
A function call waits up to 110 s, then the tool answers execution_result_timeout; the execution keeps running and can be followed by its url.
Inputs with files answer execution_files_required: send files through the HTTP API.

What the agent gets

What the agent sees back

Signing in

Limits

On this page