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

The annotations already declare destructiveHint=true, so the destructive nature is known. The description adds valuable specifics: 'Existing local files are not overwritten by default' clarifies the overwrite behavior, and 'SSH credentials are private server-side configuration. Never ask the user for a password' is a critical operational note not captured in annotations. This goes beyond the structured fields and helps the agent handle real-world constraints.

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 sentences with zero fluff. The core action is front-loaded, followed by a behavioral note and a critical usage rule. Every sentence adds essential information, and the structure is clean and scannable for an agent. This is an exemplar of conciseness.

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

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

The tool has 5 parameters and no output schema, so the description must provide enough context for correct invocation. It covers server alias resolution, password handling, and overwrite default, which are critical. However, it doesn't mention what happens on success (e.g., return value) or potential error conditions (e.g., connection failure, invalid paths). The timeout parameter is handled by the schema, but the overall description could be more complete for a file-transfer operation. Still, the core usage is adequately covered.

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 only 40%, with only server and timeout described. The description partially compensates: it defines localPath as 'absolute local path' and mentions the default overwrite behavior, which relates to the overwrite parameter. However, remotePath is not described beyond the tool name, and overwrite itself isn't explicitly defined as a parameter. Given the low coverage, the description adds some value but doesn't fully explain all parameters. A score of 3 reflects this partial compensation.

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

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

The description clearly states the action: 'Download a remote file from the selected server through SFTP to an absolute local path.' It specifies the resource (remote file) and destination (local path). While it doesn't explicitly contrast with similar siblings like ssh_read_file or ssh_upload_file, the phrase 'through SFTP' and 'to an absolute local path' distinguishes it well enough. A clear, specific 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?

The description provides explicit guidance: 'Use ssh_list_servers when the user has not supplied an exact configured alias.' It also instructs the agent to never ask for a password, which is a key usage rule. However, it doesn't explicitly state when to use this tool versus ssh_upload_file (the inverse operation), but the direction is obvious from the name and description. Overall, useful usage direction is present.

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 and readOnlyHint=false, so the mutation risk is known. The description adds valuable behavioral context beyond annotations: timeout range and default, stdout/stderr 1 MiB caps, blocking of common destructive commands, and private server-side SSH credentials. It does not contradict annotations. A small gap is that it doesn't specify what happens on timeout or output truncation, but the disclosed constraints are substantial.

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 sentences, each carrying distinct information: what it does, timeout behavior, output caps and destructive-command blocking, credential handling, and sibling routing. No filler or repetition of schema details. Front-loaded with the core action.

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 tool with no output schema, the description covers the key operational constraints an agent needs: timeout, output limits, destructive command blocking, credential privacy, and server alias resolution. It doesn't describe the return format or error behavior, but the annotations cover the safety profile and the description covers the main invocation concerns. Slightly more detail on exit codes or output structure would make it a 5.

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 67%: server and timeout have descriptions, but command has none. The description adds context about the command being a shell command on a remote Linux server and mentions output caps, but it doesn't add much about the command parameter's semantics beyond what the schema implies. The timeout parameter is already well documented in the schema, so the description's timeout mention is redundant. 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 states a specific verb ('Execute'), a resource ('shell command on the selected remote Linux server'), and clearly distinguishes itself from siblings by focusing on arbitrary command execution rather than file operations or server listing. It is immediately clear what this tool does and how it differs from ssh_read_file, ssh_write_file, ssh_list_servers, etc.

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

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

The description explicitly says to use ssh_list_servers when the user has not supplied an exact configured alias, and instructs the agent to never ask the user for a password. This provides clear when-to-use and when-not-to-use guidance, plus a direct pointer to the relevant sibling 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?

Annotations already indicate readOnlyHint and openWorldHint, so the safety profile is covered. The description adds value by explaining that SSH credentials are private server-side configuration and that the operation returns at most 10000 entries, which is 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 concise sentences, with the core action and limit front-loaded, followed by credential handling and routing to an alternative. No fluff or repetition of schema details.

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 listing tool with annotations covering read-only and open-world behavior, the description covers the action, return limit, credential handling, and when to use the alternative. No critical information for 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 description coverage is 50% (only 'server' has a description, which is already present in the schema). The tool description does not add extra detail about the 'path' parameter beyond implying it is the directory to list. Since coverage is moderate, the description does not compensate further, but the parameters are self-explanatory given the tool's purpose.

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 (List) and resource (remote directory) via SFTP on a selected server, and includes a return limit. This clearly distinguishes it from siblings like ssh_stat, ssh_read_file, and ssh_exec, which perform different 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?

It explicitly instructs to use ssh_list_servers when the user has not supplied an exact alias, providing a clear alternative. It also adds a behavioral constraint ('Never ask the user for a password'), which is important for invocation.

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 indicate readOnly and idempotent, but the description adds significant context: it returns only non-secret metadata and connection status, and explains that SSH credentials are private server-side configuration, so the agent must never request passwords. This goes beyond the annotation baseline and prevents dangerous assumptions.

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 purpose and contains several useful sentences, but it is slightly longer than necessary. The password instruction and usage rule are valuable, though the secret-credentials sentence could be merged with the password rule to reduce redundancy. Overall, it is well-structured and each sentence contributes.

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

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

