List every client and which providers each can actually reach.

connected means the session opens right now, not that a credential is filed. Those are different facts, and reporting the second as the first is how two dead sessions read as connected for a day: nothing local can tell them apart, because OAuth grants a token and never says another word about it.

So this asks each provider, concurrently. Pass check=false to skip that and report only what is stored, which is instant and was the old behaviour.

stored is the union of two different things and says which is which. api_key is a pasted key, used by the REST adapters; mcp_session is an OAuth session, used by the provider's own tools. A provider can have one and not the other, which is how plan_mail_setup refused a client that client_status had just called connected. Neither list is a claim that the credential works: it is a claim that one is filed.

Answer one question across every client at once.

Read-only by design: this is the one place that spans containers, so it can never mutate. need is one of: "email_unprotected", "no_dmarc", "domain_unresolved".

Ask one question about every client at once, using their own accounts.

Where find_across_clients answers the questions the check catalogue already asks, this reaches each client's provider account through that provider's own MCP server, so it can answer ones nobody wrote a check for. Only clients with a session are included.

Read-only by construction: every tool it holds is filtered to those the provider marks read-only, so a tool that changes anything is not present to be called. Naming one client is what unlocks writes (D5).

Check every client at once and report only what needs attention.

The thing an operator actually wants running: silent when everything passes, and a list when it does not. Nobody runs thirteen checks by hand on a dozen clients, which is why the failures that break nothing visible survive for weeks.

Read-only across every client, like find_across_clients. It answers the whole catalogue rather than one question, and it names the client beside every finding, because a finding without one is useless to somebody looking after a dozen.

Do something inside one client's accounts, using their own tools.

The other half of read across, write within. ask_across_clients spans every client and can only read; this is one client and can act, and naming them is what unlocks it.

The agent is built with that client's sessions and no others, so a request needing a second account has nothing to reach with rather than a rule telling it not to. Every change is written to the run log as it happens: open the control room to watch, or read it back afterwards.

What this client's account with this provider can actually be asked to do.

Every provider here runs its own MCP server with its own tools, and this returns them: the name, what it does, its argument schema, and whether the provider marks it read-only. Pair it with call_provider_tool, which invokes one.

This is how you do work Munim has no verb for. There is no per-operation tool to look for, because modelling one provider's tools as another tool's parameters is a losing game: Cloudflare's execute takes JavaScript. Read this list, then call what it names.

read_only is what the provider says about its own tool, and null means it said nothing. It is reported, not enforced; naming a client is what unlocks writing (D5).

names_only returns the name and read_only and nothing else, which for Resend is 2KB against 122KB. Use it first: the full listing has exceeded a caller's response limit outright. matching filters on the name, the description and the argument schema, so "which tools take a teamId" is answerable, which it is not by name and description alone.

Call one of a provider's own tools with one client's credentials.

The write half of the passthrough. tool and arguments come from list_provider_tools; the arguments are forwarded to the provider untouched, so anything that server accepts is reachable.

Munim's part is the credential: the call names a client and resolves that client's session alone, so one call touches exactly one account, and it is recorded in the run log with the tool and the arguments it was given. Read launch_status afterwards to see what was done.

No language model is involved, which is the point. This works with munim config ai off.

One HTTP call to a provider's own API, with one client's credential.

The way down a layer when a provider's MCP server does not publish what you need. Vercel's publishes no environment-variable write and no way to attach a domain to a project, so those are reachable through no tool at any layer; this is how they become reachable.

path is a path, not a URL, and that is enforced rather than assumed: an absolute URL would send this client's credential to whatever host it named. The provider's host is asserted before anything is sent.

Every call is recorded as a mutation whatever the method, because an HTTP verb is a convention and not an annotation, and this will not claim a read on the strength of one. The response body is deliberately not logged: a raw environment endpoint returns secret values.

Works for cloudflare, vercel and resend, the three whose REST base URL and header shape Munim knows. It is not a universal escape hatch.

What setting up email for this client's domain would change.

Reads what is already published and returns every record with the action it would take: create, update, merge or unchanged. Changes no DNS. Pair it with apply_mail_setup, which needs the plan id.

The one write here is creating the sending domain in the operator's own Resend account, because Resend does not publish the DKIM and SPF values a plan is made of until it exists. That adds nothing to anyone's DNS.

Carry out a plan from plan_mail_setup.

approved is required when the plan would replace or combine a record somebody put there on purpose. Creating one that does not exist is not a judgement call; changing one that does is, and it is someone else's live mail. Show the plan to the operator, then call this.

Register a client. Holds no credential - only a name and a domain.

What is known about one client. Never returns a credential.

connected is the live answer, for the same reason as list_clients. api_key and mcp_session say which store each entry in stored came from, because a client can have one and not the other and the two are not interchangeable.

Connect one provider for one client using a credential you paste.

Prefer munim connect for providers that publish an OAuth flow: it opens a browser, and no secret passes through the coding agent at all. This exists for providers that offer nothing else - Resend, for one.

Check a client or a domain. Registers it on first mention.

target can be a client you have already added, a domain belonging to one, or a domain nobody has mentioned before - there is no setup step. What passed or failed is decided by live DNS, never by a model. What a failure means is the agent's part: it reads more records if it needs them and writes the explanation the owner gets. Open the control room to watch, or read the report afterwards.

Check a client's domain, then repair what can be repaired safely.

check explains what is wrong. This acts on it. The same thirteen deterministic checks run first and are still never decided by a model; what a model decides is which repair to reach for, out of a set of tools that cannot do anything else.

Anything that would replace a record somebody already published stops and waits for a person. Approve it in the control room, or call apply_mail_setup with approved=true. Creating a record that is absent is not a judgement call and does not stop.

With agents off the checks still run and their findings still stand, exactly as check degrades: only the repair needs a model.

Read a run without waiting on it.

A launch polls DNS and can outlast a single tool call, so progress is read from the run log rather than held open.