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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description still adds value by disclosing the return shape ('short confirmation'), the absence of side effects, and the architectural reason (Bearer-token auth, no server-side session), which goes beyond the structured fields.

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 labeled lines, front-loaded with Purpose, each sentence carrying new information. There is no filler and nothing redundant with the annotations.

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 zero-parameter, no-op tool with no output schema, the description covers what it is, what it returns, and what it does not do. An agent has everything needed to decide not to depend on 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?

There are zero parameters, so the baseline is 4 and the description has nothing it needs to explain about inputs. No parameter information is missing.

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 exactly what this tool is: a legacy no-op whose name implies logout but which performs no server-side action because engine mode uses Bearer tokens. That is a specific, unambiguous characterization that an agent could not infer from the name 'logout' alone.

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 makes clear this tool exists only for backward compatibility and that there is no session to end, which implies callers do not need it. It stops short of an explicit 'do not call' or a stated safe-call guarantee, but the context for using or skipping it 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?

Annotations already declare idempotent=true, destructive=false, readOnly=false. The description adds genuinely non-redundant context: the 'Side effects: Next reads refetch from the engine' note and the scope clarification that only the MCP cache, not the engine cache, is affected — critical for avoiding a destructive-looking mistake.

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?

Four labeled single-line sections, front-loaded with purpose and scope before side effects. No filler; every line carries distinct information.

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 parameterless maintenance tool with no output schema, the description covers scope, trigger, return expectation ('Confirmation'), and side effects — everything needed to invoke it correctly. No annotations are repeated or contradicted.

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 tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter-level gaps exist.

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?

States a specific verb (clear/flush) and resource (MCP process response cache), and explicitly disambiguates from the similarly-named FortiMail Engine server cache, which no sibling covers. An agent can immediately distinguish this from engine.status.

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?

Gives an explicit trigger: 'When reads look stale after changes made elsewhere.' It does not name alternative tools or when-not to use it, but the condition is concrete enough to select the tool reliably.

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?

Annotations already declare non-read-only, non-idempotent, non-destructive, open-world behavior. The description adds meaningful side effects not covered by annotations: creating the domain and flushing the MCP cache.

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 and organized into Purpose, Inputs, Returns, and Side effects. Each line is concise and directly useful.

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?

It covers purpose, key inputs, return shape, and side effects, which is strong given the annotations and no output schema. However, the nested settings object remains loosely specified beyond the required 'ip' and a few optional fields.

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 useful semantics beyond the schema by naming optional settings fields (port, status, comment) and clarifying that settings must include 'ip' per engine 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 gives a specific verb and resource ('Create a domain') and an API endpoint, clearly distinguishing it from sibling read/update/delete domain 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?

It states the creation purpose, so usage is implied, but it does not explicitly say when to use this instead of update/delete or what prerequisites must be met.

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?

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the bar is lower. The description still adds value by disclosing a side effect not in the annotations: 'flushes MCP cache.' It doesn't cover permission requirements or undo/recovery, so it stops short of full disclosure.

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 labeled bullets (Purpose/Inputs/Side effects) with zero filler and the critical destructive warning front-loaded. Every sentence earns its place.

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 one-parameter destructive tool with no output schema and annotations covering the safety profile, the description supplies purpose, input, and a non-obvious side effect. Reversibility and permission requirements are absent but are largely implied by the destructiveHint annotation, so it is nearly 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 single parameter already carries a description ('Domain name to delete'). The description only restates the parameter name, adding no format or syntax detail beyond the schema, which is the expected baseline.

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?

States a specific verb+resource ('Delete a domain') and even names the exact endpoint (DELETE /v1/domains/{key}). The name plus purpose make it unambiguous versus siblings like domains.create, domains.update, and domains.get.

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 names the required input and flags the operation as destructive, which implies when to use it, but it offers no explicit when-to-use/when-not guidance or alternatives. The delete semantics are self-evident from the name, so the gap is modest.

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 annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered. The description's 'Side effects: None (read-only)' merely restates the annotation, and 'Returns: JSON' is too generic to add real behavioral context.

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 labeled Purpose/Inputs/Returns/Side effects format is front-loaded and compact with no wasted prose. It is efficient, though the rigid template means some labels carry little information.

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 getter with no output schema, the definition covers purpose, input, return type, and safety. Nothing essential for invoking it correctly is missing given the tool's low 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?

Schema coverage is 100% and the single parameter is documented as 'domain name (mkey)' in the schema; the description repeats the same phrase without adding format, validation, or lookup semantics. Baseline 3 applies when the schema does the work.

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?

Uses a specific verb+resource: 'Load configuration for one domain.' This distinguishes it from the create/update/delete siblings, but it does not differentiate from the closely related fortimail.domains.info.get, leaving ambiguity about which getter to choose.

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?

There is no when-to-use guidance and no mention of alternatives. With many sibling getters (domains.list, domains.info.get) available, the description offers nothing to help an agent decide when this tool is the right call.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered by structured data. The description's 'Side effects: None (read-only)' merely restates the annotation rather than adding context such as authentication needs, error behavior, or scope limits.

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 header-style layout (Purpose / Inputs / Returns / Side effects) is front-loaded and easy to scan, with no filler. It is appropriately sized for a trivial single-parameter read.

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 get with 100% schema coverage and full annotations, little is required and no output schema exists so return values need not be detailed. The main gap is the failure to disambiguate from `domains.get` and other domain siblings, which an agent would need to choose 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 description coverage is 100%, with the single `domain` parameter documented as 'Domain name'. The description only lists `domain` under Inputs and adds no format or constraint detail beyond the schema, so the baseline 3 for full schema coverage applies.

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 names a specific resource (customer/account metadata) and gives the exact endpoint (GET /v1/domain-info/{key}), so the operation is identifiable. However, there are closely related siblings, notably `fortimail.domains.get` and `fortimail.domains.info.update`, and the description does nothing to distinguish this 'domain-info' read from a plain domain GET, leaving the agent unsure which to call.

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?

There is no statement of when to use this tool versus the many alternatives (domains.get, domains.list, domains.info.update). No preconditions or exclusions are given; the agent must infer usage entirely from the name and endpoint.

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?

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the mutation/idempotency profile is covered. The description adds a non-obvious side effect beyond the annotations — 'Flushes MCP cache' — which is exactly the kind of context annotations cannot express. It stops short of covering auth requirements or replace-vs-merge semantics.

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 labeled lines (Purpose / Inputs / Side effects), each front-loaded and free of filler. Purpose and endpoint come first, then the payload shape, then the side effect — no wasted sentences.

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 mutation tool with annotations covering safety and no output schema, the description covers purpose, payload fields, and the cache-flush side effect. It omits whether the PUT replaces or merges the info object (i.e., whether omitted fields are cleared), which is the one gap an agent calling a PUT endpoint would want.

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% for the two top-level params, but the nested 'info' object is declared only as additionalProperties:{} with 'Fields to update'. The description enumerates the actual updatable fields (customer_name, customer_email, account_limit, comment), which the schema does not, so it adds real meaning beyond the structured data.

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?

States a specific verb+resource ('Update metadata') and pins it to the endpoint PUT /v1/domain-info/{key}, and 'metadata' implicitly separates it from the sibling fortimail.domains.update that changes the domain itself. Clear purpose, though the sibling differentiation is left for the agent to infer rather than stated outright.

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?

No when-to-use, when-not, or prerequisite guidance. The description never mentions fortimail.domains.update or fortimail.domains.info.get, so the agent must infer from the name alone that this targets domain metadata rather than the domain record. Usage is only implied by the purpose line.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered; the description still adds value by disclosing the markdown return format, the truncation behavior on large results, and an explicit no-side-effects statement. It does not mention pagination or auth requirements, so it is not fully rich.

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?