Given there is no output schema, the description clearly states what the tool returns (non-secret metadata and connection status) and emphasizes the importance of the alias for subsequent operation tools. It also addresses credential handling, which is critical for a discovery tool. Missing minor details like pagination or sorting are not significant for this use case.

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

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

The schema already fully describes the single optional parameter: 'Optional alias, host/IP fragment, or username used to filter configured servers.' The description repeats this list without adding format details, examples, or edge cases. With 100% schema coverage, the description adds no extra semantic value beyond what the schema provides, so a 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: 'List configured SSH servers' and clearly identifies the optional filtering by alias, host/IP, or username. It distinguishes itself from sibling operation tools by explaining that it returns metadata and the exact alias needed for them, making its role 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?

Explicitly instructs when to use this tool: 'Use ssh_list_servers when the user has not supplied an exact configured alias.' It also includes a critical behavioral rule, 'Never ask the user for a password,' preventing a common misuse. The guidance is clear and actionable.

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?

Beyond the readOnlyHint annotation, the description discloses critical behaviors: default 1 MiB limit, hard 5 MiB max, truncation of oversized text, rejection of binary content, and that SSH credentials are private server-side configuration. This adds substantial safety and edge-case awareness for the agent.

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

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

The description is compact, front-loaded with the core purpose and size limits, and each sentence earns its place—no filler or repetition of schema fields that are already self-explanatory.

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

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

The description covers size limits, content type validation, credential handling, and server selection guidance. It doesn't describe the success output format or error cases (e.g., file not found, permission denied), but the readOnly and openWorld annotations partially offload that burden. For a simple read-file tool, it is largely complete.

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

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

With only 33% schema description coverage, the description compensates by clarifying the server parameter (exact alias, use ssh_list_servers), maxBytes (size limits and truncation behavior), and path (regular UTF-8 file). It doesn't add explicit format constraints for path beyond the schema, but it provides meaningful context for two of the three parameters.

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

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

The description states a specific action ('Read a remote UTF-8 regular file through SFTP') and identifies the resource and scope. It also names ssh_list_servers as a fallback, helping an agent distinguish this tool from siblings like ssh_tail_file or ssh_stat.

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 context by mentioning server alias selection and explicitly instructs the agent to use ssh_list_servers when the user hasn't provided an alias, and never to ask for a password. It doesn't explicitly contrast with ssh_tail_file or other read-type alternatives, so the guidance stops short of being fully explicit.

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

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

Annotations already cover read-only, idempotent, and non-destructive hints. The description adds valuable behavioral context: only the selected connection is reloaded/validated, other connections are not affected, and SSH credentials are private server-side configuration. It does not contradict the annotations and supplements them meaningfully.

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 compact sentences, each with a distinct purpose: action, scoping guarantee, credential privacy constraint, and alternative-tool routing. The primary action is front-loaded and there is no extraneous or redundant 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?

For a single-parameter tool with no output schema, this description covers the action, scope, credential handling, and fallback tool selection. It does not detail validation failure behavior, but that is not essential for correct invocation given the annotations and schema richness.

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

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

The schema fully documents the sole parameter with 100% coverage. The description enhances this by specifying that the alias must be an exact configured server alias and directs the agent to ssh_list_servers when one is not available, adding practical sourcing guidance 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?

States a specific action (reload and validate) on a specific resource (selected server configuration). It distinguishes itself from siblings by explicitly scoping to the selected server and noting that other connections are unaffected, making the tool's role clear among the listed SSH 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?

Provides explicit routing guidance to ssh_list_servers when the user has not supplied an exact configured alias, and includes a firm instruction to never ask for a password. It could further contrast against other sibling tools, but the most relevant alternative is addressed and the usage 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?

The description adds meaningful behavioral context beyond the readOnlyHint annotation: it discloses the SFTP lstat mechanics, the symlink-following behavior, and the server-side credential model. It also gives a security directive—'Never ask the user for a password'—which is valuable for agent behavior. No contradiction with 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?

Four short, purpose-driven sentences. The first sentence delivers the core purpose, the second adds a critical behavior, and the remaining sentences address credentials and server routing. Every sentence earns its place, and the structure is front-loaded and 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?

The definition is largely complete for a read-only stat tool: it explains the operation, symlink behavior, credential handling, and how to obtain the server alias. With no output schema, it does not explicitly describe the returned stat fields, but 'SFTP lstat' reasonably implies standard stat metadata; this is a minor gap rather than a critical omission.

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 50%: the server parameter is already described in the schema, but the path parameter has no schema description. The tool description helps by calling it 'a remote path' and explaining lstat semantics, but it does not add much detail about path formatting or expected values. This partially compensates for the schema gap but does not fully clarify parameter semantics.

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 operation: 'Inspect a remote path through SFTP lstat on the selected server.' It also clarifies an important semantic detail—'The final symlink is not followed'—which distinguishes this from a plain read or list operation and helps separate it from siblings like ssh_read_file and ssh_list_dir.

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

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

