Transports

A component implements one interface (act:tools/tool-provider). The host exposes it over a transport of your choice. All transports share the same semantics — tools, arguments, events — and differ only in the wire encoding and discovery mechanism.

MCP is ACT’s protocol on the wire. The host speaks it over stdio or over HTTP; the CLI and the browser runtime call the same component directly, without a wire at all.

MCP over stdio

act run <component> --mcp

Speaks JSON-RPC 2.0 over stdin/stdout, backed by the rmcp crate. Tool annotations (std:read-only, std:destructive, etc.) map to MCP readOnlyHint, destructiveHint, idempotentHint.

Use with Claude Code, Claude Desktop, Cursor, Cline, OpenCode, or any MCP client. Example client config:

{
  "mcpServers": {
    "sqlite": {
      "command": "npx",
      "args": ["@actcore/act", "run", "actpkg.dev/library/sqlite", "--mcp",
               "--grant", "{\"wasi:filesystem\":{\"mode\":\"allowlist\",\"allow\":[{\"path\":\"/tmp/db.sqlite\",\"mode\":\"rw\"}]}}"]
    }
  }
}

The MCP adapter is thin: tools/list maps to list-tools, tools/call maps to call-tool. For a component that exports session-provider, the host synthesises virtual open_session / close_session tools and forwards _meta.std:session-id into the WIT call metadata. See the MCP adapter spec.

MCP over Streamable HTTP

act run <component> --mcp --http -l "[::1]:3000"

The same MCP server, carried over an HTTP listener instead of stdio. It serves the single endpoint /mcp: POST a JSON-RPC request with Accept: application/json, text/event-stream, and the response comes back as an SSE stream with an mcp-session-id header identifying the connection.

curl -X POST http://[::1]:3000/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize",
       "params":{"protocolVersion":"2025-06-18","capabilities":{},
                 "clientInfo":{"name":"curl","version":"0"}}}'

--http requires --mcp, and --listen requires --http. Because a connected MCP client is a real prompt channel, this transport can resolve ask-mode capability requests through MCP elicitation, exactly as stdio does.

/mcp is the only endpoint

The server exposes nothing else — there is no REST surface to browse. Everything, including listing tools and opening sessions, is MCP over that one path.

CLI direct

act call <component> <tool> --args '{"k":"v"}' -m std:traceparent=00-4bf9...-01

Instantiates, runs one tool, prints the result, exits. Ideal for scripting and interactive debugging. Add --session-args '<json>' when the component needs a session — the host opens it, runs the call, and closes it in one process.

Browser

A component also runs client-side, with no host process at all: @actcore/web-runtime transpiles the .wasm in the tab and enforces the same capability ceiling there, and can expose the component’s tools to a browser agent over WebMCP.

import { runComponent } from '@actcore/web-runtime';
const { toolProvider } = await runComponent(wasm, { shimBase });

See Browser runtime for the full surface, and the Python playground for it running live.

Picking a transport

Use case	Transport
Agent (Claude Code, Claude Desktop, Cursor, …)	--mcp
Remote or containerised agent, shared server	--mcp --http
Scripts, CI, debugging	act call
Playground, offline tools, client-side apps	browser runtime
Agent running inside the user’s browser	browser runtime + WebMCP

One component, one source of truth, every deployment.