Five labeled, single-line sections that are front-loaded and waste no words; purpose precedes inputs and side effects in the order an agent needs them.

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 zero parameters, no output schema, and annotations already carrying the safety profile, the description supplies everything else needed: what it returns, how large results behave, and that there are no side effects.

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 tool takes zero parameters and the description confirms 'Inputs: None,' consistent with the empty schema. Baseline for a 0-param tool is a 4 since there is nothing further to disambiguate.

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?

States a specific verb (Enumerate) and resource (mail domains via the FortiMail Engine), and is clearly distinguishable from the sibling domains.get, domains.create, domains.update, and domains.delete. An agent can tell it is the unfiltered list operation 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?

The 'When to use' line gives concrete contexts (onboarding, audits, before editing a domain), which implicitly routes the agent away from domains.get when it needs the full set. It stops short of explicitly naming the alternative tools or when-not-to-use conditions, so it falls just 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?

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description goes beyond them by disclosing a real side effect ('flushes MCP cache') and clarifying partial-update semantics. It stops short of auth/permission requirements, but the cache-flush disclosure is genuine added value.

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 labeled four-line structure (Purpose/Inputs/Returns/Side effects) is front-loaded and wastes no words. It is slightly telegraphic, but every line carries information relevant to invocation.

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 mutation tool with annotations and no output schema, the description covers inputs, return shape, and side effects, which is roughly adequate. However, it omits the differentiation from the domains.info.update sibling and any permission/error context, leaving meaningful gaps.

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 both parameters are already documented. The description restates them ('domain'; 'settings' — fields to update) without adding syntax or format detail. The free-form 'settings' object (additionalProperties {}) is inherently opaque, and the description does not compensate.

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?

States a specific verb+resource ('Partial update') and pins the exact endpoint (PUT /v1/domains/{key}). It is clear what the tool does, but it does not distinguish itself from the close sibling fortimail.domains.info.update, which an agent could easily confuse with this one.

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?

No guidance on when to choose this tool over the sibling fortimail.domains.info.update, no prerequisites, and no exclusions. The only hint is 'partial update', which is not enough to route the agent among the many domain/profile update siblings.

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?

Annotations already declare readOnly/idempotent/non-destructive, so 'Side effects: None' is largely redundant. However, the note that the detailed path requires an API key with sufficient scope adds genuine auth context beyond the structured fields.

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?

Labeled sections (Purpose/When to use/Inputs/Returns/Side effects) are front-loaded and terse; no sentence is 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 zero-required-parameter health check this is nearly complete; the only soft spot is that with no output schema, 'JSON from the engine health endpoints' does not hint at what a healthy vs. unhealthy response looks like.

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 already describes the boolean, but the description adds the endpoint it selects (/health/detailed) and the scope requirement, giving meaning beyond the schema text.

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?

States a specific verb+resource (check connectivity to the FortiMail Engine) and scopes it to liveness plus optional readiness, which cleanly separates it from every CRUD sibling in the FortiMail namespace.

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?

Gives concrete triggers: after configuring env vars, or when other tools fail with network/auth errors. That is clear usage context, though it does not name an alternative tool or state when not to bother calling 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description does add one genuinely useful behavioral fact beyond annotations: response bytes are interpreted as UTF-8 text, so compression affects decodability. It says nothing about auth requirements, payload size, or failure behavior, so it stays at the annotations-plus-one-detail level.

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?

Two short sentences with no filler, so nothing needs cutting. However, the front-loaded 'Purpose:' label leads into an API route instead of the actual purpose, and the brevity is partly under-specification rather than efficiency.

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?

This is a download tool with no output schema, so the description must carry more of the return contract, yet it never says what is downloaded (log file content), in what format/size, or that `log_file` comes from `fortimail.logs.list`. For a binary/text-returning endpoint with two parameters, important invocation context 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 baseline would be 3, but the description meaningfully extends `compressed`: the schema says only 'If true, request compressed payload from engine', while the description explains the MCP-side consequence (use `compressed: false` for plain text). `log_file` gets no extra semantics beyond the schema's 'mkey from list'.

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 'Purpose' line only restates the underlying REST route (`POST /v1/logs/download`), which is a tautology against the title 'Download Log File' rather than an explanation of what the tool retrieves. It gives no signal that distinguishes it from near-identical siblings such as `fortimail.reports.download` or `fortimail.queue.download`.

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?

There is no when-to-use guidance and no mention of the sibling download tools (reports.download, queue.download) that an agent must choose between. The only usage-flavored hint is the `compressed: false` recommendation, which is parameter-level rather than task-routing.

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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive behavior, so the description is not required to carry the safety profile. It nonetheless adds nothing beyond a raw query string — no note on return volume, paging behavior, or the log-type enum's meaning, which would have been genuinely useful for a log-listing 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?

It is a single short line with no waste, but it is under-specified rather than concise: the one sentence present conveys an endpoint path instead of usable purpose or behavior information.

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 paginated, enum-driven list tool this is thin: no explanation of the log-type taxonomy, ordering, or paging defaults, even though there is no output schema to fall back on. The annotations cover safety but not the operational context an agent needs to call it well.

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% with an enum on `log_type`, so the schema carries the parameter semantics and a baseline of 3 applies. The description's `type=&limit=&offset=` string adds no meaning and even uses names (`limit`, `offset`) that do not match the schema's `page_size` and `start_index`.

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 only restates an HTTP route (`GET /v1/logs`) rather than stating in prose what the tool does; the reader must infer 'list log files' from the title. It gives no differentiation from the sibling `fortimail.logs.download` or `fortimail.reports.list`, so it is close to tautological.

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?

There is no guidance on when to use this tool versus list-based siblings such as `fortimail.logs.download`, `fortimail.reports.list`, or `fortimail.queue.list`. Usage can only be inferred from the endpoint name.

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?

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, and idempotentHint=false, so the agent knows this is a non-destructive write operation with open-world behavior. The description adds no behavioral context beyond annotations; with annotations present, the bar is lower, but no extra value is provided, so a 3 is appropriate.

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 a single sentence with minimal waste, but the structure is minimal and provides little information. It is concise but not optimally front-loaded or informative.

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 is a non-destructive write operation with two parameters and full schema coverage, the description is adequate but not rich. It lacks details about the body structure or return values, though no output schema exists. The reference to the engine OpenAPI is a weak substitute for in-context guidance.

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 the parameters. The description only says to see the engine OpenAPI for required body fields, which adds no meaning beyond the schema. Baseline 3 is correct when schema does the heavy lifting.

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+resource, 'Create GeoIP Profile', which distinguishes it from sibling operations like get, update, delete, and list. However, there is no additional detail about what a GeoIP profile is or what it contains, leaving the purpose only minimally 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?

There is no guidance on when to use this tool versus alternatives, prerequisites, or context. The only hint is a parenthetical reference to the engine OpenAPI for required body fields, which is insufficient for 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?

Annotations already carry destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is known. The description adds nothing beyond this – it does not disclose what gets removed, whether dependent references break, or what the response looks like. No contradiction exists, but no value is added.

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 text is short and front-loaded, but it is under-specified rather than concise – a bolded 'Purpose:' label wrapping a verbatim echo of the title earns no informational value.

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 destructive delete operation with no output schema, the description should clarify irreversibility or prerequisites. Annotations partially cover safety, but the description leaves the agent without enough context to invoke confidently in a multi-sibling environment.

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?

There is a single parameter ('key') with full schema description coverage ('Profile mkey'). Per the baseline rule, complete schema coverage yields a 3, and the description adds no additional meaning about the key format or source.

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 merely restates the tool's title ('Delete GeoIP Profile') as its 'Purpose', adding no verb scope, target detail, or distinction from the many sibling delete tools (domains.delete, users.delete, queue.delete, etc.). An agent learns nothing beyond what the name already conveys.

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?

