From your own agent: the MCP server

agentry-mcp is a small MCP server that drives the agentry CLI you already have, so Claude Code, Codex or any MCP host can search a registry, read a QuickAgent's capability contract, verify a release, check and prepare your machine, install and remove QuickAgents, run them, and hold an interactive session with one — from inside your own agent, behind the same consent the CLI asks for on a terminal. It bundles nothing: the CLI is yours, with your login, your consent memory and your runner policy. Source and README: blaktron/agentry-mcp.

Install

You need Node 20 or newer, the agentry CLI and, for the session tools, python3. The site's install script installs the CLI, puts it on your PATH, and installs Node.js for your user if it is missing (Installing the CLI with one command):

curl -fsSL https://secureagentry.net/install.sh | sh     # macOS and Linux
irm https://secureagentry.net/install.ps1 | iex          # Windows, in PowerShell

Its last lines are AGENTRY_BIN=<path> and AGENTRY_NODE=<path>, the two programs the server needs. The server is on Downloads as agentry-mcp-<version>.tar.gz, one file for every platform. Check its SHA-256 against the one on its card, then unpack it anywhere:

tar -xzf agentry-mcp-<version>.tar.gz

The Downloads page also has a prompt you can paste into your coding agent to have it do all of this for you. The prompt runs the install script, unpacks the server and adds it with the two paths the script printed, so a host started before the install still finds them. To work on the server itself, build it from its source instead (npm install && npm run build); the server is then agentry-mcp/dist/index.js.

Then add it to your host. Claude Code — /mcp in a session lists agentry and its tools afterwards:

claude mcp add agentry -- node /path/to/agentry-mcp-<version>/dist/index.js

Codex — codex mcp list shows it afterwards:

codex mcp add agentry -- node /path/to/agentry-mcp-<version>/dist/index.js

When the CLI is not on the host's PATH (a host started before you installed it, or one launched from a desktop menu), pass AGENTRY_BIN (claude mcp add agentry -e AGENTRY_BIN=/path/to/agentry -- node …; codex mcp add agentry --env AGENTRY_BIN=/path/to/agentry -- node …). Sign in to a registry once in a terminal with agentry login; the server uses that login and never sees the token.

The server runs agentry --version once at start and refuses to start without a CLI that has the plan modes it previews with (install --plan, run --plan); the version floor is in its src/cli.ts and README. The CLI has no release tag for them yet, so today the floor is nominal and the modes are probed directly; a dev build of the CLI is accepted and the start-up line says the floor was not checked.

What the tools are

Every tool is one CLI invocation with an argv built from typed arguments — never a shell string, and a value that looks like a flag is refused — and every result is the CLI's own JSON in an envelope: result, exitClass (the CLI's exit taxonomy: ok, cli, usage, verify, policy, compile, gateway, harness, timeout, budget, outputSchema) and log, the CLI's last lines. A non-zero exit whose stdout is still JSON comes back as that JSON with the class beside it; one without JSON is a tool error naming the class. The runner reference lists the shapes.

Tool	Runs	For
agentry_search	agentry search --json	finding QuickAgents by text, tag, mode, capability
agentry_info	agentry info --json	a QuickAgent's latest release and its capability contract
agentry_verify	agentry verify --json	a release's digest and attestation verdict, as the registry reports them
agentry_doctor	agentry doctor --json	what this machine lacks for a run: docker, the policy, the key's variable name
agentry_setup	agentry setup --json	writing the model provider into the runner policy and pulling the images
agentry_install	agentry install --plan --json, then agentry install --json consented	putting a QuickAgent into Claude Code, Codex or OpenClaw (a run records its own consent)
agentry_uninstall	agentry uninstall --plan --json, then agentry uninstall --json consented	removing a QuickAgent's runner install, profile and consent record
agentry_list_installed	agentry list --json	every install record on this machine
agentry_run	agentry run --plan --json, then agentry run --mode autonomous --output-format json consented	one autonomous run, with the receipts named in the result
agentry_validate	agentry validate --json	an author's workspace against the registry's rules and scanners, offline
agentry_session_start	agentry run --plan --json --mode interactive, then agentry run --mode interactive consented, on a terminal the server owns	opening a chat with a QuickAgent
agentry_session_send	one line typed into that chat	a turn in, the reply out
agentry_session_close	/finish or /quit typed into it	ending the chat; the transcript and receipts in the result

Not there, on purpose: signing in (agentry login once in a terminal) and publishing (agentry publish in a terminal, where you see the pipeline's verdict).

Consent, in two calls

The CLI asks you on a terminal before it installs or runs anything. The server has no terminal, and the model is not you. So every tool that writes or runs is two calls:

1. Preview. The call without confirm runs the CLI's plan mode, which asks nothing and records nothing, and returns what consent would cover — the release that resolved, its capability contract, whether it is signed, the refusal the CLI would meet, and for a run the whole compiled plan (the tools it would be served, the gateway and proxy shape, the budgets) — plus a digest: an HMAC-SHA-256, under a key only this server process holds, over exactly those facts. The model is told to show you the contract.
2. Confirm. The same call with confirm set to that digest. The server runs the preview again, refuses if anything changed, and only then runs the command with the CLI's own consent flag. A release with no attestation, or a local workspace, needs acceptUnsigned: true on the confirm as well, which the model is told to pass only if you said so.

The digest is the control, not the instruction: a model cannot confirm what the server did not show it, since it cannot mint a digest from the facts, and the consent flags reach the CLI from no other path (the repository's CI greps for it). When your host supports MCP elicitation — Claude Code does in its interactive mode — the server also asks you directly before the write, and a "no" cancels; a host without it gets the two-call shape alone, and a headless host that declines the question gets a "no". An install or a run names the release the preview resolved, never a floating range.

Running and sessions

A run through the server is the CLI's run: the same isolation, the same receipts. The result names the receipts directory, which is the record of what was enforced, and its runPlanSha256 is the preview's planSha256. The task input is written to a temp file the server removes after the run; intake answers go by id; a run stops at timeoutSeconds, or at the runner policy's own budget when the call names none; an interrupted run tears down and writes its envelope, and a CLI that has not answered the interrupt after a minute is killed, which the error says. Progress — the CLI's narration — streams to a host that asked for it, for runs and setup.

An interactive session is the CLI's own chat on a terminal the server owns, driven as you would drive it: a line, Enter, the reply. The reply to each turn is read from the run's events receipt, which the CLI writes as the session goes and redacts as it does, not scraped off the screen; the raw terminal stream is kept beside the output folder. One session per server at a time; the release's idle timeout and budgets end it as they would in a terminal, and the next turn reports that; closing returns the transcript and the receipts. A turn is one plain line — the chat's own commands are not turns, and the model cannot reach them.

What the server holds

No credential of its own. The registry token stays in the CLI's config; the runner policy names the environment variable that holds the model provider's key, and the CLI reads it from the environment the server was started in — the server never reads it, and no tool result carries it: agentry_doctor and agentry_setup report key names only. The registry reports each release as scanned, with a finding count, and signed or unsigned — a verdict, not a promise; the server's tool descriptions and instructions say the same, and the model is told to say what the registry says.