emisar MCP
An agent runs servers through a catalog of declared actions: policy decides what runs and what waits for a person
- 330 ★ on the repository
- Last commit
Broad access
Why this level
- The agent runs commands on production servers, though only declared actions
- Policy decides actions and packs: a mistake in it or overly broad host permissions widens the damage
- The runner install needs sudo and an outbound connection to an external control plane
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add mcp/emisarDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewBroad accessThe tool can change data, run commands or handle secrets.
- The agent runs commands on production servers, though only declared actions
- Policy decides actions and packs: a mistake in it or overly broad host permissions widens the damage
- The runner install needs sudo and an outbound connection to an external control plane
This is third-party code. Review the repository files before installing.
What it does
emisar connects an MCP-capable agent to infrastructure through a list of pre-declared actions. Each action is described in a pack: which file to run, which arguments to accept and how dangerous it is. The model picks an action from the catalog and passes typed arguments; it never composes a command line for the server. A small runner on each host only opens an outbound TLS connection. The control plane checks scope and access policy and, when needed, waits for a person's approval. The runner rechecks the pack hash and arguments on the host itself and runs the declared command. It masks secrets in the output and writes every attempt to a hash-chained journal. The packs live in the repository catalog, from databases and clouds to firewalls and Docker. After the runner is installed, emisar suggests packs that match the host. You add your own actions as your own pack, and the MCP client needs no reconfiguration. The remote MCP server at https://emisar.dev/api/mcp/rpc connects through OAuth, and stdio clients use the emisar-mcp bridge. The repository also ships four agent skills, from installing the runner to responding to production incidents.
Who it is for. For DevOps engineers and SREs who want an agent to work incidents on production servers and keep each of its actions under policy.
Good fit when
- You want an agent to work an incident on a production host: reading logs, service status and metrics through declared actions
- You need human approvals for dangerous actions and an audit where denied and pending requests are visible
- You have many hosts and each needs its own set of allowed actions with no shared SSH access
- You want to give the agent a capability for a new system without reconfiguring every MCP client
- You need command output masked before it reaches the run history and the model's context
Not a fit when
- You need a generic execute(command) call or an SSH replacement: emisar deliberately does not offer it
- You need a process sandbox: emisar is not one, and the author suggests a separate isolation tool such as Coop
- You want a substitute for OS least privilege, change management and configuration management: emisar complements them
- You need a host without systemd: the runner installer is built for Linux with systemd
Example request
Check on host web-3 how long it has been up and what the load is, and show the result from the run history.MCP
- Transport
- stdio, http
- Authentication
- OAuth
Limitations
You need an emisar account, Linux with systemd and sudo, and outbound HTTPS to emisar.dev, registry.emisar.dev and the Sigstore trust-root servers. The release signature is verified with GitHub CLI. Without it the installer asks whether to continue on the checksum alone, and with `--yes` it warns and continues.
emisar is not a sandbox and does not protect from harmful actions that policy and the pack allow. Safety depends on which actions and packs you allowed, how policy and the runner are configured and what permissions the host has. The temporary plain-shell pack is for staging only: it is critical-risk, denied by default and must not be installed on production runners.
There are two licenses: the runner, bridge and packs are Apache 2.0, and everything else, including the control plane, is Business Source License 1.1. Commercial use outside the Additional Use Grant needs a separate license.
How to disable. For a client, run `emisar-mcp disconnect --client cursor` or `emisar-mcp disconnect --all`: the command touches nothing else in those files. Stop and remove the runner on the host by the instructions in `runner/README.md`, and revoke client keys in the console on the AI agents page.
FAQ
How do I connect emisar to Claude Code?
Install the bridge with `curl -fsSL https://emisar.dev/install-mcp.sh | sudo bash`. In an interactive terminal the installer runs `emisar-mcp connect`, opens a browser for one approval and offers to write the config into detected clients. You can also run `emisar-mcp connect --client claude-code` separately.
How is emisar different from SSH access for an agent?
The agent gets no shell and instead calls declared actions with typed arguments. Policy on the control plane decides what runs, what goes to approval and what is denied, and the runner rechecks the action on the host. Every attempt lands in the journal.
What is an action pack?
A set of declared actions for one system, such as Docker or Caddy. It describes the executable, the argument schema, the risk level, the timeout and the redaction. A pack is addressed by a hash of its contents, and the control plane pins the trusted hash.
Do I need to open inbound ports on the host?
No. The runner opens an outbound TLS WebSocket connection and keeps no inbound listener. Command results come back over that same connection.
Can I write my own pack?
Yes. The author-pack skill walks you through creating, validating, testing and distributing a pack, including through a private registry. New and changed custom packs wait for trust before the runner executes them.
Discussion
No questions or reviews yet.
Related
MCP serversA self-hosted gateway that merges several MCP servers into one endpoint with auth and tool selection
Self-hosted MCP server for running commands on remote servers over SSH, with tokens and roles
A secure MCP runtime through which an agent operates local machines, servers and containers
MCPM
mcpm
A package manager and registry for MCP on all platforms and clients: finds, adds and configures MCP servers, remembers the source and updates
A Node.js manager for MCP servers: it starts local servers, connects remote ones and gives a client one address, with a REST API for control
MCP Gateway Registry
mcp-gateway-registry
One registry and gateway for MCP servers, agents and skills: shared login, OAuth, audit, OpenTelemetry. Community project for Docker and cloud
Comparison with similar tools
Entries that share the main search query, and how they differ.
| Entry | Official | Authentication | Repository stars | Main difference |
|---|---|---|---|---|
| emisar (this entry) | yes | OAuth | 330 | |
| SSH MCP | no | API key | 840 | runs commands over SSH with classification and policies, while emisar gives no shell at all and runs only declared actions |
| Docker MCP server | no | not required | 749 | manages Docker containers, while emisar covers whole hosts through a catalog of packs |
README in short
The documentation opens with the security boundaries and limits of emisar and then routes you through sections from runner install to architecture. For project contributors it describes a local environment on Coop and Docker.