There is no guidance on when to use this tool versus alternatives, nor any precondition (e.g., that the profile must exist or be unreferenced). Deletion is irreversible per annotations, yet no caution or context is offered.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds nothing beyond that — no note on missing-key behavior, external GeoIP lookups implied by openWorldHint, or response shape.

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?

One short sentence, front-loaded and free of filler. The '**Purpose:**' marker is mild label noise but does not obscure the content.

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 tool with full annotation coverage and no output schema, the definition is minimally adequate. It omits any indication of what is returned or how errors (e.g., unknown mkey) surface, leaving the agent to infer the contract.

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 there is a single parameter, so the baseline is 3. The description does not enrich the meaning of 'key'/'Profile mkey' beyond what the schema already states.

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?

States a specific verb ('Get') and resource ('GeoIP Profile') and the scope of 'one', which distinguishes it from the sibling geoip.list. It stops short of naming those siblings or clarifying what a profile contains, but an agent can identify the 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?

No when-to-use guidance, no prerequisites, and no hint that the required 'key' must be obtained from fortimail.profiles.geoip.list. Usage is left entirely to inference from the name.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so 'Side effects: None (read-only).' is redundant restatement. No additional behavior (output shape, pagination, scope) is disclosed beyond the annotations.

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?

Two short labeled lines, front-loaded with purpose. No filler. Could be slightly more informative but is efficient.

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 no-param list tool with annotations covering safety, the description is minimally adequate. However, it doesn't distinguish from sibling list tools or confirm no filters are accepted, leaving a small 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?

Zero parameters, so baseline 4 applies. Schema requires nothing; description need not add parameter guidance.

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?

States a specific verb (List) and resource (GeoIP Profiles), clearly one of the geoip CRUD siblings (get/create/update/delete). The phrasing 'List GeoIP Profile profiles' is slightly awkward but the intent is 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?

No indication of when to use this versus fortimail.profiles.geoip.get or whether pagination/filtering applies. It provides no context or alternatives despite many siblings.

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?

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=true), so the mutation is idempotent and non-destructive. The description adds nothing beyond that — no mention of required permissions, partial-update semantics, or whether unmentioned settings are preserved.

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?

It is a single bolded sentence with zero padding, and the purpose label is front-loaded. However, brevity here reflects under-specification rather than disciplined conciseness — the sentence earns its place only as a title echo.

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 mutation tool with an open-ended nested 'settings' object (additionalProperties: {}), an agent has no idea which fields are valid or how partial updates behave. With no output schema and no guidance in the description, the definition is too thin 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?

Schema description coverage is 100%, with 'key' (Profile mkey) and 'settings' (Fields to update) documented directly in the schema, so the baseline of 3 applies. The description contributes no additional meaning about the mkey format or which fields the open-ended settings object accepts.

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 reads 'Update GeoIP Profile', which is a verbatim restatement of the tool name and title. It identifies the verb and resource but adds no scope, distinction from siblings like fortimail.profiles.geoip.create or .get, or detail about what is actually being updated.

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?

There is no when-to-use guidance, no prerequisites (e.g. the profile must already exist), and no routing advice relative to the sibling create/get/delete operations. The agent must infer everything from the name alone.

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?

Annotations already declare the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false). The description adds no behavioral context such as what happens on duplicate keys, permission requirements, or side effects of creating a profile.

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 brief and front-loaded, but its purpose sentence simply repeats the title and its second sentence offloads critical request-body detail to an external source. It avoids bloat, yet neither sentence adds much value beyond what is already provided.

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 create tool with a nested settings object and no output schema, the definition is not self-contained. It explicitly tells the agent to see the engine OpenAPI for required body fields, so the definition alone is insufficient to construct a valid request.

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 the three top-level parameters. The description adds no meaning beyond the schema and defers body-field details to an external document. Baseline 3 is appropriate when the schema does the heavy lifting.

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's only purpose statement is an exact restatement of the tool title ('Create IMAP Auth Profile'), adding no detail about what an IMAP Auth Profile is or how this differs from sibling create operations like smtp_auth.create. The pointer to the engine OpenAPI does not clarify purpose.

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?

