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

With no annotations provided, the description carries the burden and does well: it discloses that the currently active script is replaced and remains stored but inactive, which is important mutation context. It does not mention required permissions, error behavior for missing scripts, or the response shape, so it stops short of full transparency.

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

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

Two sentences, front-loaded with the primary effect and followed by the replacement caveat. Every sentence earns its place with no wasted wording.

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 no annotations and no output schema, the description covers the key behavioral impact (activation and replacement). Combined with complete schema documentation, an agent has enough to call it correctly, though error semantics and return values remain undocumented.

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, including the case-sensitive script name and the accountId/accountName alternative. The description adds no parameter-level meaning beyond what the schema provides, 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 uses a specific verb and resource: 'Make a script the active one,' and immediately states the effect of filtering all incoming mail. This clearly distinguishes it from sibling tools such as sieve_deactivate_scripts without needing to open the schema.

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

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

It gives a clear usage condition: 'Only do this when the user asks for the script to go live.' This tells the agent when to invoke it, though it does not explicitly name alternatives like sieve_deactivate_scripts or describe when not to use it beyond the go-live condition.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the default test-before-save behavior with rollback semantics ('nothing is saved if they fail'), the storage location ('shared encrypted store used by every MCP client'), and the credential-safety concern that motivates the CLI alternative.

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 sentences, front-loaded with purpose, then the usage steering, then the behavioral guarantee. No filler; each sentence adds a distinct decision-relevant fact.

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 no annotations and no output schema, the description covers the critical gaps: safety of the write (test-first), what happens on failure, and where data lives. Combined with a fully documented schema, an agent has everything needed to call this 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%, so the schema already documents all 8 parameters thoroughly, making 3 the baseline. The description adds value beyond the schema by explaining the test/save interaction ('by default the connection and login are tested first') and the storage model, giving semantic context that no single parameter field conveys.

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 ('Add') and resource ('ManageSieve account'), and its name/scope clearly distinguishes it from siblings like sieve_update_account or sieve_list_accounts. An agent can tell immediately this is the creation path for a new account.

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

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

Explicitly states the preferred alternative (the CLI setup tool) and the precise condition under which this tool should instead be used ('only if the user explicitly provides the details here'). This is a rare case of a description that actively steers away from itself and names the exact scenario for use.

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

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

No annotations are provided, so the description carries the full burden; it does disclose the key behavioral trait that nothing is persisted ('without saving it') and that validation uses the server's own compiler, catching unsupported extensions. It stops short of stating auth requirements or how the error/warning payload is shaped, but the safety profile is clear.

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

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

Three short sentences, front-loaded with the action and the non-persisting constraint, then the return values, then the sibling relationship. Every sentence carries distinct information with zero padding.

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, single-required-param tool this covers purpose, non-persistence, return categories, and sibling routing. With no output schema, the error/warning payload structure is only described at a high level, which is the one 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% and each parameter (content, accountId, accountName) is documented in the schema, including the RFC 5228 require-line requirement and the single-account fallback. The description adds no parameter-level detail beyond that, 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?

States a specific verb (validate) and resource (Sieve source) plus the scope constraint 'without saving it', and explicitly distinguishes itself from sieve_put_script. An agent can tell exactly what this does versus the other 14 siblings.

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

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

Explicitly names the alternative (sieve_put_script) and its relationship — put runs this automatically — and gives the selecting condition: 'use it directly while iterating on a draft.' Nothing about when to reach for this tool is left to inference.

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

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

With no annotations provided, the description carries the behavioral burden well by stating that the active script is deactivated, all filtering stops, and scripts remain stored rather than deleted. It omits details such as idempotency or behavior when no active script exists, but the key side effect and data-retention behavior are disclosed.

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

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

The description is two concise sentences with the effect front-loaded and no wasted language. The caveat about explicit user intent follows immediately and 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 simple two-optional-parameter tool with no output schema and no annotations, the description provides enough context to select and invoke it correctly: what it does, what happens to stored scripts, and when to use it. The account selection details are already handled by the fully described schema.

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

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

Schema description coverage is 100%, so both accountId and accountName are already documented in the input schema. The description adds no parameter-specific meaning beyond what the schema provides, which is the baseline when schema coverage is complete.

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

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

