Munim

One MCP server holding a live session with every client's account at once.

A coding agent can be logged in to one Cloudflare account. One Vercel. One Resend. Connect a second client and the first goes away. So the person looking after a dozen small businesses runs a dozen agent sessions, and none of them can answer a question about more than one client.

Munim holds them all. Each client gets its own registration with the provider, its own token and its own namespace in the tool list, so one agent can read across every client and write inside the one you named.

Kloudfirst       -> Kloudfirst@gmail.com's Account   (3 tools)
Ivy & Fern       -> ivy@example.com's Account        (3 tools)

both sessions opened concurrently, one process, no logout

That is a real run against two real Cloudflare accounts, not a diagram. The second account is a client's and their address is replaced here: they did not consent to a public repository, and this file is also the PyPI page. Reproduce it with your own two: scripts/cross_account_probe.py.

Install

Requires Python 3.10+. Nothing else: no Node, no build step, no account to create first.

uv tool install munim          # or: pipx install munim, or: pip install munim
claude mcp add munim -- munim-mcp

If a coding agent is doing the install for you, point it at llms-install.md, which says the parts that are easy to get wrong when nobody is watching the terminal, and where it has to stop and hand back.

Start

munim clients                          # who you look after, and what is connected
munim clients add "Ivy & Fern"         # write one down, connect nothing yet
munim connect "Ivy & Fern" cloudflare  # a browser opens; that is the whole setup

There is no wrong order. Connect first and the account you sign in to names the client, or write the client down first and connect whenever. Both arrive in the same place.

Then ask your coding agent something a single logged-in session cannot answer:

which of my clients has a domain expiring this quarter?
check ivyandfern.co.uk for Ivy & Fern Studio

Doing the work, not just the diagnosis

Munim does not wrap each provider in verbs of its own. Every provider here runs its own MCP server with its own tools, so Munim forwards them and supplies the credential:

munim tools "Ivy & Fern" cloudflare          # what that account can be asked to do
munim call  "Ivy & Fern" cloudflare execute --args '{"code": "..."}'

Your coding agent gets the same two as list_provider_tools and call_provider_tool. There is no model in this path, so it works with agents off, and every call is written to the run log with the tool and its arguments. A call names one client and resolves that client's credentials alone.

When a provider's own MCP server does not publish what you need, call_provider_api goes a layer down and makes one HTTP call to that provider's API with the same client's credential. Vercel publishes no environment-variable write and no way to attach a domain to a project, which is what this is for. It takes a path and never a URL, and refuses anything that would send the credential to another host.

Munim is local by default. The checks, the audit and the mail plan are deterministic: they never needed a model and never call one, and neither does the passthrough above. Three tools can also reason about what they find (check, work_on_client, ask_across_clients), and that is switched off until you ask for it, so having a key lying around is not the same as consenting to use it.

munim config ai key gemini   # prompts, stored in ~/.munim/credentials.json
munim config ai on           # takes effect on the next call, no reconnect
munim config ai              # what is on, on what, and where each came from

Hosts are Amazon Bedrock, which works out of the box, plus Google Gemini and Anthropic, which Strands ships as extras: pip install 'munim[gemini]'.

One thing this does not change: Munim runs as an MCP server, so whatever its tools return goes into your coding agent's context and therefore to whichever model that agent runs on. Turning agents off stops Munim calling a model of its own; it cannot change how MCP works. The privacy policy says so plainly.

munim doctor says what is set up, what is not, and the exact command to fix each gap. Start there whenever something is unclear.

Where to find it

The video is a real run against a real client's domain: fifteen deterministic checks find two faults, a Strands agent explains them in the owner's language, and the repair stops at an edge condition because that client is not connected to the provider a repair would need. Nothing in it is staged, which is also why there is no repair on camera.

To run it yourself without installing anything: scripts/check_client.py runs the check catalogue against one client and writes the report, and scripts/fix_client.py runs the repair graph. Both use the same code paths as the check and fix MCP tools, with no agent in front of them.

Documentation

Why this exists

One person maintains the web and email setup of a dozen small businesses. The clients own the accounts; the operator holds delegated access and does the work. Every provider allows one login at a time, so the workaround is a separate agent session per client.

The costly part is not the switching. It is that a mistake in mail setup breaks nothing visible. Get an A record wrong and the site is down in minutes. Get the SPF record wrong and the client's invoices quietly stop arriving, and nobody notices for weeks.

A munim is the steward a business owner trusts to keep their books and handle their affairs without being asked each time.

Disclosure

Built with AI assistance. No pre-existing code was incorporated; the repository was created during the submission period.

Licence

MIT. See LICENSE.

Contributing

CONTRIBUTING.md says how to run the two suites and what a good change looks like here, which is mostly about writing down why. docs/DECISIONS.md is the numbered log those reasons live in, and several of its entries reverse an earlier one.

Adding a provider needs no Python. Eleven ship and only the first needed any: a provider here is a row in a table, and munim servers add <name> <url> works out how that server authenticates by asking it. munim servers export <name> then prints the row for a pull request. That lane asks for the row, a page copied from docs/providers/TEMPLATE.md, and the measurement you took. It does not ask for a failing test, because tests/test_provider_docs.py already fails when a row arrives without a page.

Security issues go in a private advisory rather than an issue. SECURITY.md says what is in scope, and lists what is already known and deliberate so a report can skip it.