There is no guidance on when to use this tool versus imap_auth.list, imap_auth.get, imap_auth.update, or other profile creates. The only usage advice is to consult an external OpenAPI document, which is not a substitute for in-definition 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?

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds no additional context such as what gets destroyed, whether the action is reversible, permission requirements, or side effects. It provides no value beyond the structured annotations.

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 extremely short (one phrase) and front-loads the purpose. However, it is arguably under-specified for a destructive operation, and the 'Purpose:' label is redundant formatting rather than earning its place.

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 destructive delete tool with no output schema and 100% schema coverage, the description should at least confirm scope (e.g., that deletion is permanent) or mention dependencies. It provides nothing beyond the title, leaving behavioral gaps unaddressed.

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 both parameters (key, domain) are fully documented in the schema. The description adds no parameter meaning, so the baseline of 3 applies.

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 ('Delete IMAP Auth Profile'), which distinguishes it from siblings like imap_auth.get, imap_auth.list, imap_auth.create, and imap_auth.update. It lacks explicit differentiators from other delete tools (e.g., notification.delete, smtp_auth.delete), but the resource scope is 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?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no warnings about irreversibility. The description simply restates the purpose without context.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context at all (e.g., what happens if the profile key doesn't exist, scoping by domain), so it contributes nothing beyond the structured metadata.

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?

It is a single front-loaded sentence with zero waste, which is appropriate for a simple getter. It is arguably under-specified rather than bloated, but nothing is redundant.

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 should say something about what is retrieved or the need for the domain/profile key, and it does not. For a getter with no return-value documentation, this leaves the agent guessing at the response shape.

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 both parameters (key, domain) are documented in the schema, so the baseline is 3. The description adds no extra meaning about the required domain/key pairing or their formats.

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 ('Get') and resource ('IMAP Auth Profile'), which clearly separates it from the sibling imap_auth.list/create/update/delete variants. It is clear but adds nothing beyond the title and tool name to differentiate further contexts.

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?

There is no guidance on when to use this tool versus alternatives such as imap_auth.list, nor prerequisites like needing both a domain and a profile key. The agent must infer usage entirely from the name.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the 'None (read-only)' line merely repeats structured data rather than adding context. Nothing is said about scoping to a domain, pagination, or result ordering.

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 short, front-loaded with purpose, and wastes no words. The only blemish is the redundant 'IMAP Auth Profile profiles' phrasing and a second line that duplicates the annotations.

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 one-parameter list tool whose annotations cover the safety profile, this is minimally adequate. With no output schema, a hint about what the listing returns or whether results are domain-scoped would have closed the remaining 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 description coverage is 100% for the single required 'domain' parameter, so the schema already carries the semantics. The description adds no format, matching, or scoping detail beyond the schema, which is the expected baseline.

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+resource combination ('List IMAP Auth Profile profiles'), so the agent knows exactly what operation is performed. However, it offers no differentiation from close siblings such as fortimail.profiles.imap_auth.get or fortimail.profiles.smtp_auth.list, and the phrasing 'Profile profiles' is redundant.

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?

There is no guidance on when to use this tool versus the .get, .create, .update, or .delete siblings, nor any stated prerequisites beyond the required domain. The phrase 'via the engine' is too vague to route the agent.

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?

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds nothing beyond that - it does not explain what 'settings' mutates, whether changes are reversible, or any permission requirements.

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?

It is a single short sentence, but that brevity stems from under-specification rather than disciplined conciseness. The label 'Purpose:' adds no structure or information.

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?

This is a mutation tool with no output schema and a nested, unconstrained 'settings' object, yet the description says nothing about what fields can be updated, what the domain/key scope implies, or what the result looks like. An agent cannot call it confidently.

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 documents key, domain, and settings on its own, giving a baseline of 3. The description adds no meaning beyond that; notably the opaque 'settings' object with additionalProperties:{} is left entirely unexplained.

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 reads 'Purpose: Update IMAP Auth Profile,' which merely restates the tool name and title verbatim. There is no added specificity about what an IMAP Auth profile is or how this update differs from sibling operations like create or delete.

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?

No guidance whatsoever on when to use this tool versus the many siblings (imap_auth.create, imap_auth.get, imap_auth.delete, smtp_auth.update). No prerequisites, no exclusions, no context.

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?

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=true, so the mutation/duplicate-on-retry profile is known. The description adds nothing beyond that: it does not say what a notification profile contains, what happens on conflict, or what permissions are required.

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?

It is a single short, front-loaded sentence with no wasted clauses. The tradeoff is that its brevity comes from under-specification rather than efficient communication.

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 create tool with a nested, opaque settings object and no output schema, the description should explain the body and outcome but instead punts entirely to an external OpenAPI reference. An agent cannot determine what a valid call produces or what the settings body should contain.

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 required key/domain and the opaque settings body are already documented by the schema; baseline 3 applies. The description only defers to an external OpenAPI for body fields, adding no semantics the schema does not already provide.

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+resource ('Create Notification Profile'), which lets an agent distinguish it from the geoip/imap_auth/smtp_auth profile creators. However, it merely restates the title with no added detail about what a notification profile is or how it differs from the update/delete/get siblings in the same family.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as fortimail.profiles.notification.update or the other profile-create tools. The only hint is a pointer to an external OpenAPI spec, which is documentation, not 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?

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is carried by structured data. The description adds nothing beyond that — no note on irreversibility, required permissions, or whether the profile must exist first.

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?

Very short and front-loaded, but the '**Purpose:**' label prefix is pure cruft around a sentence that only echoes the title. No wasted content beyond the label, but no value added either.

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 destructive, non-idempotent deletion with no output schema, the description says nothing about consequences, confirmation needs, or failure modes. The annotations cover the destructive flag, but the description leaves the agent without operational context for an irreversible action.

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%, with 'key' documented as 'Profile mkey' and 'domain' as 'Domain name'. The description adds no meaning beyond the schema, so baseline 3 applies.

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 merely restates the tool name and title ('Delete Notification Profile') with a 'Purpose:' label. It states a verb and resource but adds nothing an agent couldn't already infer from the identifier, and gives no differentiation from siblings like notification.get/update or geoip.delete.

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?

No when-to-use guidance, no prerequisites, and no indication of when deletion is appropriate versus using update or get. The only implied guidance is the word 'Delete' in the name itself.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds nothing beyond this – no note on return shape, error behavior for a nonexistent mkey, or scope of the lookup.

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?

A single front-loaded sentence with zero waste. Nothing to trim.

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 two-parameter read tool with full schema coverage, no output schema, and annotations covering safety, the description is minimally viable. It is complete enough to call but offers no guidance on the mkey/domain relationship or failure cases.

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%, with both 'key' (Profile mkey) and 'domain' documented in the schema. The description adds no meaning beyond that, so the baseline 3 applies.

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 gives a specific verb ('Get') and resource ('one Notification Profile'), and the singular 'one' implicitly separates it from the sibling list tool. It stops short of explicitly naming or contrasting with notification.list/create/update/delete.

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?

No when-to-use guidance, no prerequisites, and no mention of the required domain/key lookup keys or how to obtain them. The agent must infer that this retrieves an existing profile rather than listing or creating 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the description's 'read-only' note merely repeats structured data. The only novel-ish phrase, 'via the engine', is too vague to convey behavior; no mention of pagination, permissions, or scoping by domain.

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?

Two labeled bullets, front-loaded with purpose, no filler sentences. The templated '**Purpose:**'/'**Side effects:**' framing is a touch formulaic but wastes no words.

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 one-parameter, read-only list tool with no output schema, the description is minimally sufficient, but it omits anything about the return shape or result set scope. An agent could call it, but with no more understanding than the schema and annotations already provide.

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% for the single 'domain' parameter, so the schema carries the meaning and the description need not compensate. Baseline 3 applies; the description adds nothing about how domain scopes the listing.

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?

States a specific verb+resource ('List Notification Profile profiles') and the 'List' verb distinguishes it from its notification.get/create/update/delete siblings. The phrasing is slightly redundant ('Profile profiles') but the intent is 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?

No guidance on when to use this versus siblings like notification.get or the other *.list tools. Usage is only implied by the verb 'List'; there are no prerequisites, exclusions, or alternatives named.

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?

Annotations already declare the full safety profile (not read-only, not destructive, idempotent, open-world), and the description adds nothing on top of that. It does not say what happens to omitted settings fields, whether the update is partial or full replacement, or what permissions are required.

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 a single bolded label with no substance; it is short but by under-specification rather than efficiency, so the one sentence does not earn its place.

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 mutation tool with a nested free-form settings object and no output schema, the description should at minimum explain partial-update behavior and the shape of settings. With annotations covering safety and the schema covering the three params, the remaining behavioral gap is large and unaddressed.

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 key, domain, and settings are already documented in the schema; the baseline of 3 applies. The description adds no meaning beyond the schema — notably it is silent on the opaque 'settings' object, which is the only parameter carrying real ambiguity.

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 'Update Notification Profile' is a pure restatement of the title and name, adding no verb+resource specificity beyond what 'profiles.notification.update' already conveys. It does not distinguish this from the sibling update tools (geoip.update, imap_auth.update, smtp_auth.update, users.update) in any meaningful way.

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?

There is no when-to-use guidance, no mention of prerequisites such as requiring an existing profile, and no routing to alternatives like notification.create or notification.get. Usage is only implied by the verb 'Update'.

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?

Annotations already declare readOnlyHint=false, idempotentHint=false, openWorldHint=true and destructiveHint=false, so the write/mutation nature is covered structurally. The description adds essentially nothing beyond that — no mention of required permissions, effect of re-creating an existing profile, or the domain-scoped key semantics.

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?

A single front-loaded sentence with a bolded purpose label and zero filler. It is tight, though the brevity comes partly from deferring content rather than compressing it.

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?

This is a creation tool taking a nested, unrestricted request body, with no output schema and no annotations describing side effects. The description offloads the actual payload contract to an external OpenAPI document, leaving an agent unable to construct a valid call from the definition alone.

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% (key = 'Profile mkey', domain = 'Domain name'), so the schema carries the two required parameters and the baseline is 3. The description's reference to the engine OpenAPI adds no field-level detail, and the nested 'settings' body is left as an open object with no semantics anywhere.

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?

States a specific verb+resource ('Create SMTP Auth Profile'), which is unambiguous on its own. It does not distinguish itself from the sibling CRUD set (smtp_auth.list/get/update/delete), though the verb 'create' makes the intent clear enough to select 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?

No when-to-use guidance, prerequisites, or alternative routing is given. The only hint is a pointer to the engine OpenAPI for body fields, which is a documentation deferral rather than 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?

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is known without the description. The description adds no extra context such as irreversibility, required permissions, or dependent objects removed. It does not contradict the annotations, but it contributes nothing.

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?

It is short, but the single sentence is pure filler: it repeats the title without conveying information, so it fails the 'every sentence earns its place' test. Front-loaded formatting is present but the content is empty.

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 destructive mutation with no output schema, the description should at minimum describe the effect of deletion and any caveats. Given the annotations carry the safety hints, the remaining burden is small, but the description still supplies nothing beyond the title.

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% — both 'key' (Profile mkey) and 'domain' are documented in the schema itself. The description offers no additional parameter meaning, so the baseline 3 applies.

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 is a bare restatement of the title: 'Delete SMTP Auth Profile.' It names a verb and resource, but adds nothing beyond the name/title, and does not distinguish this tool from the many sibling delete tools (imap_auth.delete, notification.delete, geoip.delete). This is the textbook tautology case.

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?

There is no when-to-use guidance, no prerequisites, and no reference to alternatives. Nothing tells the agent when to pick this over fortimail.profiles.smtp_auth.get/list/update or the parallel imap_auth delete.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds no behavioral context of its own — not whether a missing profile errors, what is returned, or any auth/scope requirements.

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?

A single front-loaded sentence with no waste, but it is so terse that it omits useful context; the '**Purpose:**' label is slightly redundant formatting.

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, fully-annotated read tool with 100% schema coverage and no output schema, the description is minimally sufficient. It still leaves the return shape and error behavior unstated, so it is adequate but not 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 description coverage is 100%, with both 'key' (Profile mkey) and 'domain' documented in the schema, so the baseline is 3. The description adds no extra meaning beyond the schema, such as where mkey values come from.

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?

States a specific verb (Get) and resource (one SMTP Auth Profile), and 'one' distinguishes it from the sibling list operation. It does not explicitly name or differentiate itself from nearby siblings like smtp_auth.list or imap_auth.get, so it stops short of a 5.

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?

There is no guidance on when to use this versus smtp_auth.list or the create/update/delete siblings, nor any prerequisites such as needing a domain and profile mkey. Usage is only implied by the tool name.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the 'Side effects: None (read-only)' line merely restates structured data and adds no new behavioral context. No information about scoping, pagination, or return shape is offered.

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?

Two short, front-loaded lines with no padding, though 'via the engine' is a wasted phrase that could be dropped without loss.

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 list tool with a fully documented single parameter and no output schema, this is minimally viable. It omits any indication of domain scoping behavior or result format, but the annotations cover the safety profile.

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% with a single documented 'domain' parameter, so the schema carries parameter meaning. The description adds nothing beyond that, which is the baseline 3 case.

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?

States a specific verb and resource (list SMTP Auth profiles), which is distinguishable from the sibling get/create/update/delete tools by the verb. However, 'via the engine' is filler and the awkward 'Profile profiles' phrasing adds no information.

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?

No guidance on when to use this versus the sibling fortimail.profiles.smtp_auth.get or the parallel imap_auth.list, and no note that results are scoped to the required domain parameter. The agent must infer usage entirely from the name.

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?

Annotations declare readOnlyHint=false, idempotentHint=true, openWorldHint=true and destructiveHint=false, but the description adds nothing about what actually happens on an update: no note on which settings fields are mutable, whether omitted fields are reset, or what permissions are needed. For a mutation tool with a free-form nested 'settings' object, this is a complete omission of behavioral context.

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?

It is short, but that brevity reflects under-specification rather than disciplined concision. The single label line carries no information an agent could act on.

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 mutation tool with a nested free-form settings object, no output schema, and no annotations explaining mutation semantics, the description leaves everything an agent needs unexplained. Sibling create/get/delete tools exist but are never referenced.

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 domain, key and settings are already documented in the schema; baseline 3 applies. The description supplies no additional meaning for the especially under-specified 'settings' object (additionalProperties: {}), but it does not degrade what the schema 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 is a verbatim restatement of the tool name and title ('Update SMTP Auth Profile'), adding no scope, resource qualifiers, or differentiation from siblings like fortimail.profiles.imap_auth.update. It is a tautology rather than an explanation.

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?

There is no guidance about when to use this tool versus fortimail.profiles.smtp_auth.create, .get, .delete, or the imap_auth equivalents. No prerequisites, no mention of required domain/key context beyond what the schema already names.

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?

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered by structured data. The description's added value is the requirement of a confirmation header, but it is vague ('see engine docs') and restates the destructive trait already present in annotations.

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?

Two labeled fragments, front-loaded with purpose then side effects, with no filler sentences. The 'see engine docs' pointer is a mild deferral but keeps the definition tight.

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 an irreversible destructive operation with no output schema, the definition states destructiveness and mentions a confirmation header, but it never specifies the header itself or whether deletion is permanent, pushing essential detail to external docs. Adequate but with a clear gap for a tool whose main risk is irreversibility.

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% for both parameters, covering the comma-separated mkey format and the queue_type enum with thirteen values, so the schema carries the semantics. The description adds nothing about parameter formats, which is the expected baseline when the schema 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?

The description names a specific verb and resource (DELETE on the mail queue) and matches the title 'Delete Queued Mail', so an agent knows it removes messages from a queue. It does not, however, distinguish itself from siblings like fortimail.queue.reroute or fortimail.queue.download beyond the obvious delete semantics.

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?

There is no statement of when to use this tool versus alternatives such as fortimail.queue.search or fortimail.queue.view for locating mkeys, nor any exclusions or prerequisites. The only guidance is a deferral to 'engine docs' for the confirmation header, which leaves the agent without actionable selection 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?

The annotations declare readOnlyHint=true and idempotentHint=true, implying a functional read operation. The description contradicts the title's implied capability by saying the tool is not exposed and only returns error guidance, which is behaviorally inconsistent with a working read-only tool. No useful behavioral context is provided beyond the contradiction.

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 extremely short and front-loaded, but it is uninformative rather than concise. It has no wasted words, but also no useful content beyond stating unavailability.

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 that is supposedly not implemented, the description does not tell an agent what to do instead, what error to expect, or how to handle the stub. There is no output schema, no further guidance, and no alternative tool suggested. It is not complete enough for an agent to act on.

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 adds nothing about parameters. Per the rubric, with high schema coverage the baseline is 3, even though the description provides no parameter meaning. The schema itself documents mail_keys and queue_type adequately.

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 is 'Not exposed on the FortiMail Engine OpenAPI in this MCP version', which explicitly says the tool does not perform its named function. A tool titled 'Download Queued Mail' provides no statement of what it actually does; it says only that it is not available. This is misleading by design, so purpose clarity is minimal.

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?

There is no guidance on when to use this tool versus alternatives like fortimail.queue.view or fortimail.queue.list. The description says only that it is unavailable and returns error guidance, which gives no actionable usage context.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so 'Side effects: None (read-only)' merely restates structured data and adds no new behavioral information. It says nothing about pagination behavior, default result volume, or what happens when start_index exceeds the queue length.

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?

Two labeled fragments, front-loaded with purpose before side effects, with zero filler. It is efficient, though the extreme brevity leaves substantive gaps rather than excess.

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 listing tool with no output schema, the description gives no indication of what a result contains or how pagination fields interact, and it does not disambiguate among the several queue siblings. Annotations and the schema cover safety and parameters, but the routing and result-shape context an agent needs is absent.

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 all three parameters and the baseline is 3. The description's references to 'type', 'offset', and 'limit' loosely map to queue_type/start_index/page_size but use different names, adding neither format detail nor constraint context 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 names the resource and the HTTP endpoint ('GET /v1/queue') and implicitly a listing operation, so the basic purpose is recoverable. However, it never states what a queue listing actually is in this context and offers no differentiation from the adjacent siblings fortimail.queue.search, fortimail.queue.view, or fortimail.queue.download, leaving an agent to guess which queue reader to pick.

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?

There is no when-to-use guidance at all: nothing says how this differs from queue.search (filtered retrieval) or queue.view (single-item detail), nor whether it should be preferred for broad enumeration. The agent must infer usage purely from the name.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, but the description adds nothing beyond them. There is no mention of what happens to the original queued messages, whether rerouting is reversible, or that it targets an external host.

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?

While short, the single sentence is uninformative rather than concise. This is under-specification, not economical phrasing, and there is no front-loaded explanation of the operation.

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 mutating, open-world tool with three required parameters and no output schema, the description is entirely inadequate. An agent gets no information about side effects, required permissions, or expected outcome.

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 mail_keys, queue_type, and alternate_host, including the queue_type enum. The description contributes no additional parameter meaning; baseline 3 applies when the schema does the work.

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 only restates the HTTP endpoint 'POST /v1/queue/reroute', which is a tautology of the tool name. It does not state in plain language that the tool sends queued mail to an alternate host; that information lives only in the title, not the description body.

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?

No guidance whatsoever on when to use this versus siblings like fortimail.queue.delete, fortimail.queue.download, or fortimail.queue.view. The agent is given no conditions, prerequisites, or 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint, and openWorldHint; the description's "None (read-only)" simply restates that. It adds no new behavioral context such as pagination limits, result caps, or engine-side filtering quirks.

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?

Two compact bolded sections with the endpoint and filters front-loaded. Every sentence carries 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?

For a read-only search tool with no output schema, the description covers purpose and side effects adequately. It omits sibling disambiguation and any indication of what the search returns, leaving the agent to infer the tool's role in the queue tool family.

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 all nine parameters fully, making 3 the baseline. The description lists filter names but uses different casing (clientIp, sessionId) than the schema, adding no real meaning beyond what the schema 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?

States a specific verb+resource (search mail queue) and names the underlying endpoint plus its optional filter fields, so the agent knows exactly what operation this performs. It does not, however, distinguish it from the sibling fortimail.queue.list, which an agent would need to disambiguate between.

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?

There is no guidance on when to use this versus fortimail.queue.list, queue.view, or queue.download. Filters are listed but no condition or scenario selects this tool over its siblings.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered elsewhere. The description adds nothing further — no note on whether the view returns full message content/headers, whether mail is fetched from the live engine, or any rate/expiry behavior — so it contributes no behavioral context beyond structured fields.

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 a single endpoint fragment with a '**Purpose:**' label — extremely brief, but this is under-specification rather than effective conciseness. Nothing is front-loaded because there is essentially no explanatory content at all.

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 is the only place return values could be explained, and it says nothing about what a queue view yields. For a tool requiring two parameters and aimed at inspecting individual queued mail, this is completely inadequate to guide 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?

Schema description coverage is 100%: mail_key, account_type (with a 13-value enum), and open_method are all documented in the schema, including the default and range for open_method. Baseline 3 applies since the description adds no meaning beyond the schema, but nothing is left ambiguous.

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 only restates the tool name/title as a raw endpoint string, `GET /v1/queue/view`, which is a tautology rather than an explanation of what the operation does. It does not say that it retrieves the full content/details of a single queued message, nor does it distinguish itself from `fortimail.queue.list` or `fortimail.queue.search`.

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?

There is no when-to-use guidance, no prerequisite (e.g., needing an mkey obtained from `fortimail.queue.list`), and no mention of the queue.* siblings such as list, search, delete, reroute, or download. The agent must infer entirely from the name which of the six queue tools applies.

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?

Annotations already declare destructiveHint=true, idempotentHint=false, readOnlyHint=false and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: it does not state irreversibility, whether deleted report keys can be recovered, or any auth/rate-limit context.

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 single sentence is front-loaded and free of filler, but it is under-specified rather than genuinely concise. It is there is no structure to help an agent beyond the raw endpoint.

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 destructive, non-idempotent delete operation with no output schema, the description should at minimum warn about permanence or reference how to obtain report_keys. It leaves the agent with only the raw endpoint, which is inadequate context for a mutation 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 all three parameters (domain, report_keys, report_class) are documented in the schema. The description adds no parameter meaning beyond 'with query params', so the baseline of 3 applies.

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 names the HTTP verb and endpoint (DELETE /v1/reports), which implies deleting reports, but it largely restates the title 'Delete Reports' and adds no scope detail (e.g. which reports, by domain/class). It does not distinguish this tool from siblings like fortimail.reports.list or fortimail.reports.download.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as reports.list to find report keys first. The phrase 'with query params' gives no conditional information about when this tool is the right choice.

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?

Annotations already declare the safety profile (readOnly, idempotent, non-destructive, openWorld), so that burden is lifted. The description does add one genuinely useful behavioral detail: the response is a binary payload decoded as UTF-8 when possible, which matters since there is no output 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?

A single short sentence with no bloat, and the behavioral caveat is front-loaded. It is efficient, though the endpoint string itself carries little value to an agent.

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 binary-download tool with no output schema, the description is thin: it does not explain the returned content's format, size, or how report_class/report_key drive the payload. The one UTF-8 note helps but leaves the agent underinformed.

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 all three parameters (domain, report_key, report_class with its enum) are already documented in the schema. The description adds no additional parameter meaning, so the baseline of 3 applies.

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 mostly restates the tool name and title by mapping to the raw endpoint `POST /v1/reports/download`. It implies a download action but does not state in prose what resource is being downloaded or how it differs from siblings like fortimail.reports.generate.* or fortimail.logs.download.

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?

There is no when-to-use guidance, no precondition (e.g., that a report must first be generated via fortimail.reports.generate.* or keyed from fortimail.reports.list), and no mention of alternatives. The agent is left to infer the entire workflow.

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?

Annotations already declare readOnlyHint=false, idempotentHint=false, openWorldHint=true and destructiveHint=false, and the description adds nothing beyond the endpoint string. It does not disclose whether report generation is synchronous or asynchronous, whether it queues a job, or what happens if one is triggered repeatedly.

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?

It is short, but that brevity is under-specification rather than efficiency: the single line carries no substantive content and nothing is front-loaded beyond an endpoint reference.

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, no parameters, and a report-generation tool whose result delivery is undocumented, the description leaves the agent unable to know what it gets back or how to consume it. It is far too thin for the tool's role.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool is 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 only maps the tool to its HTTP endpoint (POST /v1/reports/domain-stats), which essentially restates the title. It never says what the report actually contains or how it differs from siblings like fortimail.reports.generate.mail_stats and fortimail.reports.generate.mailbox_stats.

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?

There is no guidance on when to use this tool versus the two sibling report generators (mail_stats, mailbox_stats) or reports.list/download. No prerequisites, no conditions, no exclusions are stated.

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?

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false and destructiveHint=false, so the safety profile is covered and is not contradicted by the description. The description adds nothing on top of it: no indication of whether the report is generated synchronously or asynchronously, what the effect of the POST is, or whether task_name must pre-exist. With annotations carrying the burden, a 2 reflects a description that contributes zero behavioral context.

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 one short line, but it is under-specified rather than concise — the single sentence is devoted to an endpoint path that duplicates structured information, leaving no room for the guidance an agent actually needs. Brevity here is a symptom of missing content, not economy.

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 and no description of what the generated report contains, whether the call triggers a scheduled task or runs one immediately, or how results are retrieved. For a non-read-only, non-idempotent tool whose name implies a stateful operation, this leaves an agent materially under-informed.

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 task_name parameter is documented in the schema itself as a 'Scheduled task mmkey for mailbox statistics (e.g. from engine UI)'. Per the baseline rule for high coverage with no added param info in the description, a 3 is appropriate; the description adds nothing about where to obtain the mmkey.

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 is essentially a restatement of the tool name as an API endpoint: 'POST /v1/reports/mailbox'. It conveys no verb+resource clarification beyond what the name already says, and gives no basis for distinguishing this tool from its near-identical siblings fortimail.reports.generate.mail_stats and fortimail.reports.generate.domain_mail_stats.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives, even though three other report-generating tools sit in the sibling list. An agent cannot tell from this text why it would pick mailbox_stats over mail_stats or domain_mail_stats.

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?

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false and openWorldHint=true, and the description adds nothing to that profile. It does not disclose whether the report is generated asynchronously, what the task_name keys against, whether results must be fetched via `reports.download`/`reports.list`, or any rate/permission constraints. It contradicts nothing, but contributes no behavioral context.

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?

It is a single brief line, but this is under-specification rather than conciseness: nothing is front-loaded except the HTTP verb and path, and the one sentence carries no actionable information for an agent.

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 report-generation tool with no output schema, the description should explain what is produced and how to retrieve it, and it explains neither. The presence of `reports.list` and `reports.download` siblings strongly suggests a two-step workflow that is entirely undisclosed.

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 there is a single required parameter, so the schema already documents `task_name` with an example (`Daily_Stats`). Baseline 3 applies since the description adds no additional meaning about the parameter.

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 only restates the underlying HTTP endpoint (`POST /v1/reports/mail-stats`), which is a tautology rather than a statement of what the tool does in domain terms. It gives no way to distinguish this from its close siblings `reports.generate.domain_mail_stats` and `reports.generate.mailbox_stats`, which differ only by 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?

There is no when-to-use guidance, no exclusions, and no routing to alternatives such as the domain-level or mailbox-level report generators. An agent must guess which of the three report-generation siblings applies.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. However, the description adds nothing about pagination behavior beyond schema defaults, rate limits, or the openWorldHint implication. With annotations covering safety, the bar is lower, but the description still provides almost no behavioral context.

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 single sentence is concise but under-specified rather than efficient; it conveys a raw endpoint string with no front-loaded purpose. Brevity here is a symptom of missing content, not good structure.

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 read-only listing tool with four optional filters and no output schema, the description should explain what is returned (report metadata? report IDs? list entries?) and how pagination interacts with start_index/page_size. No output schema exists, so the description must carry return-value explanation, which it does not.

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 all four parameters (domain, page_size, start_index, report_class) are already documented in the schema with descriptions, defaults, ranges, and an enum. The description adds no additional parameter meaning beyond the endpoint path, so 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 description only states 'GET /v1/reports', which is essentially a REST endpoint rather than an explanation of what the tool does. It does not clarify that it lists/fetches available report metadata, nor does it differentiate from siblings like reports.generate.* or reports.download.

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?

There is no guidance on when to use this tool versus alternatives such as fortimail.reports.generate.mail_stats, fortimail.reports.download, or fortimail.reports.delete. The agent must infer usage entirely from the tool name.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds nothing behavioral — no indication of whether SMTP config is global or per-domain, auth requirements, or what the payload contains — so it contributes no value beyond the annotations.

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?

It is a single, front-loaded line with no wasted words, but that brevity stems from under-specification rather than disciplined editing — there is essentially no content to structure.

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 and no parameters, the description carries the burden of explaining what the returned SMTP configuration contains (host, port, TLS, auth settings, relay rules) and its scope. It provides none of that, leaving the agent unable to anticipate the response shape.

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 tool takes zero parameters, so per the scoring baseline there are no parameter semantics to document; the empty schema is self-consistent with the description's parameterless endpoint.

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 is just '**Purpose:** `GET /v1/smtp-config`.' — it restates the tool name (Get SMTP Configuration) in HTTP-path form without adding any specificity about what configuration is retrieved or how it differs from siblings like fortimail.smtp.config.update.

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?

There is no guidance whatsoever on when to call this versus alternatives such as fortimail.smtp.config.update or other config-get tools. The agent must infer usage purely from the name.

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?

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered structurally. However the description adds literally zero behavioral context — not whether this is a full replacement or a partial merge, what permissions are needed, or what happens to unspecified fields.

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?

It is short, but this is under-specification rather than conciseness — a single fragment that is mostly a URL. There is no front-loaded statement of effect or scope for an agent to act on.

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 mutation tool with a nested free-form settings object, no output schema, and no annotations-level detail about what gets changed, a bare endpoint reference is completely inadequate. An agent cannot know what a valid settings payload looks like or what the call returns.

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 there is only one required parameter, so the baseline is 3 by rule. The description adds nothing beyond the endpoint path, but the schema does carry the parameter documentation ('Fields to update (e.g. proxy_original)').

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 only restates the tool name/title as an HTTP endpoint (`PUT /v1/smtp-config`); it is a tautology rather than an explanation of what 'SMTP configuration' covers or which attributes can be changed. It does not distinguish this from sibling update tools like fortimail.domains.update or the paired fortimail.smtp.config.get.

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?

No guidance on when to use this tool, no prerequisites, and no mention of the obvious alternative fortimail.smtp.config.get for reading the current configuration. An agent gets nothing to decide between this and any sibling.

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?

Annotations already declare write (readOnlyHint=false), non-idempotent, non-destructive, open-world behavior. The description adds a genuinely non-obvious side effect beyond that: 'Flushes MCP cache.' It does not cover auth/permission requirements or behavior when the key already exists, so it stops short of a 5.

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 labeled lines (Purpose / Inputs / Side effects), each front-loaded and information-dense. No filler, no repetition of schema or annotation data.

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 3-param mutation with annotations and no output schema, the definition covers endpoint, required inputs, settings fields and a side effect. Gaps remain around permission requirements and failure modes (duplicate key), but nothing critical to correct invocation 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 coverage is 100% for the two required params, and the description usefully enumerates fields inside the opaque `settings` object (password, status, type, displayname) — information the schema's 'User fields' with additionalProperties:{} does not provide. It points to the engine OpenAPI rather than fully specifying settings, so not a 5.

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?

States a specific verb+resource ('Create mailbox user') and pins it to the exact REST endpoint POST /v1/domains/{domain}/users/{key}). The 'create' action plus the users.* sibling family makes it easy to separate from users.get/update/delete/list, though it never names those siblings explicitly.

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?

