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

There are no annotations provided, so the description carries the burden. It clearly states behavior: it registers a client, holds no credentials, returns the client's id, name, and domain. It also mentions that a domain can be added later. However, it doesn't disclose potential side effects like whether it overwrites an existing client with the same name, or any idempotency behavior. The description is mostly transparent, but lacks some edge-case details.

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 well-structured. It is three short paragraphs: the first states the core function, the second describes the return value, and the third gives usage guidance. It front-loads the most critical information and every sentence serves a purpose. No fluff or redundancy.

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 that there is no output schema and no annotations, the description adequately explains the return value (client's id, name, and domain). It also provides usage context. However, it could be improved by mentioning what happens if a client with the same name already exists (e.g., error or update), which would help the agent handle edge cases. Still, for a simple registration tool, it's mostly 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?

Schema coverage is 100%, so the baseline is 3. The description adds a bit of context: it states that the domain can be added later by naming it in a check, and that the tool holds only a name and a domain. However, it does not add much beyond what the schema already explains. The parameter descriptions in the schema are already detailed (e.g., 'Used in tool names, so two clients cannot differ only by punctuation'), so the description adds minimal extra value.

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: 'Register a client by name.' It specifies the resource (client) and the action (register/add), and explicitly notes what it does not hold ('Holds no credential, only a name and a domain'), distinguishing it from other tools that may involve credentials. This helps an agent understand exactly what this tool accomplishes.

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 provides explicit usage guidance: 'Use this to write a client down before connecting anything.' It also clarifies when it is NOT needed: 'You do not need it first: naming a domain in `check` or `fix` registers it on the spot.' It differentiates from the sibling tool `connect_provider` by stating that connecting a provider is a separate step. This gives clear context for when to use this tool versus alternatives.

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 full behavioral burden, and it does this well. It discloses return values, the needs_approval state, that changes are not made without approval, that retrying with approved=true is safe, and the side-effect distinction between creating absent records and replacing existing ones.

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 front-loaded. The opening sentence states the action immediately, and every subsequent sentence adds necessary context about return values and approval semantics without repetition or filler.

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 tool with no output schema and no annotations, the description sufficiently covers what the tool returns, what side effects it may have, and how to handle approval. An agent has enough information to decide whether to call it and to interpret the likely result.

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 description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining that approved is only needed for existing records nominally and that retrying is safe, which clarifies the parameter's behavioral meaning rather than just its type.

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 uses a specific verb and resource: 'Carry out a plan from plan_mail_setup.' It clearly identifies this as the execution counterpart to planning, which distinguishes it from sibling tools like plan_mail_setup, check, and fix.

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 guidance on when approval is needed, when it is not, and advises showing the plan before setting approved=true. It does not explicitly name alternatives or state when not to use the tool, but the context is clear enough for correct use.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It clearly states the tool is read-only, 'never writes,' explains the exact return shape (one entry per failing client with client name and run_id), and defines empty results as meaning all clients are healthy.

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 core purpose, followed by return behavior and safety, then routing guidance. Every sentence adds meaningful information with no filler or redundancy.

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 tool with no annotations and no output schema, the description is remarkably complete: it explains the return format, the omission behavior, the read-only nature, and how it differs from relevant siblings. No critical information an agent needs to invoke it correctly is missing.

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 description coverage is 100% and the sole parameter dkim_selector already has a clear description and default value. The tool description adds no extra parameter-level detail, which is acceptable because the schema fully documents 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 states a specific verb and resource: 'Run the whole check catalogue against every client' while narrowing the output to 'only what needs attention.' It also explicitly differentiates itself from sibling tools by naming 'check' and 'find_across_clients' and their distinct scopes.

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 routing guidance: use 'check' for a single client with a reportかな, and 'find_across_clients' when checking one specific check across all clients. It also clarifies when this tool is appropriate by emphasizing it runs the whole catalogue against every client.

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 full burden of behavioral disclosure. It states that every call is recorded as a mutation regardless of HTTP method, that the response body is never written to the log, and that absolute URLs are refused to prevent credential leakage. These are critical behavioral traits beyond the schema and are clearly articulated.

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 tight and front-loaded: the purpose is stated in the first sentence, followed by usage guidelines and provider specifics. Every sentence adds value—no filler. The structure flows logically from what it does to when to use it to how it behaves.

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?

Despite having no output schema, the description explicitly mentions that it returns 'the status and the parsed body, plus a run_id.' It covers the essential call contract, security constraints, and usage context. For a tool with 6 parameters, the description, combined with a fully described schema, leaves nothing an agent needs to correctly 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?

Schema description coverage is 100%, so baseline is 3. The description goes beyond the schema by explaining the path constraint (must start with slash, never a full URL) and the rationale for refusing absolute URLs. It also clarifies that the method field, despite being GET by default, is recorded as a mutation for any verb. This adds meaningful semantics to the 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 clearly states the action: 'Make one HTTP call to a provider's own REST API with one client's credential.' It specifies the resource (provider REST API) and explicitly differentiates from siblings by referencing list_provider_tools and call_provider_tool. The verb and target are unambiguous, and the scope is distinct from the other provider-related tools.

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?

Explicit guidance is given: '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.' This names the alternatives and the condition for choosing this tool. It also provides concrete examples (Vercel env-var write, project-domain attach) and lists supported providers, leaving no ambiguity about when to invoke it.

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 full burden and does so thoroughly: it discloses the return shape ('provider's own result, plus a run_id'), the forwarding behavior ('Arguments are forwarded untouched'), the side effect of logging ('tool and its arguments go to the run log'), the scope boundary ('touches no other account'), and the no-model behavior. This gives an agent a complete safety and side-effect picture before calling.

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 six sentences, each earning its place: purpose, return value, sourcing guidance, scope, logging, and compatibility. It front-loads the core action in the first sentence and avoids any redundant re-statement of schema fields.

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 4-parameter tool with no output schema and no annotations, the description is remarkably complete. It explains the return value, the run log side effect, how to source parameters, and the environment in which the tool works, leaving little an agent needs to infer. The only thing absent is explicit sibling routing, but that is already covered under usage guidelines.

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 already describes all four parameters with 100% coverage, so the baseline is 3. The description adds meaningful guidance beyond the schema by directing the agent to source `tool` and `arguments` from `list_provider_tools` and by clarifying that `client` scopes the call to exactly that one account. This extra semantic guidance earns a 4.

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 opens with a specific verb and resource: 'Call one of a provider's own tools with one client's credentials.' This clearly distinguishes it from sibling tools like call_provider_api (which would target the provider's API) and work_on_client (which is broader), by narrowing to a single client's credentials and a provider-defined tool. The first sentence alone makes the tool's job unmistakable.

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 provides clear context for when to invoke: it specifies acting on one client, using a provider's own tool, and notes 'No model is involved, so this works with agents off.' It also tells the agent to obtain `tool` and `arguments` from `list_provider_tools` rather than guessing, which is actionable guidance. It does not, however, explicitly name alternatives or state when not to use this tool, so it stops short of a 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?

With no annotations, the description carries the full burden and does so thoroughly. It discloses that DNS decides pass/fail, never a model; that with agents on a model only adds an explanation; that watch/report URLs appear only while running; that unknown domains get registered as clients; and what the return values are. This is rich behavioral context beyond the schema.

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?

Every sentence carries distinct information: main operation, return values, runtime-only URLs, deterministic behavior, agent-mode behavior, target flexibility, and sibling alternatives. It is front-loaded and dense with no filler.

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 no annotations, yet the description explains what is returned, the side effect of registering unknown domains, how pass/fail is determined, what agent mode changes, and when to use related tools. Nothing essential for selecting and invoking the tool is missing.

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 description coverage is 100%, so the schema already documents target and dkim_selector well. The description reinforces target semantics by explaining the three possible target forms and the no-setup implication, but it does not add meaning substantially beyond the schema, which is the baseline case for full 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 opens with a specific verb–resource pairing: 'Run the deterministic check catalogue against one client or one domain.' It clearly states what the tool does and distinguishes it from siblings by naming audit_all_clients and fix as alternatives, so an agent can tell it apart without reading their schemas.

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 explicitly states when to use this tool versus alternatives: '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.' It also clarifies that target can be a client name, an existing domain, or a previously unmentioned domain, and that there is no setup step.

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 behavioral burden. It discloses that the tool 'ask[s] each provider live', revealing that it makes network calls and can report 'connected', 'needs_login', and 'unreachable'. It also states a strong privacy guarantee: 'Never includes a credential value.' This goes beyond a typical read operation and gives the agent necessary 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 organized into a clear one-line summary, a return-field breakdown, and usage guidance. Every sentence adds value, though the second and third paragraphs are dense. It could be tightened slightly, but it remains well-structured and front-loaded with the core purpose.

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?

There is no output schema, so the description must fully explain return values. It does: it lists the client's name and domain, 'stored', 'api_key', 'mcp_session', and the three live statuses. It also covers the meaning of the two stores and the safety behavior. The description is complete enough for an agent to know exactly what to expect and how to interpret the result.

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 does not add explicit parameter explanations beyond the schema, but it does provide context that clarifies the effect of the 'check' parameter (stored vs. live status) and the meaning of 'client' (one registered name). That context is helpful but not essential given the schema already describes both parameters well.

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 opens with a precise summary: 'What is known about one client.' It identifies the exact resource (one client) and the specific verb (status/returns what is known). It also explicitly differentiates from sibling list_clients: 'Use this for one client and list_clients for all of them.' This makes the tool's scope unambiguous relative to its 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?

The description gives explicit when-to-use guidance: 'Use this for one client and list_clients for all of them.' It also explains the non-interchangeability of the two credential stores, which is critical for interpreting results and deciding whether to call this tool versus provider-specific tools. This is clear, direct, and includes an 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 the full burden and does so well: it states the credential is stored, is never returned by any tool, and that only the connected provider is returned. It also explains the REST-vs-browser-session distinction, making the side effects and security posture clear.

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 front-loaded: the core action appears first, followed by return behavior, then usage conditions. Every sentence contributes either selection guidance, safety information, or behavioral context, with no filler.

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 there is no output schema, the description usefully states what the tool returns and what it never returns. It also covers when to use it and how it relates to browser login and mail tools. Minor gaps like overwrite behavior or failure modes are not critical for an agent deciding whether to invoke this tool.

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 description coverage is 100%, so the baseline is 3. The description reinforces the parameters by calling the credential a 'pasted API key' and emphasizing 'one client and one provider,' but it does not add substantial semantic detail beyond the schema's already thorough parameter descriptions.

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 opens with a specific verb and resource: 'Store a pasted API key for one client and one provider.' It clearly distinguishes the tool's purpose from the sibling tools, which are about calling provider APIs, planning setups, or auditing clients, by framing this as a credential-storage operation.

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 explicit when-to-use guidance: 'Use this only for providers with no browser login, or when a REST API key is needed alongside a session.' It also names the alternative path, `munim connect` at the terminal, for browser login, which helps an agent choose correctly.

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 provided, so the description carries the full burden. It states 'Read-only, and it never writes,' which is a key safety disclosure, and explains the return format. This covers the most important behavioral aspects, though it doesn't mention edge cases like invalid check names or client count limits, which are minor for a read-only tool.

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 concise paragraphs. The first sentence front-loads the purpose and output, the second adds the read-only nature, and the third covers parameter guidance and alternatives. Every sentence earns its place with zero fluff.

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, read-only tool with an output schema, the description covers purpose, usage, alternatives, and safety. It is fully sufficient for an agent to call it correctly, and the presence of an output schema means return value details are not needed in the description.

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 fully describes the single parameter 'need' with examples, and the description reinforces this with the same examples. Since schema coverage is 100%, the description adds marginal value beyond the schema, meeting the baseline of 3 without elevating 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's action ('Run one named check across every client at once') and its output (one row per client with result and evidence). It explicitly differentiates from siblings by naming audit_all_clients and ask_across_clients, so an agent can pick it without opening schemas.

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 on when to use this tool versus alternatives: use audit_all_clients for the whole catalogue and ask_across_clients for open-ended questions. It also implies use when you have a specific check name, with no ambiguity.

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 full burden, and it delivers: it explains that the same deterministic checks run, that models only choose a repair, that replacing published records waits for human approval, that creating absent records does not stop, and that report_file is always written. This is rich behavioral disclosure beyond what the schema provides.

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 long but structured and front-loaded with the core purpose. Every paragraph adds a distinct behavioral or operational point: repair scope, approval gates, reporting artifacts, and degraded-agent mode. Some phrases are cryptic ('munim approve answers without it'), which prevents a 5.

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 tool with no annotations and no output schema, this covers the important operational dimensions: what is repaired, what is off-limits, how approvals work, reporting artifacts, and behavior with agents off. A clearer statement of the returned status or resolution result would make it fully 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?

Schema coverage is 100%, and the description does not add much parameter-level detail beyond the schema. It indirectly relates to 'target' via the client/domain resolution, but it does not explain dkim_selector or otherwise deepen the parameter picture. Baseline 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 first sentence names an explicit action ('repair what can be repaired safely') and a clear resource ('a client's domain'). It also distinguishes itself from the sibling 'check' tool by saying 'check explains what is wrong. This acts on it.'

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 usable context: use this when you want to act on check results, and use 'check' for diagnosis. It also references 'apply_mail_setup' for approvals. It stops short of an explicit when-to-use vs. when-not-to-use list, but the alternatives are named and meaningful.

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 full burden. It clearly discloses that the tool is non-blocking, reads from a run log, returns ordered events, and defaults to the newest run. It does not mention error behavior or response format details, but the core behavioral traits are well covered.

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 front-loaded: main action, then return contents, then default behavior, then rationale. Every sentence adds value and there is no filler or repetition of the tool name.

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 tool with one optional parameter, the description is nearly complete. It explains what the run contains, the default behavior, and why it reads from the log. It could go slightly deeper on the exact event shape, but the absence of an output schema is mitigated by the high-level return description.

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 description coverage is 100% and the single run_id parameter already explains that it comes from check, fix, or call_provider_tool, and that omission means newest run. The tool description restates the default but adds no new parameter-level meaning.

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 a clear verb and resource: 'Read a run back without waiting on it', and explains the tool returns ordered events. It is distinct from siblings like check or fix because it is explicitly a non-blocking read of a previous run, though it does not name a specific sibling to differentiate from.

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 strong context: reads progress from the run log rather than holding a call open, and defaults to the newest run. It implies this should be used after check or fix when a long-running operation has been kicked off, but it does not explicitly name alternatives or exclusion criteria.

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 explains that the tool performs live provider probes, can be short-circuited with check=false, and returns a mix of stored and live status fields. This is substantive behavioral context beyond the tool name.

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?

Every sentence earns its place: the core purpose, the return shape, the optional parameter behavior, and the sibling alternative. The description is well-structured, front-loaded, and free of filler.

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 output schema exists and there is only one optional parameter, the description fully covers what the agent needs: scope, return semantics, live vs. stored modes, and the single-client alternative. Nothing important is missing.

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 already fully documents the check parameter with 100% coverage, so the baseline is 3. The description restates the same behavior without adding new semantic meaning beyond what the schema already provides.

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 opens with a specific verb and resource: 'List every client and what each one can actually reach.' It immediately differentiates itself from the sibling client_status, so an agent can tell exactly what this tool does without opening the schema.

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 explicitly directs the agent to use client_status for a single client and explains the behavioral choice between live checks and check=false. It does not discuss every sibling alternative, but it gives clear routing for the most relevant one.

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 full burden of behavioral disclosure. It reveals the return fields, explains that `read_only` is reported not enforced, and warns about response size limits, recommending `names_only` as a workaround. It does not cover authentication or error conditions, but for a listing tool that is acceptable.

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 organized into clear sections: purpose, return details, and usage guidance. Every sentence contributes useful information—no filler. It is slightly long but efficiently structured with line breaks for 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?

Given 4 parameters and no output schema, the description explains what is returned, how to filter, and how to avoid response limits. It covers the key behaviors an agent needs to call correctly, though it does not detail error handling or authentication. Overall, it is sufficiently complete for the tool's complexity.

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?

While the schema already describes each parameter, the description adds valuable context: `names_only` is optimized to reduce payload (2KB vs 122KB for Resend) and `matching` searches across name, description, and schema to answer questions like 'which tools take a teamId'. This enriches the parameter meaning 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 the tool lists the tools a client's account with a provider publishes. It explicitly distinguishes from sibling `call_provider_tool` by saying to read this before invoking that one, and contrasts with other siblings like `call_provider_api` by focusing on tool listing.

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 provides explicit guidance: read this before `call_provider_tool`, use `names_only` for lightweight calls, and use `matching` for filtering. It clearly identifies when to use this tool versus alternatives and even gives size-based rationale.

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 full burden and it does so thoroughly: it discloses a non-obvious side effect ('planning creates the sending domain in your own Resend account'), reassures that client DNS is untouched, and describes the return payload (plan_id, records with current/proposed values, approval count). No behavior is hidden or misrepresented.

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 five sentences, each adding essential information: purpose, output, safety, side-effect disclosure, and routing to alternatives. It is front-loaded with the main purpose and uses minimal words to convey a complex behavior.

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 planning tool with no output schema, the description fully covers what the agent needs: the output structure, the side effect, the safe nature, and how to proceed afterward. There are no critical gaps 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 input schema provides 100% coverage with detailed descriptions for both parameters (client and domain), so the baseline is 3. The tool description adds no extra parameter-specific meaning beyond the schema, which is acceptable given the schema's quality.

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 opens with a specific verb ('work out') and a clear resource ('what setting up email for this client's domain would change'), and immediately distinguishes itself from siblings by naming apply_mail_setup and fix. It leaves no ambiguity about the tool's function.

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 explicitly tells the agent when to use this tool versus alternatives: '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.' It also notes the safe nature ('Touches no client DNS') which guides risk-aware usage.

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 covers what is returned, that changes are logged incrementally and readable via launch_status, and the limitation that the agent only has this client's sessions. It does not explicitly warn about irreversibility, but the write/change language is clear.

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?

Three short paragraphs front-load the purpose, then add return/log behavior and routing guidance. Every sentence carries distinct information and there is no filler.

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 what the tool returns, how changes are recorded, and which sibling to use instead. It lacks only an explicit statement of prerequisites or safety caveats for arbitrary write requests, which is a minor gap given the schema and routing details.

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 schema already explains both parameters, including a request example and scoping to one client's credentials. The description reinforces the one-client scope but adds little new parameter-level meaning.

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 opens with a specific verb-resource pair: 'Carry out a request inside one named client's provider accounts.' It also differentiates itself from siblings by naming ask_across_clients and fix and by stating the one-client 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?

It explicitly says when not to use it: 'a request needing a second account has nothing to reach with,' and points to ask_across_clients for cross-client reads and fix for DNS/mail repairs. This gives an agent clear routing criteria.

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