Loading ToolBench
One MCP server holding a live session with every client's account at once. Multi-account DNS, email, and domain management across Cloudflare, Vercel, Resend and other providers.
Munim provides 9 tools with descriptions and purpose, but significant quality gaps limit its rating to fair (C grade). All tools have descriptions (10-200 chars is baseline; most here are 100-300 chars, acceptable), and all are registered with input schemas. However, parameter descriptions lack the specificity required by the rubric: many omit format constraints, validation rules, and error recovery guidance. Tool names follow verb_noun convention (list_, find_, connect_, call_, ask_, plan_, apply_, work_on_, audit_), which is good. Schemas are present but underspecified, parameter types are defined (string, boolean, object) but lack enum constraints, length limits, and format declarations. Error handling is largely absent from tool descriptions; no guidance on what to do if a provider is unreachable or a credential is missing. The codebase shows awareness of safety (readOnlyHint/destructiveHint annotations in annotations.py), but tool descriptions do not expose this to agents. Output schemas are not documented anywhere in the tool definitions.
Carry out the plan from `plan_mail_setup`. Publishes DNS records and configures the mail provider.
Ask the same open-ended question of every client's provider at once, returning everything each one says. Use `find_across_clients` for questions that are in the catalogue, like `spf_single` or `dmarc_policy`.
Run every check in the catalogue across every client. Returns every result with the evidence behind it.
Call a tool from a client's provider. The tool must exist in that provider's catalogue and require only the arguments you name. Tools that need complex input or have high-consequence results will refuse and name what would be needed to call them safely.
Open a browser to connect this client to a provider. Stores the session token in the keychain and records the client in the registry. If you are asked to configure a provider first, use `config_provider`.
Output schemas are not documented. Tool descriptions lack 'returns' or schema declarations. Agents cannot plan downstream calls or extract required fields for chaining.
'arguments' parameter in call_provider_tool is typed as 'object' with no schema constraints. Agents cannot know what fields are valid for a given provider tool. Needs dynamic schema or validation guidance.
Parameter descriptions lack validation rules. 'check' param in list_clients has no detail on what 'check=true' actually does or what network I/O it triggers. 'need' param in find_across_clients cites examples (spf_single, dmarc_policy) but no enum constraint. Agents must guess which check names are valid.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
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.
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.
Plan the full email setup for a domain: what DNS records to publish and how to configure a mail provider. Returns a plan that names what would change and prompts for confirmation before anything is written.
Set the working client for the session, so later questions default to asking about this one. Use with `client_status` to confirm it worked.
Error handling is absent. Tool descriptions do not specify what happens if a provider is unreachable, no credential is stored, or a check fails. Agents have no recovery path beyond retry.
Safety annotations (readOnlyHint/destructiveHint) are used in code (toolsets.py _is_read_only check) but not exposed in tool descriptions. Agents cannot see which tools are read-only vs destructive. 'work_on_client' is WRITE but description does not emphasize state modification.
'client' and 'provider' parameters in multiple tools are required but lack guidance on valid values. What are the available providers? How is a 'client' named, domain, email, arbitrary string? Agents must discover via trial and error.
No pagination support documented. 'list_clients' and 'audit_all_clients' may return large result sets, but there are no limit, offset, or cursor parameters. Large lists can blow context windows.
Credentials and OAuth flows are mentioned in descriptions but secret injection is not explicit. Code references keyring (line 'toolset_for(client: str, provider: str, *, keyring=None)'), but tool descriptions do not clarify that no API keys are passed as parameters.