There is no when-to-use or when-not-to-use guidance, no mention of prerequisites (e.g. domain must already exist), and no routing to alternatives such as users.update when the mailbox already exists. The structured 'Inputs' block is parameter documentation, not 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds the non-obvious side effect 'Flushes MCP cache,' but does not explain permanence, auth requirements, or cache-flush consequences.

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?

Two compact labeled lines, purpose first and side effect second. There is no filler, and the critical routing information is front-loaded.

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 two-parameter delete operation with rich annotations and full schema coverage, the description supplies the endpoint and a key side effect. It stops short of usage conditions, but the structured fields already carry safety and parameter details, so an agent has enough to call 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 both required parameters are described there ('User mkey', 'Domain name'). The description only repeats the path placeholders domain and key, adding no syntax or 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 gives the exact HTTP route DELETE /v1/domains/{domain}/users/{key}, and the title identifies the resource as a mail user. That is a specific verb and resource that separates it from sibling users.get/create/update.

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?

No when-to-use guidance, prerequisites, or alternatives are provided. The endpoint implies deletion, but the description does not say when this tool should be selected over users.update or other user-management siblings.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description's 'Side effects: None (read-only)' merely restates these, adding no new behavioral context such as auth needs, rate limits, or error handling.

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 labeled sections (Purpose, Inputs, Side effects) front-load the purpose with zero filler. Every line is useful and the structure is immediately scannable.

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 two-parameter read tool with rich annotations and full schema coverage, the description covers purpose, inputs, and side effects. It omits return value details, but with no output schema and a get operation, the core requirement for correct invocation is met.

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 both parameters are documented in the schema. The description lists 'domain' and 'key' but adds no syntax or format details 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?