The description uses a specific verb ("Deactivate") and resource ("active script") and states the concrete effect: no Sieve filtering is applied to incoming mail. This clearly distinguishes the tool from its sibling sieve_activate_script and other script-management 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 gives an explicit usage condition: "Only when the user explicitly wants filtering switched off." That is clear guidance on when to use it, though it does not name the alternative tool (sieve_activate_script) for re-enabling filtering.

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

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

With no annotations provided, the description carries the full burden and does so well: it discloses the destructive outcome, a server-side guard that blocks the active script, a side effect (a local backup is written first), and the return value (backup file name). That is exactly the context an agent needs before committing an irreversible-looking mutation.

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 short sentences, each carrying a distinct fact (what it does, what it refuses, what side effect it produces, when to invoke). Front-loaded with the action and 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 3-parameter mutation tool with no annotations and no output schema, the description covers action, guard, side effect, return value, and invocation policy. The only gap is recovery guidance — it does not mention that the backup can be retrieved via sieve_list_backups/sieve_get_backup, which would close the loop on the destructive operation.

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 'name', 'accountId', and 'accountName' are already fully documented in the schema, including the case-sensitivity and the list_scripts cross-reference. The description adds no parameter-level detail beyond what the schema supplies, 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?

Opens with a specific verb+resource pair ('Delete a stored script from the server') that cleanly separates it from siblings like sieve_rename_script, sieve_put_script, and sieve_activate_script. The guard clause ('Refuses to delete the active script') further narrows scope so an agent knows exactly which deletions this tool will perform.

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 precondition for invocation ('Only when the user asks for the script to be deleted') and an explicit exclusion (the active script cannot be deleted). It does not, however, route the agent to the natural alternative workflow — deactivating via sieve_deactivate_scripts before deletion, or restoring from the returned backup via sieve_get_backup.

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

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

No annotations are provided, so the description carries the full burden. It discloses the read-only nature ('Read the content') and the multi-tool restore chaining, but says nothing about return format, whether the backup content is text or binary, or any access prerequisites. Adequate but with real disclosure gaps for an unannotated 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?

Two short sentences with zero waste: purpose first, workflow second. Every sentence earns its place and the selection-relevant information leads.

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 small 3-parameter read tool with full schema coverage and no nested objects, the description covers what it does and the key follow-on workflow. Without an output schema, one might wish for a note on the shape of the returned content, but that is the only 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%, with the file parameter already stating it must match sieve_list_backups output and the account fields documented. The description adds no parameter detail beyond the sibling's overwrite flag. Baseline 3 applies 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?

States a specific verb and resource: 'Read the content of a local backup.' This distinguishes it from sieve_list_backups, which is only named indirectly in the schema. Clear enough to select without opening the schema, but the sibling differentiation is implicit rather than stated.

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

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

Explicitly routes the agent to sieve_put_script for the restore use case and flags the overwrite: true condition. There is no stated 'when not to use' (e.g., call sieve_list_backups first to obtain the file name), but the primary workflow is unambiguous.

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

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

With no annotations, the description carries the burden and discloses that the tool connects and logs in, returns server capabilities, and doubles as a connection/account test. It still omits error behavior or auth failure details, but adds meaningful behavioral context beyond the schema.

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

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

The description is front-loaded with the main action and key return field, then adds two tightly relevant usage notes. Every sentence adds value with no filler.

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

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

For a simple tool with no output schema, the description explains the important return value (`sieveExtensions`) and why to use it. It could say more about other capability fields or account scoping, but it is sufficient to call and interpret the tool correctly.

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

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

Schema description coverage is 100%, so the two account parameters are already well documented in the schema. The description adds no parameter meaning or selection guidance, which matches the baseline 3 for high-coverage schemas.

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 action (connect, log in, return capabilities) and identifies the key resource (`sieveExtensions` with concrete examples). It makes the tool's distinct purpose obvious relative to siblings like script-writing or account-management 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 gives clear usage contexts: check before writing a script that `require`s an extension, and use it as the quickest account test. It does not explicitly name alternatives or when-not conditions, which keeps it below a 5.

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

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

With no annotations, the description carries the full burden. It makes the read-only nature implicit via 'Read' and adds useful workflow context, but says nothing about return format, error conditions if the script name is wrong, or account-resolution behavior. Adequate but with clear gaps for an un-annotated 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?

Two sentences, front-loaded with the core purpose followed by actionable workflow guidance. Every sentence earns its place with no redundancy.

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

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

Given three well-documented parameters, no annotations, and no output schema, the description covers what the tool does and how to use the result. It could be improved by noting what the return value looks like (full text, error if missing), but the essentials are present.

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%, with the 'name' parameter described as case-sensitive and tied to sieve_list_scripts, so the schema already does the semantic work. The description adds no meaning about parameters beyond what the schema provides, 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 ('Read') and resource ('the full source of a Sieve script'), making it clearly distinct from the write-oriented siblings like sieve_put_script and sieve_check_script. An agent can tell immediately this is a retrieval 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?

The description gives explicit workflow guidance ('Always read the current script before changing it, and edit that text rather than writing a replacement from scratch'), which tells the agent both when to call this tool and how to use the result. It does not name the specific alternative tool (e.g., sieve_put_script) or state exclusions, keeping it below a 5.

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

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

With no annotations, the description carries the burden and usefully discloses that the password itself is never returned while noting where password information comes from. It still does not explicitly state read-only behavior, permissions, error behavior, or ordering, so important behavioral gaps remain.

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 sentences, front-loaded with the core action, and the parenthetical return-field detail is efficient. There is no wasted text.

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?

Since there is no output schema, the description usefully lists the returned fields and explains the primary use case for accountName. It is sufficient for a zero-parameter list tool, though it omits empty-state, ordering, and error details.

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

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

The tool has zero parameters, so the baseline is 4. The description appropriately adds no parameter guidance because there is nothing to configure.

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

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

The description uses a specific verb and resource: 'List configured ManageSieve accounts.' It also names the returned fields and distinguishes this account-listing tool from sibling account mutation tools and script 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 gives a clear usage condition: 'Call this first when the user has more than one mailbox, to get the accountName for other tools.' It does not explicitly state when not to use it or name an alternative, but the context 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?

With no annotations, the description carries the full burden: it discloses that backups are automatic, local, and returned newest first, which is valuable beyond the name. It does not state that this is a non-mutating read, whether results are paginated or capped, or how long backups are retained, which matters for an unannotated 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?

Two short sentences, zero waste. The core purpose and the key behavioral trait (ordering) are front-loaded, with the workflow hint second.

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 list tool with no output schema, the description covers what is listed, where it came from, ordering, and the natural follow-up tool. Minor gaps remain around result size limits and retention, but nothing needed to call it correctly is missing.

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

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

Schema description coverage is 100%, so all three parameters (name, accountId, accountName) are already documented in the schema. The description adds no filtering semantics 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?

States a specific verb and resource ("List local backups"), explains their origin ("taken automatically before scripts were overwritten or deleted"), and gives ordering ("newest first"). This clearly distinguishes it from the sibling sieve_get_backup, which retrieves a single backup.

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

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

Explicitly routes the agent: "Use with sieve_get_backup to undo a change" names the follow-up tool and the workflow. It lacks explicit when-not-to-use guidance or a note on when listing is preferable to direct script inspection, so it stops short of a 5.

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

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

With no annotations, the description carries the burden and adds meaningful domain behavior: only one script is active at a time and that active script filters incoming mail. It implies a read-only list operation, though it does not discuss permissions, pagination, or return format.

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

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

The description is three short sentences, front-loaded with the core action and active-script behavior, with no wasted text. Every sentence contributes to selection or usage.

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 no output schema and fully documented parameters, the description covers the essential return concept: scripts and which one is active. It stops short of describing script object structure, but that is a minor gap for this operation.

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 accountId and accountName are already well documented in the schema. The description adds no parameter-specific meaning beyond what the schema provides, 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 uses a specific verb and resource: listing Sieve scripts and identifying the active one. It distinguishes itself from siblings like sieve_get_script and sieve_activate_script by explaining that the active script is the one filtering incoming mail.

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

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

It explicitly says to start here before reading or changing filters, giving clear sequencing guidance. It does not name specific alternatives by tool name, but the context is sufficient to route an agent correctly.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses validation-before-write, no-write-on-invalid behavior, overwrite requirements, local backup before replacement, dryRun diffing, and the fact that writing does not automatically activate a script. It also explains the side effect when replacing an already-active script.

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

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

The description is front-loaded with the core action, then gives validation, overwrite, workflow, and activation details in a compact sequence. Despite being longer than a one-liner, every sentence adds operational value for a destructive write tool with no 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?

Given six parameters, no annotations, and no output schema, the description is complete enough for correct invocation. It covers validation, overwrite, dryRun, backup behavior, recommended workflow, and activation semantics without needing return-value documentation.

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 defines all six parameters. The description nonetheless adds useful parameter-level meaning by tying overwrite to local backup and dryRun to showing a diff before replacement, going somewhat beyond the structured field descriptions.

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

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

The description starts with a specific verb and resource: create or replace a Sieve script. It distinguishes this from sibling tools by explaining validation, overwrite requirements, and activation behavior, so an agent can identify its role without opening the schema.

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

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

It gives an explicit recommended workflow for changes and names the exact sibling tools to use at each step. It also states when overwrite is required, when dryRun should be used, and when activation must be handled separately.

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

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

With no annotations, the description carries the full burden and does meaningful work: it discloses that the effect is local-only and that server-side scripts are untouched, which is the key blast-radius question. It omits what happens on an unknown account (error vs. silent no-op) and whether the removal is reversible, leaving those gaps for a mutation 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?

Three short sentences, front-loaded with the action and effect scope, followed by the invocation guard. Every sentence adds an operational constraint; none restates the tool name.

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

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

For a two-parameter, output-schema-less mutation tool, the description covers what is removed, where, and when to do it. The only missing piece an agent might want is confirmation of the return value or failure behavior on a nonexistent account.

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, but the description adds real information: 'The account must be named explicitly' signals that an identifier has to be supplied even though the schema lists zero required parameters. It does not explain the accountId vs. accountName trade-off, which the schema already covers.

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 ('Remove an account from the local config') and immediately bounds the effect ('only forgets the connection details on this machine; scripts on the server are untouched'). That scope statement clearly separates it from the script-mutating siblings like sieve_delete_script or sieve_deactivate_scripts without needing to name 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?

'only do this when the user asks' gives an explicit gating condition for when to invoke, which goes beyond most definitions. It stops short of naming alternatives (e.g., sieve_update_account for changing rather than removing an account), so it is clear context without full exclusion guidance.

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

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

With no annotations, the description must carry the behavioral burden. It usefully discloses two key traits: the script remains active after renaming, and the operation fails if the new name is already taken. However, it omits permission requirements, what happens if the original script does not exist, whether the rename is atomic, and other mutation 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?

The description is three short sentences with no wasted words, and the core operation is front-loaded. Each sentence contributes a distinct, useful fact.

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 four-parameter mutation tool with full schema coverage, the description supplies the most important behavioral details: active status preservation and duplicate-name failure. The absence of annotations and an output schema leaves some minor gaps around permissions and error cases, but the essentials for correct invocation are present.

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 are already documented clearly in the schema, including the case-sensitive script name and optional account context. The description adds no parameter-level meaning beyond that, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Rename a script on the server.' This clearly distinguishes it from sibling tools like sieve_put_script, sieve_delete_script, and sieve_update_account. It does not explicitly name a sibling alternative, but the operation 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?

Usage is implied by the operation itself, but the description does not state when to prefer renaming over alternatives such as putting a new script and deleting the old one. The notes about active status and duplicate names are behavioral constraints, not guidance on when to invoke the tool.

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

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

No annotations are provided, so the description carries the full burden. It explains the password workaround but does not state whether omitted settings are preserved, what authorization or validation applies, or what happens on failure. Additionally, 'The account must be named explicitly' conflicts with the schema, which allows accountId or an omitted accountName when only one account exists.

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

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

Three compact sentences with the core operation front-loaded, followed by the password exception and account identification requirement. There is no filler or redundant restatement.

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 nine-parameter mutation tool with no annotations or output schema, the description is minimally adequate: it tells the agent the main fields and avoids the password field. It still omits partial-update semantics and misstates the account identification requirement relative to the schema, leaving important 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 coverage is 56%, so the description must compensate but only partly does. It maps several updatable fields and adds useful guidance on password changes, but it does not clarify the accountId/accountName distinction or explain allowInvalidCertificate beyond the vague 'certificate check'.

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

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

The description states a specific verb and resource: changing connection settings of an existing account. It enumerates the relevant settings (host, port, tls, user, certificate check, name), making it clearly distinct from account creation/removal siblings.

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

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

It usefully redirects password changes to a terminal command and says the account must be identified explicitly. However, it does not contrast this tool with sieve_add_account or explain when to prefer one over the other beyond the existing-account framing.

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