Opsmaxx MCP server

@opsmaxx/mcp

Connect any stdio MCP client to a running OpsMaxx desktop app.

npx -y @opsmaxx/mcp

Why this exists

OpsMaxx already exposes an MCP server over Streamable HTTP on 127.0.0.1, and clients that can express an HTTP server with an Authorization header — Claude Code, Codex — should use that directly. It is one command:

opsmaxx claude

Some clients cannot. Claude Desktop, notably, does not read url or headers from claudedesktopconfig.json at all, so an HTTP MCP server is simply not expressible there. This package is the adapter for those: stdio in, authenticated HTTP out.

What it does, and does not

It is a protocol relay. Every message is forwarded unmodified in both directions. No tool, session or policy logic lives here — access groups, approvals, secret redaction and the audit log all stay in the app, so a stdio client gets exactly the same treatment an HTTP client would.

It talks only to 127.0.0.1. It is not a server, it holds no state, and it cannot reach anything OpsMaxx would not already allow.

OpsMaxx must be running, with the bridge enabled under AI & MCP.

Configuration

Environment first, then the session the opsmaxx CLI has already cached:

If none are set it reads the session cached by the CLI, so running opsmaxx claude once is enough and there is no token to paste.

Claude Desktop

{
  "mcpServers": {
    "opsmaxx": {
      "command": "npx",
      "args": ["-y", "@opsmaxx/mcp"],
      "env": {
        "OPSMAXX_MCP_TOKEN": "your-session-token",
        "OPSMAXX_MCP_PORT": "5177"
      }
    }
  }
}

Restart Claude Desktop afterwards.

A note on the token

The token is scoped to one workspace and one access group, and it is the same secret you would otherwise paste into a client's config by hand. It is not an SSH key and it is not a vault password: an agent holding it still never receives an SSH password, a private key, a database credential, a hostname or an interactive root shell. See the threat model.

Licence

MIT. Source: