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.
Three rules, the same across every domain.
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.
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.
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 category | Decision |
|---|---|
| dev, test | executed immediately |
| prod, staging, demo, infra, decom, tmpl | authorisation request nothing runs before approval |
| unknown (no qualifier) | authorisation request in the same way |
| host with “AI Managed” granted for a period | executed until it expires or is revoked |
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 opens | Grant |
|---|---|---|
| mcp:discovery | the list of domains, models, fields and methods | always |
| mcp:read | search and read records | always |
| mcp:source | read the Python code of an exposed method | for development |
| mcp:execute | call an exposed method, according to the rules | when the agent has to act |
| mcp:write | create, change, delete, according to the rules | rarely |
One for your administrators, one for your teams.
For administrators
Hosts, PostgreSQL clusters, Kubernetes clusters and releases, networking, App Servers, task queue. Fourteen generic tools, organised by domain.
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 on the Muppy server itself, and no updating or restarting Muppy by the agent.
Kubernetes goes through Muppy’s methods (sync, logs, patch), under the same rules.
To see what an application responds, the agent creates a health check, which leaves a history.
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.
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
Odizy Your Odoo ERP, from branch to production
Manganese Complete App Servers, any stack
Manganese DevFleet Agentic remote dev for large organisations