What is ACT

ACT — Agent Component Tools — is a protocol for packaging tools as WebAssembly components. One .wasm file works from any host: agents via MCP (stdio or HTTP), developers via the CLI, browsers via the web runtime.

Why another protocol

Tools today are scattered across MCP servers, OpenAPI backends, ad-hoc REST APIs, and language-specific SDKs. Each target needs its own adapter, its own auth story, its own sandbox. ACT collapses the pipeline:

Problem	ACT
One codebase per transport (MCP server, REST backend, CLI)	One .wasm, served over MCP (stdio or HTTP), the CLI, or in the browser
Tools run with full OS access	Deny-by-default filesystem + network sandbox; capabilities are declared in the component and intersected with host policy
Metadata drift across Cargo.toml / pyproject.toml / package.json	Merged at build time into a signed act:component custom section
”Works on my machine”	One .wasm artifact, pinned by digest and signed to the workflow that built it — the same bytes wherever it runs

Architecture in one picture

graph TD
    Component["component.wasm<br/>(tool-provider + act:component)"]
    Host["act host<br/>(wasmtime, capability-gated)"]
    Stdio["MCP over stdio"]
    Http["MCP over Streamable HTTP<br/>(/mcp)"]
    CLI["act call"]
    Browser["Browser runtime<br/>(+ WebMCP)"]

    Component --> Host
    Host --> Stdio
    Host --> Http
    Host --> CLI
    Component -.-> Browser

Every component exports the tool-provider interface from act:[email protected]. Stateful components additionally export act:[email protected] — used by the bridges (mcp-bridge, openapi-bridge) and any component with a session lifecycle. Both depend on act:[email protected] for cross-cutting types. The host reads each component’s metadata from a WASM custom section (act:component, CBOR) without instantiating it, then exposes the tools over MCP — on stdio or over HTTP.

What’s in the box

• act — host CLI. Pulls components from OCI registries, HTTP URLs, or local paths; runs them as MCP server, HTTP server, or direct-call.
• act-build — component post-processor. Merges metadata from Cargo.toml / pyproject.toml / package.json / act.toml into the .wasm.
• act-sdk (Rust) — #[act_component] / #[act_tool] macros.
• act-sdk (Python) — @component / @tool decorators via componentize-py.
• Spec — actcore/act-spec. WIT is normative; JSON Schema is derived.
• Components — 22 published under actpkg.dev/library, from sqlite and postgres to a full Python environment. See Published components.

Next

• Install
• Run your first component (pull + serve + call in under a minute)
• Build your own — Rust or Python