List every client and what each one can actually reach.

Returns one row per client with their domain, stored (every provider with a credential filed), api_key and mcp_session saying which store each came from, and connected, needs_login and unreachable from asking each provider live. Pass check=false to skip the live probes and report only what is stored, which is instant.

Use client_status for one client in the same shape.

Run one named check across every client at once.

Returns one row per client with that check's result and the evidence behind it. Read-only, and it never writes.

need is a check name from the catalogue, such as spf_single, dmarc_policy or dkim_present. Use audit_all_clients to run the whole catalogue instead of one check, and ask_across_clients when the question is open-ended rather than one of these.

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).

Run the whole check catalogue against every client, reporting only what needs attention.

Returns one entry per client that has something wrong, naming the client beside each failing check, plus a run_id. Clients that pass are omitted entirely, so an empty result means every client is healthy.

Read-only across every client, and it never writes. Use check for one client with a report, and find_across_clients when you want one specific check across everybody rather than the whole catalogue.

Carry out a request inside one named client's provider accounts.

Returns what was done in the agent's own words, and which providers it had available. Every change is written to the run log as it happens, so launch_status reads it back.

The agent is built with only this client's sessions, so a request needing a second account has nothing to reach with. Use ask_across_clients to read across every client instead, and fix when the job is repairing DNS or mail, which is deterministic and stops for a person before replacing a record somebody published.

List the tools this client's account with this provider actually publishes.

Returns each tool's name, description, argument schema, and whether the provider marks it read-only. read_only is what the provider says about its own tool; null means it said nothing, and it is reported rather than enforced.

Read this before call_provider_tool, which invokes one of them. Start with names_only, which returns names and read-only flags alone: for Resend that is 2KB against 122KB, and 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.

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

Returns the provider's own result, plus a run_id. Arguments are forwarded untouched, so anything that server accepts is reachable. Take tool and arguments from list_provider_tools rather than guessing.

One call resolves one named client's session and touches no other account, and the tool and its arguments go to the run log; read it back with launch_status. No model is involved, so this works with agents off.

Make one HTTP call to a provider's own REST API with one client's credential.

Returns the status and the parsed body, plus a run_id. Every call is recorded as a mutation whatever the method, because an HTTP verb is a convention rather than a guarantee, and the response body is never written to the log.

Use this only when the provider's MCP server publishes no tool for the job: list_provider_tools first, call_provider_tool if it names one. Vercel publishes no environment-variable write and no project-domain attach, which is what this exists for. Works for cloudflare, vercel and resend, the three whose REST shape Munim knows.

Work out what setting up email for this client's domain would change.

Returns a plan_id and every record that would be created or replaced, each with its current published value beside the proposed one, and a count of how many need a person to approve them. Touches no client DNS.

One honest note: planning creates the sending domain in your own Resend account, because Resend publishes no DKIM values until the domain exists. Pass the plan_id to apply_mail_setup to carry it out, or use fix, which plans and applies in one call and stops for approval in between.

Carry out a plan from plan_mail_setup.

Returns what was published and what was left unchanged, plus a run_id. When approval is needed and not given it returns needs_approval and changes nothing, so calling it again with approved=true is safe.

approved is required only for records that already exist. Creating one that is absent is not a judgement call; replacing one somebody published is theirs to make, so show them the plan first.

Register a client by name. Holds no credential, only a name and a domain.

Returns the client's id, name and domain.

Use this to write a client down before connecting anything. You do not need it first: naming a domain in check or fix registers it on the spot. Connecting a provider is a separate step, connect_provider.

What is known about one client: their domain, what is stored, and what actually opens right now.

Returns the client's name and domain; stored, every provider with a credential filed; api_key and mcp_session, saying which of the two stores each one came from; and connected, needs_login and unreachable, from asking each provider live. Never includes a credential value.

Use this for one client and list_clients for all of them. The two stores are not interchangeable: api_key is what the mail tools call REST APIs with, mcp_session is what a provider's own tools run on, and a client can have one without the other.

Store a pasted API key for one client and one provider.

Returns which provider was connected, never the credential itself.

Use this only for providers with no browser login, or when a REST API key is needed alongside a session: the mail tools call REST APIs and a browser session is a different credential. munim connect at the terminal does the browser login.

Run the deterministic check catalogue against one client or one domain.

Returns the failing checks with an owner-facing sentence for each, counts of what was checked and skipped, a run_id, and report_file, where the report was written. watch and report are control room URLs and appear only while it is running. DNS decides pass or fail, never a model; with agents on, a model adds the explanation and nothing else.

target may be a client name, a domain belonging to one, or a domain nobody has mentioned before, which registers it: there is no setup step. Use audit_all_clients to run the same catalogue across every client at once, and fix to repair what it finds rather than only reporting it.

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.

report_file is always written. watch and report are control room URLs and appear only while it is running; munim approve answers without it.

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 back without waiting on it.

Returns that run's events in order: what was checked, what changed, what is waiting on a person. Defaults to the newest run.

A check or a repair can outlast a single tool call, so progress is read from the run log rather than held open.