States a specific verb ('Fetch') and resource ('one user'), with the exact REST endpoint. The singular 'one user' inherently distinguishes it from sibling fortimail.users.list and from create/update/delete 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?

No guidance is given on when to choose this over fortimail.users.list or other user-related endpoints. Only inputs and side effects are listed; no when-to-use or exclusion conditions are provided.

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?

'Side effects: None (read-only)' merely restates the readOnlyHint/destructiveHint=false annotations and earns little credit. It does add one piece of context the annotations do not carry — the return shape is a Markdown summary — but omits pagination behavior, result caps, and authorization requirements for the domain.

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?

Four labeled lines, purpose front-loaded, zero filler, and the endpoint is included compactly. Nothing could be removed without losing information.

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 one-parameter read-only list tool with full annotation coverage, the definition covers purpose, input, and output format. The remaining gap is pagination/result-limit behavior, which matters for a list endpoint but is a minor omission 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?

Schema description coverage is 100% and the single parameter is documented in the schema itself, so the baseline of 3 applies. The description only restates 'Inputs: domain' and adds no format, casing, or wildcard guidance beyond what the schema 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?

States a specific verb and resource ('List mailbox users for a domain') and pins the exact REST endpoint, so the agent knows it enumerates users rather than fetching one. It does not explicitly name siblings like fortimail.users.get or fortimail.users.create, leaving the list-vs-get distinction to be inferred from the verb and endpoint.

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 its use case (enumerate mailbox users scoped to a domain) via the required 'domain' input, but offers no explicit when-to-use, prerequisites, or named alternatives such as fortimail.users.get for a single user. Usage is inferable but not stated.

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?

