Power your agent
Yayıncının kendi komutu. PlugMCP uç noktası değildir.
Host a copy with our keys and logs.
npx -y @actcore/[email protected]Claude Code'un yerel komutlar için kurulum bağlantısı yok. Aşağıdaki komutu kopyalayın ve bir terminalde çalıştırın.
claude mcp add actcore-act -- npx -y @actcore/act@0.14.6Bir terminalde çalıştırın.
{ "mcpServers": { "actcore-act": { "command": "npx", "args": [ "-y", "@actcore/[email protected]" ] } }}claude_desktop_config.json
Uzak URL mi, yoksa makinenizde bir komut mu? İki kurulum arasındaki fark
PlugMCP’de çalıştır
A new server you create. It is not this listing's official endpoint. Use the publisher install when you want their URL and their credentials.
BaşlatYayıncıdan
Every agent tool you install today runs with your permissions: your files, your
keys, the whole network. ACT packages a tool as one WebAssembly component
that declares what it needs — this directory, these hosts — and the host
enforces it: anything undeclared is denied, anything declared still waits for
your grant, and every decision lands in an audit trail. The same .wasm is an
MCP server, a CLI tool, and it runs in a browser tab.
CLI host for ACT (Agent Component Tools) WebAssembly components
Try it in your browser → real pandas on your CSV, sandboxed to the one file you hand it. Nothing to install.
mkdir -p /tmp/demo
npx @actcore/act call actpkg.dev/library/sqlite query \
--args '{"sql":"SELECT sqlite_version()"}' \
--session-args '{"database_path":"/tmp/demo/app.db"}' \
--allow 'fs=/tmp/demo/**'
Docs · Components · Website
act — run, call, inspect, and serve ACT components from local files, HTTP URLs, or OCI registries. Components built for wasm32-wasip2 (with async) and wasm32-wasip3 run the same way, under the same capability grantsact-build — post-process compiled WASM components: embed metadata, skills, and custom sections# act (CLI host)
npm i -g @actcore/act
pip install act-cli
cargo install act-cli
# act-build (build tool)
npm i -g @actcore/act-build
pip install act-build
cargo install act-build
Pre-built binaries available on GitHub Releases and Docker (ghcr.io/actcore/act).
# Discover tools in a component
act info --tools actpkg.dev/library/sqlite
# Call a tool. sqlite is session-based: --session-args opens a session for
# this one call. --allow lets it touch /data and nothing else.
act call actpkg.dev/library/sqlite query \
--args '{"sql":"SELECT sqlite_version()"}' \
--session-args '{"database_path":"/data/app.db"}' \
--allow 'fs=/data/**'
# Serve over MCP stdio
act run --mcp actpkg.dev/library/sqlite --allow 'fs=/data/**'
# Serve over MCP Streamable HTTP, at http://[::1]:3000/mcp
act run --mcp --http -l '[::1]:3000' actpkg.dev/library/sqlite --allow 'fs=/data/**'
Components can be referenced as:
actpkg.dev/library/sqlite (a tag or @sha256: digest is optional)https://example.com/component.wasm./component.wasmRemote components are cached in ~/.cache/act/components/.
The default mode is ask: an interactive run prompts, a headless one denies.
Grants come from flags, or per profile in ~/.config/act/config.toml.
Aliases: fs = wasi:filesystem, http = wasi:http, sockets = wasi:sockets,
creds = act:credentials; output always shows the full id. IPv6 goes in
brackets (http=[::1]:8080). A rule never exceeds what the component declared.
act run --help lists every class and its shorthand.
run and call write a structured audit trail to stderr: what component is running and under what capability modes, every capability decision as it resolves, and a per-call summary. It is on by default and independent of RUST_LOG — only --no-audit (or [audit] enabled = false in the config file) turns it off.
audit: act-cli/tests/fixtures/fs-canary.wasm sha256:f17cda │ act:credentials=deny wasi:filesystem=ask wasi:http=deny wasi:sockets=deny
audit: ⚠ declared ask, no prompt channel — every access will be denied: wasi:filesystem
audit: ? ask-deny wasi:filesystem /tmp/probe.txt no prompt channel mode:ask
audit: ● read tool-error 1ms args:43ebc7 req:0005a4
That's a real, captured transcript of one headless call with no --grant: the first line is the instantiation header (component, digest, resolved mode per capability class); the second warns that a declared ask capability has no prompt channel to answer it, so every access degrades to deny; the third is the immediate denial (denials and asks print the moment they resolve, never batched); the fourth is the per-call rollup — outcome, duration, an args: digest of the tool arguments (or the full values with --audit-args), and a req: id for joining this line back to a client log. Allowed operations coalesce into that rollup line instead of one line each, e.g. filesystem: 12 read under /data/**.
run --mcp --http)act run --mcp --http -l <addr> serves the same MCP server as stdio over
Streamable HTTP, at one endpoint: /mcp. --http requires --mcp. The
earlier REST binding (/info, /tools, …) was removed in 0.12.0.
# Embed act:component metadata, act:skill, and WASM custom sections
act-build pack target/wasm32-wasip2/release/my_component.wasm
# Validate without modifying
act-build validate target/wasm32-wasip2/release/my_component.wasm
# Publish as a CNCF Wasm OCI Artifact
act-build push my_component.wasm ghcr.io/you/my-component:0.1.0 \
--also-tag latest \
--source https://github.com/actpkg/my-component \
--skip-if-identical
Metadata is resolved via merge-patch from project manifests:
Cargo.toml, pyproject.toml, or package.json (name, version, description)[package.metadata.act], [tool.act], or "act" in package.json)act.toml — highest priority, applied lastact-build push produces artifacts conformant with the CNCF
TAG-Runtime Wasm OCI Artifact spec:
manifest config has media type application/vnd.wasm.config.v0+json
(with architecture, os, layerDigests, and
component.{exports,imports} derived from the component's exports
and imports), and the layer is application/wasm.
Authentication is resolved in order: OCI_USERNAME/OCI_PASSWORD
env, then GITHUB_TOKEN for ghcr.io, then ~/.docker/config.json
(or $DOCKER_CONFIG/config.json), then anonymous.
RISC-V (riscv64) is a first-class target. Regressions on RISC-V are release-blocking.
A glibc build of act or act-build requires glibc 2.34 or newer —
Debian 12, Ubuntu 22.04, RHEL 9 and later. This is a supported-platform
commitment, not an incidental build setting: it is asserted in CI, and lowering
it is a breaking change.
Which channels it applies to:
The floor is one symbol. DNS SVCB/HTTPS lookups call res_query(3), which
glibc did not export under that name before 2.34 — earlier releases had only
__res_query, and a modern glibc keeps that as a compat symbol new code cannot
link against, so there is no spelling that satisfies both. Nothing else in the
binary requires past glibc 2.33.
On an older distribution, use a musl build: musl exports the symbol outright and
carries no floor. Building from source does not lift the requirement — it is the
same call — so musl is the answer there, not cargo build.
cargo build --release # both tools
cargo build -p act-cli # act only
cargo build -p act-build # act-build only
Set RUST_LOG=act=debug for verbose output.
MIT OR Apache-2.0
CLI host for ACT (Agent Component Tools) WebAssembly components
{ "mcpServers": { "actcore-act": { "command": "npx", "args": [ "-y", "@actcore/[email protected]" ] } }}Araçlar
Henüz araç listesi yok. Uzak sunucular ilk sağlık kontrolünden sonra bir liste alır.
SSS
Bu sayfadan Cursor, Claude Desktop, Claude Code veya VS Code için stdio yapılandırmasını kopyalayın. PlugMCP proxy'sini değil, yayıncının kurulumunu kullanır.
Bu kayıtta gerekli bir ortam değişkeni listelenmiyor.
@actcore/act yerel olarak stdio üzerinden çalışır.
Son kontrol: 2026-10-26. CLI host for ACT (Agent Component Tools) WebAssembly components