The description gives explicit routing guidance: 'Use ssh_list_servers when the user has not supplied an exact configured alias.' This addresses a common precondition for selecting the tool. It does not, however, contrast ssh_stat with path-related siblings such as ssh_read_file, ssh_list_dir, or ssh_exec, so the when-not-to-use guidance is partial.

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?

Beyond the readOnlyHint annotation, the description adds useful behavioral context: output is capped, timeout is 30 seconds, SSH credentials are private server-side configuration, and the agent must never ask for a password. It does not detail failure modes or timeout results, but the annotations already cover the read-only nature.

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 short sentences, each carrying a distinct operational fact, with the purpose front-loaded. It could be slightly tightened by combining the two credential-related sentences, but there is no filler.

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

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

The description covers purpose, output boundaries, timeout, authentication constraints, and fallback routing. It lacks explicit failure/timeout behavior and return format, but for a simple tail-file tool this is an adequate and practical level of detail.

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 only 33%, so the description must compensate. It adds that the path refers to a remote log file and that the behavior is tail-like, but the exact meaning of the `lines` parameter is still left mostly to the schema and parameter name.

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

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

Description states a specific verb ('Read'), a specific resource ('remote log file'), and tail semantics ('last lines'). This cleanly distinguishes it from ssh_read_file (full file) and ssh_list_servers (alias discovery).

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 says to use ssh_list_servers when the user has not supplied an exact configured alias, and gives clear credentials guidance. It does not explicitly contrast with ssh_read_file for full-file reads, leaving a small when-not gap.

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 and destructiveHint=true, but the description adds critical behavioral details beyond them: 'replacement is atomic and backed up by default' discloses the write semantics and safety net, and 'SSH credentials are private server-side configuration' clarifies authentication constraints. This significantly enhances the agent's understanding of side effects without contradicting 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 sentences long, with the core purpose in the first sentence and usage constraints in the second. It wastes no words, front-loads the action, and integrates all essential guidance without redundancy. Every clause contributes to effective tool selection or 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 file-upload tool with 5 parameters and no output schema, the description covers the key operational aspects: absolute local path, atomic replacement, backup behavior, credential privacy, and the alias resolution via ssh_list_servers. It also aligns with the destructive annotation, preparing the agent for overwrites. Given the moderate complexity and presence of annotations covering read-only/destructive flags, this is sufficiently 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 only 40% (server and timeout have descriptions; localPath, remotePath, createBackup do not). The description compensates by clarifying that localPath must be absolute, and by mentioning atomic replacement and backup defaults that relate to createBackup and remotePath behavior. While remotePath semantics aren't explicitly detailed, the description's context plus intuitive naming cover most gaps. It adds meaningful info beyond the schema for the undocumented parameters.

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

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

The description clearly states the action ('Upload a local file to the selected remote server through SFTP'), specifies the resource types (local file, remote server), and distinguishes it from siblings like ssh_download_file and ssh_write_file by naming the SFTP transport and the upload direction. It also adds specifics (absolute path, atomic replacement, backup) that reinforce the 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?

The description gives explicit usage guidance: it instructs to never ask the user for a password, and it directs the agent to use ssh_list_servers when an exact configured alias hasn't been supplied. This clearly delineates when to use this tool versus the listed sibling. It also implies the prerequisite of an exact alias, providing a decision rule.

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 mark destructiveHint=true, but the description adds behavioral details: backups by default, refusal to replace symlinks, and credential handling (private server-side config, never ask password). These go beyond annotations, so the agent understands safety and edge cases.

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 sentences with no filler, each adding distinct information. The main action is first, followed by safety and usage notes. Efficient and well-organized.

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

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

For a 4-parameter tool with no output schema, the description covers the core behavior, backup, symlink handling, and credential rules, plus routing to ssh_list_servers. It could mention return value or error behavior, but given the tool's simplicity, it's fairly 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 only 25%, with server having a description. The description adds context that content is UTF-8 text and mentions backup default and symlink refusal, which inform path and createBackup semantics. However, it doesn't explicitly define path requirements or content format beyond UTF-8, so it partially compensates but not fully.

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

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

The description clearly states the action: writing UTF-8 text via SFTP to a selected server, with specifics like atomic rename and backup. It distinguishes from siblings like ssh_upload_file (likely binary) and ssh_exec (commands) by focusing on text content and SFTP write 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?

The description explicitly instructs to use ssh_list_servers when the user hasn't provided an exact alias, and warns never to ask for a password. It does not explicitly exclude other file operations, but the alias condition and password rule give clear context for when to use this tool.

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