Claude Code plugin and MCP server

The airdress CLI is also an MCP server. An editor, or a model inside one, gets the same reads and writes the CLI does, offered as tools: your airdresses and their status, the functions dev loop, resources, recent inbound events, the agent bus and agent chat, and every tool your own functions publish.

Your own operator for now

MCP, the tools your functions publish, and the agent bus and agent chat work today on an operator you run yourself and are coming to an airdress we host. What runs where: feature matrix.

There are two ways in: the Claude Code plugin, which is in preview and not published yet, and airdress mcp serve, which works today with any MCP client.

The Claude Code plugin (preview)

Not published yet

The Airdress plugin for Claude Code is a preview. Its repository, airdress-co/airdress-claude-code, is public so you can read and rebuild it, but no release has been published, so installing it from the marketplace does not work yet. Until it does, use airdress mcp serve below.

Once it is published, installing it will be three commands inside Claude Code:

/plugin marketplace add airdress-co/airdress-claude-code
/plugin install airdress@airdress
/airdress:login

It targets Linux and macOS. Windows is not supported: the local path needs a device host and a keychain the plugin does not have there.

What it gives you

Command	What it does
/airdress:login	Sign in
/airdress:status	Account, airdress, what it has turned on, how the server was verified
/airdress:fn [name]	Functions: list, versions, logs, deploy
/airdress:bus	The agent bus: who is connected, topics, unread
/airdress:claim <name> [topic]	Claim a shared task before working on it

The plugin ships a verified copy of the MCP server and borrows your airdress sign-in; it writes no second copy of any token.

Verified before it runs

Claude Code runs what a plugin says to run and checks nothing about it, so the plugin’s launcher checks first. Before any byte of the server executes:

1. the bundle’s SHA-256 matches the pin in the plugin’s own commit;
2. its signature’s certificate chains to Sigstore’s Fulcio and was valid when it signed;
3. the certificate’s identity is exactly the plugin repository’s release workflow at that tag;
4. Rekor’s inclusion proof checks out, offline, against a trust root embedded in the plugin;
5. the version is not on the signed withdrawal list.

Any failure prints the check, the expected value and the actual one, and refuses. The launchers are committed and rebuild byte for byte in a pinned toolchain; the repository’s README says how to check that yourself.

Settings

Setting	Default	What it does
CLI profile	the active one	Which airdress profile to act as
Default airdress	resolved	Which airdress a tool acts on when it names none
Read only	off	Remove every tool that changes anything
Join the agent bus	off	Register this session on the bus at start
Bus topics	general	The topics this session joins
Session label	<host> · <repo>	How other sessions see this one

Writing to the bus needs this machine approved as an agent device; without one, the bus can be read and not written, and the tools say so.

Any MCP client: airdress mcp serve

Point the client at the CLI as a stdio server:

{
  "mcpServers": {
    "airdress": {
      "command": "airdress",
      "args": ["mcp", "serve"]
    }
  }
}

Useful flags:

airdress mcp serve --read-only true              # hide every tool that changes anything
airdress mcp serve --default-airdress home       # when a tool names none
airdress mcp serve --profile work                # act as another profile
airdress mcp serve --bus true --bus-topics general
airdress mcp catalogue                           # the tool list, as JSON, without serving

--read-only really is: a model that asks for a hidden tool by name is refused, not quietly obliged.

The tools

Area	Tools
Account	login, whoami, logout
Airdresses	airdresses_list, airdress_status
Functions	function_list, function_versions, function_logs, function_templates, function_validate, function_deploy, function_promote
Resources	resources_list, resources_get, resources_apply
Events	ingress_events_recent
Your functions’ own tools	bridge_list, bridge_call, and each one re-exported as fn_<tool>
Agent bus	bus_sessions, bus_topics, bus_read, bus_thread, bus_claims, bus_state_get, bus_state_list, bus_topic_policy, bus_post, bus_reply, bus_ack, bus_claim, bus_renew, bus_release, bus_handoff, bus_state_put, bus_state_delete
Agent chat	chat_conversations, chat_read, chat_send

airdress mcp catalogue prints each tool’s schema and whether it is read-only.

What the server promises

• It holds no credential. Your profile store owns the tokens; the server refreshes through it and writes no second copy. Nothing it returns (a tool result, an error, a log line) carries a token, a device code or a signing key.
• It contacts your hub and your airdresses, and nothing else. No analytics, no crash reporting, no tracing exporter.
• stdout is the protocol. Every human-facing line goes to stderr.

What the model provider sees is what any model provider sees: the conversation, including whatever a tool returned into it. If you ask for your function’s logs, those logs are in the conversation.

An airdress can switch the editor path off. Then every tool answers one sentence saying so. That switch makes this client behave; it is not a fence around your own data, which the CLI reaches either way.

Related

• Agents: agent devices, the bus and agent chat.
• Functions: the dev loop the function tools drive.
• Get started with the CLI: sign-in and profiles, which the MCP server reuses.