Annotations already declare the write/non-idempotent/open-world profile, and the description adds a genuinely useful side effect ("Flushes MCP cache") plus the requirement that the body include `type`. It stops short of describing permission needs or what an existing key collision does.

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?

Two labeled lines, front-loaded with purpose then side effects, no filler. Slightly terse for a mutation tool, but every sentence carries information.

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?

No output schema exists, so return values need not be explained, and the cache-flush note plus required `type` cover the main behavioral surprises. However, for an open-world mutation with a nested free-form `extra` object, there is no mention of failure modes or payload expectations.

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 does add one piece of value by clarifying that `type` is required by the engine and can be supplied via `map_type` or a full `body`, but it does not explain `external_name` or `extra` 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 states the concrete endpoint (`POST /v1/user-maps/{key}`) and the name/title give verb+resource (Create User Map). It is distinguishable from the sibling update/get/delete/list user-map tools, though the description itself never names them.

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?

There is no guidance on when to create a user map versus updating one, nor prerequisites or which sibling to pick for adjacent needs. The agent is left to infer usage entirely from the name and endpoint.

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?

Annotations already declare destructiveHint=true, idempotentHint=false, readOnlyHint=false, and openWorldHint=true, covering the core safety profile. The description adds a concrete side effect beyond annotations: it flushes the MCP cache, which is useful operational context.

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 short, front-loaded statements that cleanly separate purpose from side effects. Every sentence adds information 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 simple one-parameter destructive delete, the description supplies the endpoint and a non-obvious cache side effect, while annotations cover the safety profile. It does not discuss error behavior or return values, but no output schema exists and the tool's complexity is low.

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 key parameter is documented as 'Internal user name (mkey)'. The description only references {key} in the endpoint and adds no format or semantic detail beyond the schema, so the baseline 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 states a specific HTTP method and resource, DELETE /v1/user-maps/{key}, which clearly identifies deleting a user map by key. The title reinforces this, but the description itself does not explicitly distinguish the tool from sibling operations such as get, update, or create beyond the HTTP verb.

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 no explicit guidance on when to use this tool versus alternatives such as updating, getting, or listing user maps. Usage is only inferable from the DELETE endpoint and title, with no when-not-to-use or prerequisite context.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is known. The description adds 'Side effects: None (read-only)' which is redundant with annotations, but it also discloses the important behavioral quirk that the tool is implemented as a list-then-filter operation rather than a direct GET. This is useful context beyond annotations, though it doesn't cover things like pagination or result limits.

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 extremely concise, using a structured format with Purpose, Inputs, and Side effects. Every sentence earns its place, and the key information (purpose and implementation workaround) is front-loaded. No wasted words.

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 a simple one-parameter read-only tool with full schema coverage and rich annotations, the description provides the essential implementation detail that the tool lists instead of directly getting. It is complete enough for an agent to call correctly. The only minor gap is that it doesn't mention return format, but there is no output schema and the implementation detail implies a list response filtered to one item.

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 has 100% description coverage, fully documenting the single 'key' parameter as 'Internal user name (mkey)'. The description repeats this as 'key — internal mkey'. Baseline of 3 is appropriate when the schema already does the work; the description adds no new syntax or format details beyond what the schema 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 states a specific verb+resource: find one user map by key. It clearly distinguishes itself from the sibling fortimail.users.maps.list by specifying 'one map' and noting there is no single-GET in OpenAPI. This is clear and specific, though it doesn't explicitly contrast with the other maps siblings like create/update/delete.

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 the usage pattern: to retrieve a single user map, you must call the list endpoint and filter, because no single-GET operation exists. This gives clear context and implicitly tells when to use this tool versus the list tool. No explicit exclusions are stated, but the implementation detail is helpful.

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's only behavioral claim, 'None (read-only)', restates what the annotations already declare (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so it adds no value beyond structured data. It says nothing about pagination, result size, or whether the list is scoped to a domain/user, which for an unpaginated list endpoint would be genuinely useful.

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?

