Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations present, the description carries the full burden of disclosing behavior. It clarifies that only name and domain are stored (no credential), but does not mention side effects, error handling, or permissions. This is partial transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded with the core action. It avoids extraneous details and is easy to parse, with the key verb and object appearing first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is adequate for a simple add operation, but it does not address potential outcomes (e.g., duplicate client, validation failures) or return behavior. Since there is no output schema, more context about expected results would improve completeness, though it is not critically lacking.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides detailed descriptions for both parameters (name and domain), achieving 100% schema coverage. The tool description's mention of 'only a name and a domain' adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Register a client') and the resource (client), making the purpose unambiguous. It also distinguishes itself by noting it holds no credential, which helps differentiate it from other client-related operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool over alternatives such as list_clients or work_on_client. It only implies that it is for adding a new client, but provides no explicit guidance or contrast with sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears full responsibility for disclosing effects. It warns that the action may replace or combine an existing record, emphasizes that modifying existing data affects someone else's live mail, and indicates that explicit operator approval is needed in those cases. This is adequate though not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loads the core purpose, then adds necessary approval caveats. Some phrasing is a bit cryptic ('somebody put there on purpose', 'someone else's live mail') but it does not waste words and remains understandable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's mutation-like nature and the absence of an output schema, the description provides enough context about when to call it, what it may change, and the approval requirement. It does not describe return values or failure modes, but these are not essential for an agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the descriptions add useful constraints beyond basic types: `client` specifies the registered name and credential resolution, `plan_id` ties to the planning output and cross-client rejection, and `approved` clarifies default behavior and when it is required. This exceeds the baseline given full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool's action as carrying out a plan produced by `plan_mail_setup`, which distinguishes it from the planning sibling tool. It names the specific resource (a mail setup plan) and the operation (apply/execute).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit guidance to show the plan to the operator before calling, and states when `approved` is required (when the plan would replace or combine an existing record). It could more explicitly contrast with `plan_mail_setup`, but the instruction to call only after showing the plan is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description explicitly states the read-only nature: 'Read-only by construction' and explains the filtering mechanism. It also discloses that only clients with a session are included, providing transparent behavioral expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear opening, a contrast to a sibling, and a behavioral note. However, the final sentence 'Naming one client is what unlocks writes (D5)' is cryptic and somewhat tangential, slightly reducing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema required), the description covers purpose, usage, behavior, and parameter semantics thoroughly. It provides enough context for an agent to decide when and how to invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'question' has a clear description with an example: 'A question in plain English about every client at once, for example which of my clients has no DMARC policy.' This fully explains the parameter's meaning and usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb and resource: 'Ask one question about every client at once, using their own accounts.' It also differentiates itself from the sibling tool find_across_clients, making its role distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly contrasts with find_across_clients, explaining that this tool reaches provider accounts via MCP servers to answer questions not covered by the check catalogue. It also notes the condition 'Only clients with a session are included', giving concrete usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that the tool is read-only, returns nothing when everything passes, returns a list of findings when issues exist, and includes the client name with each finding. This is useful behavioral transparency, though it does not detail the output format or the exact nature of the checks.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description opens with a clear one-line purpose, but the subsequent paragraphs contain rhetorical flourishes ('The thing an operator actually wants running', 'Nobody runs thirteen checks by hand') that add tone rather than essential information. It could be more concise without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description conveys the overall behavior and result style but omits specifics such as what constitutes a failure, which mail configuration aspects are audited, and the exact output structure. Since there is no output schema, these details are left to inference, leaving moderate gaps for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, dkim_selector, is fully described in the input schema, so the tool description adds no additional meaning. The schema description is sufficient: it explains the default and when to change it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks every client at once and reports only issues, and it distinguishes itself from find_across_clients by being an audit rather than a search. However, the exact types of checks performed (e.g., DKIM, SPF, DMARC) are not explicitly enumerated, leaving some ambiguity about the audit scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this should be used when an operator wants a proactive, aggregate health check across all clients and contrasts it with manually checking each client. It does not explicitly compare against siblings like ask_across_clients or work_on_client, so the when-to-use guidance is somewhat implicit rather than fully explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of disclosing behavior. It thoroughly explains that absolute URLs are refused to avoid sending credentials to another host, that the provider's host is asserted before any request, that every call is logged as a mutation regardless of HTTP method, and that response bodies are deliberately not logged.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is informative but somewhat verbose and stylistic, with repeated emphasis on security and credential protection. It could be tightened without losing meaning, especially since some points appear in both the description and the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema, the description sufficiently explains the tool's security model, supported providers, mutation logging, and response-body handling. It does not explicitly describe return formats or error behavior, but for a raw HTTP-call tool the provided context is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides descriptions for all parameters, and the tool description reinforces key constraints such as path being relative, provider being limited to three known services, and method always being treated as a mutation. It adds meaningful context about credential safety and logging, though it does not introduce major new parameter-level details beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool makes one HTTP call to a provider's own API using one client's credential. It also distinguishes its role as a fallback when a provider's MCP server does not publish the needed operation, giving concrete examples like Vercel environment-variable writes and domain attachment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use guidance: when a provider's MCP server lacks a needed capability. It also warns that the tool is not a universal escape hatch and that every call is recorded as a mutation, which helps set usage expectations. It does not name alternative sibling tools, but the provided scenario is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the burden. It discloses that arguments are forwarded untouched, only the named client's credentials are resolved, exactly one account is touched, and the call is recorded in the run log. The phrase 'anything that server accepts is reachable' hints at potentially arbitrary side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than needed and contains distracting, unclear passages like 'Munim's part is the credential' and 'This works with munim config ai off.' The core purpose and guidance could be conveyed in two or three clear sentences without the repetitive jargon.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema and the arbitrary nature of provider tools, the description provides enough workflow context: it names prerequisites, explains the single-account scope, mentions run-log recording, and directs the agent to launch_status for follow-up. It does not describe return values or error handling, but launch_status fills that gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and each parameter already has a meaningful description. The tool description adds extra context beyond the schema, such as sourcing tool/arguments from list_provider_tools, the forwarding behavior, and the reminder to read inputSchema first.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence clearly states the action: 'Call one of a provider's own tools with one client's credentials.' It also distinguishes itself as 'the write half of the passthrough' versus the read-oriented list_provider_tools sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides concrete guidance: obtain tool and arguments from list_provider_tools, read the tool's inputSchema before guessing, and check launch_status afterward. It does not explicitly contrast with call_provider_api, but the 'provider's own tools' phrasing implies the distinction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description discloses key behaviors: it registers new domains on first mention (a side effect), performs live DNS lookups, may read additional records, and writes explanations. This gives a good sense of the tool's side effects and internal logic.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is moderately concise but contains poetic flourishes like 'Open the control room to watch, or read the report afterwards.' These add little practical value and could distract. The structure is clear but could be more direct.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains the check and the side effect of registration, but does not specify the exact return value or output format. Since there is no output schema, the ambiguity about what the caller receives (e.g., a boolean, a report) leaves a gap. Also lacks guidance on when to use over siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds minor context about 'target' (a client, a known domain, or a new domain) and clarifies that dkim_selector should only be changed if not using Resend. This adds value but does not significantly exceed schema information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool 'checks' a client or domain and clarifies that it performs DNS-based pass/fail checks. The verb 'check' and resource are clear, though the poetic phrasing partially obscures the exact nature. It is distinct from sibling tools like listing or auditing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool instead of alternatives like 'client_status' or 'audit_all_clients'. It implies it is for quick DNS checks with no setup, but lacks direct comparison or usage conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must carry the burden of disclosing side effects and safety. It states 'Never returns a credential' and hints at live vs. stored data, but the phrase 'A write resolves this one client's credentials' is ambiguous and potentially implies a write action without clear explanation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively short but includes confusing phrasing such as 'for the same reason as list_clients' and 'A write resolves this one client's credentials and no other.' These sentences are cryptic and could be simplified for better readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema, and the description does not fully explain what the return value looks like beyond mentioning 'connected' and 'stored.' It does not describe behavior when 'check' is false or how errors are handled, leaving significant gaps for an agent trying to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides detailed descriptions for both 'check' and 'client' parameters (100% coverage), so the main description adds little extra value. The parameter descriptions in the schema are clear and self-explanatory, meeting the baseline for well-documented parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'What is known about one client,' which indicates a single-client status retrieval, but it does not use a direct verb like 'get' or 'retrieve.' It mentions 'connected' and 'stored' but leaves the exact output structure vague, making the purpose only moderately clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description references 'list_clients' for comparison but does not clearly explain when to use this tool instead of others like 'check' or 'work_on_client.' It lacks explicit guidance on when a single-client status check is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses important behavior: the credential is stored and never returned by any tool, and the operation is a write scoped to one client. It does not explicitly mention failure modes or whether an existing credential is overwritten, but it covers the main side effect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and information-dense, with no redundant wording. It front-loads the purpose and adds only necessary guidance about OAuth and credential handling.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple mutation with no output schema, the description covers purpose, parameter semantics, and privacy behavior. It does not specify the return value or error conditions, but that is not a significant gap given the tool's simplicity and the provided schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All three parameters are described with concrete meanings: client identifies the registered client, provider specifies the service (with examples), and credential is the API key/token that is stored and never returned. Schema coverage is complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly names the action (connect), the target (one provider for one client), and the method (paste a credential). It also distinguishes itself from OAuth-based setup by referencing `munim connect` for providers that support OAuth.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use this tool: for providers that do not offer OAuth, such as Resend, and directs users to prefer `munim connect` when OAuth is available. This gives clear selection guidance relative to the main alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full weight. It explicitly states 'Read-only by design' and 'it can never mutate,' which is a key behavioral trait. It also lists specific valid values for the 'need' parameter, adding transparency beyond the schema. However, it does not disclose any error behavior or output structure, though the output schema exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loads the purpose, and includes the key read-only disclosure. Every sentence earns its place with no fluff or repetition. It is efficiently structured for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with an output schema, the description covers the essential aspects: purpose, read-only nature, and parameter values. It does not elaborate on return format or error conditions, but the output schema fills that gap. A 5 would require explicit mention of edge cases or output shape, which is not necessary here.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% coverage, so the baseline is 3. The description adds concrete values for 'need' ('email_unprotected', 'no_dmarc', 'domain_unresolved'), which the schema does not enumerate. However, these values appear to be a subset of a larger catalogue ('one of the catalogue check names'), and the description's phrasing 'one of:' could be misread as exhaustive, potentially misleading an agent about the full range of valid inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Answer one question across every client at once.' It specifies the resource (every client) and the action (answer a question), and it distinguishes itself by noting it is 'the one place that spans containers,' implying uniqueness among siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides clear context: use this tool when you need to query across all clients, as opposed to per-client tools. It does not explicitly name alternative tools or give exclusions, but the phrase 'the one place that spans containers' signals the intended use case. A more explicit mention of when not to use it would push to 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Even with no annotations, the description fully discloses important safety behavior: thirteen deterministic checks run first, the model only chooses which repair to apply, replacing an existing record stops for human approval, and creating an absent record does not stop. It also states that checks still run and findings still stand when agents are off.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the main purpose, but the later wording is verbose and somewhat cryptic, with phrases like 'out of a set of tools that cannot do anything else' and 'exactly as `check` degrades'. The content is meaningful but could be expressed more directly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's behavior, safety model, approval flow, and agent-off behavior, which is sufficient for an agent to understand when and how to call it. It does not describe the output, but no output schema is present and the behavior is otherwise well specified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Both parameters are fully described in the schema. The description adds useful context beyond the schema: `target` can be a client name or bare domain, and `dkim_selector` should only be changed if the client does not send through Resend.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks a client's domain and repairs what can be repaired safely. It also differentiates itself from `check` by saying check explains the problem while this tool acts on it, and from `apply_mail_setup` by noting that replacement actions require approval through that tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates this tool is used after `check` has identified issues, since it says check explains what is wrong and this acts on it. It also explains when to involve a human and when to use `apply_mail_setup` with `approved=true`, and it describes behavior when agents are off.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations present, the description carries the burden of disclosing behavior. It transparently states that the tool is non-blocking and reads progress from the run log, which is sufficient for a read-only status tool, though it does not cover error handling or return format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and focused, using two short paragraphs to convey purpose and rationale without unnecessary detail. Every sentence contributes to understanding the tool's function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only status tool with one optional parameter and no output schema, the description is complete. It explains the non-waiting nature, the reason for reading from the run log, and how the parameter behaves, covering all necessary context for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter run_id is fully described: it is optional, indicates the run to read, specifies provenance ('as returned by check, fix or call_provider_tool'), and defines the default behavior ('The newest run when omitted'). This adds meaningful context beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb and object: 'Read a run without waiting on it.' This distinguishes it from wait/block operations and implies a non-blocking status read, making the intent unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use the tool: when a launch polls DNS and can outlast a single tool call, progress should be read from the run log rather than held open. It provides clear context, though it does not explicitly name sibling tools to avoid.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden. It explicitly discloses that the tool asks each provider concurrently by default, can skip that with check=false, and makes the distinction between actual connectivity and stored credential state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is stylistically repetitive in places but remains focused and understandable. It delivers the key behavioral points without excessive length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the main behavior and parameter semantics, and an output schema is present, so the lack of explicit return-value details is acceptable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents check with 100% coverage, and the description adds meaningful context by explaining the trade-off between live checks and instant stored results.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's primary purpose: listing every client and which providers each can actually reach. This distinguishes it from related sibling tools like find_across_clients by emphasizing the client-level listing scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to set check=false (to report stored state instantly) and clarifies the difference between live connectivity and stored credentials, giving the agent enough guidance to choose the right behavior.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description takes on the full burden. It explains that read_only is reported but not enforced, describes what is returned, and warns about response size limits for large providers. It does not explicitly say 'no side effects', but the listing nature is strongly implied by the content.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is rambling and includes irrelevant, confusing asides such as 'This is how you do work Munim has no verb for' and 'naming a client is what unlocks writing (D5)'. Useful information is buried under opaque prose, making the description much longer than necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the essential context: how to use names_only, matching, the relationship to call_provider_tool, and the read_only semantics. It lacks a concrete example of the output shape, but since there is no output schema and the return content is described, it is mostly complete. The cryptic references slightly reduce completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers 100% of the parameters with descriptions, and the tool description adds meaningful extra semantics: matching searches names, descriptions, and argument schemas; names_only is for reducing payload size; client resolves a specific credential set; provider limits reachability. These additions go well beyond the baseline schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool returns the tools a client can use with a given provider, including names, descriptions, argument schemas, and read-only flags. It also distinguishes itself from call_provider_tool, which is invoked after listing. However, the meaning is obscured by odd digressions like 'Munim has no verb for' and references to 'D5', so it is not perfectly crisp.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete usage guidance: pair with call_provider_tool, use names_only first when response size is a concern, and use matching to search across schemas. It does not explicitly contrast with sibling tools like list_clients or find_across_clients, but the intended context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Even though there are no annotations, the description fully discloses the side effect: it may create a sending domain in the operator's own Resend account, while making no changes to the client's DNS. This is transparent about the one write operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is somewhat repetitive and rambling, but it is front-loaded with the main purpose and each sentence adds useful detail. The overall structure is acceptable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description adequately describes the return format as records with actions. It also covers side effects and input fallback behavior, though it does not mention error cases or permission requirements.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The parameter descriptions add useful examples and explain client/domain behavior. However, the domain description says 'Uses the client's registered domain when omitted' even though the schema marks domain as required, creating a contradictory instruction.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly explains that the tool plans email setup by reading current records and returning proposed actions (create, update, merge, unchanged). It also distinguishes itself from apply_mail_setup, making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says to pair it with apply_mail_setup, which needs the plan id, and clarifies that it changes no DNS. It could be more explicit about using it as a dry-run before applying, but the guidance is still clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description explicitly mentions that changes are written to the run log and can be monitored, which discloses side effects. It also states the tool 'can act' and is the 'write within' counterpart, making its mutating nature apparent. No annotations are present, so this disclosure is important and sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is overly metaphorical and poetic, using phrases like 'read across, write within' and 'open the control room to watch.' While not extremely long, it obscures the straightforward purpose and would benefit from a more direct, concise description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description places the tool in context relative to its sibling `ask_across_clients` and mentions the run log for monitoring. It does not explicitly relate to other siblings like `call_provider_tool`, but the purpose and scope are sufficiently clear for typical usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides clear descriptions for both parameters, including an example for `request` and a note about scope for `client`. The tool description adds a bit of extra context by saying 'naming them is what unlocks it,' which reinforces the `client` parameter's role.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool acts on a single client's accounts using their tools, and explicitly contrasts it with the read-only `ask_across_clients` sibling. While the phrase 'Do something' is vague, the name and context make its role clear as the write/action counterpart for one client.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly differentiates this tool from `ask_across_clients` by stating that one is read-only across clients and the other can act on a single client. It also implies the client must be named, and that the agent has sessions only for that client, guiding when to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.