AI agents · MCP

Your AI agent runs the infrastructure. You keep the decision.

Muppy ships an MCP server. Claude (on claude.ai, Claude Desktop or Claude Code) or any other MCP client reads the same information you do, runs a closed list of methods and waits for a human for everything else. The boundary is written down in black and white, and the agent cannot move it.

The rules of engagement

Three rules, the same across every domain.

01

Data is read-only

Write, create, delete: closed on every model. For an agent to change data, you open the model yourself, for as long as you choose, and every write still goes through a request that you approve.

02

Free in dev and test, on request elsewhere

Every resource carries a qualifier (dev, test, staging, prod, infra…). In dev and test, the call runs. Everywhere else, or if the qualifier is unknown, an authorisation request is created and nothing runs until you approve.

03

Every command is logged

Every _exec method leaves a trace: command, output and exit code, whether it was approved or not. Passwords passed on the command line are masked. Entries are kept for 180 days by default.

Resource categoryDecision
dev, testexecuted immediately
prod, staging, demo, infra, decom, tmplauthorisation request nothing runs before approval
unknown (no qualifier)authorisation request in the same way
host with “AI Managed” granted for a periodexecuted until it expires or is revoked

docs.muppy.io/muppy-mcp

Approval

You approve what is going to run, in plain text.

When a call is held back, you receive a notification with a button to open it. The request shows the resource, the method and its arguments decoded in plain text. On approval, Muppy runs exactly what the agent sent. A request left unanswered expires.

Right (scope)What it opensGrant
mcp:discoverythe list of domains, models, fields and methodsalways
mcp:readsearch and read recordsalways
mcp:sourceread the Python code of an exposed methodfor development
mcp:executecall an exposed method, according to the ruleswhen the agent has to act
mcp:writecreate, change, delete, according to the rulesrarely
Two MCP servers

One for your administrators, one for your teams.

Muppy · infrastructure

For administrators

Hosts, PostgreSQL clusters, Kubernetes clusters and releases, networking, App Servers, task queue. Fourteen generic tools, organised by domain.

Manganese · tenants

For your teams and their agents

Only their own App Servers, through the mgx_* methods: create, build, deploy, resize, run, read logs. Isolation between tenants is guaranteed by this server.

No shell

No shell on the Muppy server itself, and no updating or restarting Muppy by the agent.

No kubeconfig

Kubernetes goes through Muppy’s methods (sync, logs, patch), under the same rules.

No free-form HTTP

To see what an application responds, the agent creates a health check, which leaves a history.

Documentation for agents

Give your agent the docs URL. It does the rest.

Every page of docs.muppy.io also exists as raw markdown. An llms.txt index lists every page, and llms-full.txt gathers them into a single file. The IDE of every App Server ships Claude Code, which knows how to fetch them.

Next step

Which task would you hand to an agent tomorrow?

A test server per branch, a cluster diagnosis, an upgrade rehearsed in staging… Let’s look together at what an agent can do for you, and where it will have to ask.

You describe your project

Four fields, no phone number required.

We talk it through for 30 minutes

Architecture, hosting constraints, security, taking over what you already run.

You receive a written proposal

Scope, timeline and a quote, backed by the public documentation.

Prefer to try first? Try Manganese, free beta

Your project