Two short labeled lines, front-loaded with the endpoint and side-effect profile, with no filler. It is appropriately sized, though the bold headers add mild ceremony for such a small payload.

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 carries the burden of describing what is returned, and it does not — no mention of the shape of a user-map entry, ordering, or pagination. Annotations cover the safety profile, but the agent still cannot predict the response from this definition.

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 tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify that the empty schema does not already imply.

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 underlying endpoint (`GET /v1/user-maps`) and the title 'List User Maps' identifies the verb+resource, but the description body itself never says what a user map is or how this list differs from `fortimail.users.maps.get` or `fortimail.users.list`. It is a minimal, endpoint-anchored statement of purpose rather than a distinguishing one.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as `fortimail.users.maps.get` for a single map or `fortimail.users.list` for users. The listing intent is only inferable from the title and path, so the agent gets context but no routing 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?

Annotations already declare non-read-only, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds a genuine extra trait not present in the annotations: that the call flushes the MCP cache, which is meaningful side-effect information for a mutation. It stops short of describing permissions, what happens to unmentioned fields, or partial-update semantics.

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?

Two labeled fragments, no filler, purpose front-loaded ahead of side effects. It is efficient, though so terse that it barely qualifies as a description rather than a metadata stub.

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 two-parameter mutation with a nested freeform object and no output schema, annotations cover the safety profile and the description adds the cache-flush side effect. Still missing is any sense of what fields `settings` accepts or how this differs from create/delete, which leaves meaningful ambiguity for the caller.

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; `key` (mkey) and `settings` are both documented in the schema. The description adds nothing about the freeform `settings` object, whose updatable fields are opaque (`additionalProperties: {}`), but that gap is not something the description was expected to close here.

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?

It states the verb and resource only indirectly through the raw REST mapping (`PUT /v1/user-maps/{key}`), without ever saying what updating a user map actually does or what a user map is. The name and title already convey 'Update User Map', so the description adds endpoint identity rather than functional meaning. It does not distinguish this from siblings like users.maps.create or users.maps.get beyond the verb embedded in the path.

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?

There is no guidance on when to call this versus users.maps.create, users.maps.delete, or fortimail.cache.flush. No prerequisites, ordering, or conditions are given. The agent must infer entirely from the tool name.

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?

Annotations already declare readOnly=false, idempotent=true, destructive=false, and openWorld=true. The description adds a concrete non-obvious behavior: it flushes the MCP cache. It still omits permissions and update scope details, but the added side effect is valuable beyond the annotations.

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 short labeled lines with no filler. Purpose and side effects are front-loaded and easy to scan.

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 mutation with a nested, dynamically typed settings object and no output schema, the description covers the endpoint and one important side effect. It does not explain what settings can contain, permissions, or update scope, leaving some contextual gaps despite strong schema and annotation support.

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%, with domain, key, and settings documented in the schema. The description's path placeholders do not add meaning beyond the schema, so the baseline of 3 applies.

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 exact REST operation and path, `PUT /v1/domains/{domain}/users/{key}`, which identifies both the resource and the mutation. It distinguishes this tool from sibling user operations by method and path, though it does not spell out 'update mail user settings' in prose.

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?

There is no when-to-use guidance, no comparison to siblings such as users.create, users.get, or users.delete, and no prerequisites. The agent can infer usage from the endpoint, but the description provides no explicit usage guidance.

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