ftp-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation2/5
Several tools have overlapping purposes, notably ftp_move vs ftp_rename, ftp_sync vs ftp_mirror, and ftp_exists vs ftp_stat. While descriptions clarify some differences, the boundaries between move/rename and sync/mirror remain ambiguous enough to cause misselection.
Naming Consistency4/5
The vast majority of tools follow a consistent ftp_<verb>_<noun> snake_case pattern, such as ftp_add_site, ftp_upload_directory, and ftp_list_connections. Minor deviations like ftp_pwd, ftp_cd, ftp_tree, and ftp_connection_info break the verb_noun convention, but the overall pattern is predictable.
Tool Count2/5
With 36 tools, the server is over-scoped for an FTP MCP. Many functions overlap, and the count exceeds the 25+ threshold where the tool set becomes heavy and harder to navigate, even though FTP supports a wide range of operations.
Completeness4/5
The tool surface covers the core FTP lifecycle well: connection management, site profiles, navigation, file/directory CRUD, uploads/downloads, sync, permissions, search, and integrity checks. A notable gap is the lack of a recursive directory delete operation, which would require manual traversal with list/delete.
Average 3.3/5 across 36 of 36 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only states the basic function. It does not disclose behavior around duplicate names, validation, persistence, or potential errors, leaving the agent to guess about side effects of this mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It is concise and to the point, making every word earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters and no output schema or annotations, so the description needed to provide richer context. It does not explain return values, failure conditions, or prerequisites, making it inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: each of the 9 parameters has a description, so the schema fully documents the parameters. The description adds no extra parameter semantics, achieving the baseline for complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Save') and resource ('a connection profile'), and implies it adds a new profile to the site manager. It distinguishes from siblings like ftp_edit_site and ftp_remove_site, though it does not explicitly say 'create' or mention alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as ftp_edit_site or ftp_connect. The only usage signal is the tool name itself, 'add_site', which implies creating a profile, but the description does not elaborate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'change' (implying mutation) and covers files/directories, but does not disclose side effects, reversibility, permission requirements, or recursive behavior. The schema's 'recursive' parameter is not referenced in the description, leaving a transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, fully front-loaded with the action and target, and contains no filler or redundancy. It earns its place and is appropriately sized for a simple permission-changing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a mutation with no annotations or output schema, the description is too minimal. It doesn't mention the required connection, the effect on existing permissions, or any return behavior. The schema covers parameters, but the description lacks sufficient usage context for an agent to confidently invoke the tool in real scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 four parameters. The description adds the example '755, 644' which is already in the mode parameter's schema description, thus providing no additional value beyond the structured schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Change') and the target ('file or directory permissions'), with concrete examples ('755, 644'). However, it doesn't explicitly distinguish from sibling tools like ftp_chown or ftp_stat, though the focus on permissions makes the purpose fairly unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, no exclusions, and no prerequisites. It simply restates the basic function; the agent must infer usage context from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description carries full responsibility for behavioral disclosure. It does not state whether the operation is read-only, what kind of differences are reported, how output is structured, or whether it follows recursion (though recursion is implied by the schema default). This lack of detail is a notable gap for a tool that likely traverses directories.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It succinctly conveys the tool's core purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and annotations, the description should provide more context about what the agent can expect from the tool. It does not explain the return format, whether results are a list of differences, a diff summary, or a status code. For a comparison tool, this is a significant omission that leaves the agent unsure of how to interpret results or handle them downstream.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 4 parameters with descriptions, achieving 100% coverage, so the baseline is 3. The description adds little beyond the schema; it mentions 'local and remote directories' but does not elaborate on 'recursive' or 'connection' semantics. Since the schema already describes each parameter, the description does not need to repeat them, but it also does not enrich them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Compare local and remote directories to find differences' clearly states the action (compare) and the resources (local and remote directories), with the intended outcome (find differences). It is specific enough to distinguish from most siblings, though it does not explicitly contrast with ftp_sync or ftp_mirror, which also involve comparison but add modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool instead of alternatives like ftp_sync, ftp_mirror, or ftp_list. It does not mention any prerequisites, use cases, or exclusions, leaving the agent to infer when a compare is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool gets info, but does not disclose whether it requires an active connection, what happens if the connection name is invalid, or what fields are returned. The read-only nature is implied by 'Get' but not explicitly confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler content. It effectively conveys the core action and target, earning a high score for conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain what 'detailed info' includes. It does not, leaving the agent uncertain about the return value. The simplicity of the single-parameter input does not compensate for this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter 'name' as the connection name, achieving 100% schema description coverage. The tool description adds no additional parameter semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get detailed info about a specific connection' clearly identifies a get operation targeting a specific connection, differentiating it from sibling tools like ftp_list_connections. However, it does not specify what 'detailed info' includes, leaving some ambiguity about the tool's exact purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives such as ftp_list_connections, nor does it state prerequisites like having an active connection. The context is implied from the tool name and schema but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the core operation. It does not disclose potential cost of recursive scans, behavior on missing paths, or whether an existing connection is required, leaving important behavioral context undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, directly and efficiently stating the tool's function. It is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description omits return format (e.g., bytes vs human-readable) and prerequisites (e.g., requires an existing connection). While the core purpose is clear, operational details are left ambiguous, making it less complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides clear descriptions for both parameters (path as remote directory, connection as connection name) with 100% coverage. The description adds the recursive behavior but no new parameter-level insights, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates the total size of a remote directory recursively, providing a specific verb and resource. It distinguishes from siblings like ftp_stat by focusing on recursive directory size, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as ftp_stat or ftp_tree. The recursive scope implies whole-directory sizing, but there is no explicit when/when-not or alternative recommendation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure. It only states the basic operation but does not mention side effects, error conditions, whether it can overwrite existing paths, or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the main action and resource. It contains no redundant information and is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description is minimal. There is no output schema or annotations to supplement it, and it omits important contextual details such as whether oldPath/newPath are relative to the current directory, how conflicts are handled, or any side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for all three parameters (newPath, oldPath, connection), covering 100% of the schema. The tool description adds no additional parameter semantics, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Rename') and the resource ('remote file or directory'), making the tool's purpose obvious. However, it does not explicitly distinguish this from sibling tools like ftp_move, which could also involve renaming in a broader sense.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., ftp_move, ftp_copy). The description lacks any conditions, prerequisites, or context for when renaming is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the core action and does not disclose important behavioral traits such as failure on non-empty directories unless recursive is set, irreversibility of removal, or permission requirements. Since there are no annotations, the description carries the full burden but lacks these details for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant content. It is appropriately concise for a simple tool and every word contributes to the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the schema covering parameters, the description lacks essential context for a destructive tool: no mention of recursive behavior, what happens to contents, whether it prompts for confirmation, or return values. The absence of a warning about non-empty directories is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for all three parameters (path, recursive, connection), so the schema already handles parameter semantics. The description adds no extra context about how parameters affect behavior, matching the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a remote directory' clearly states the action (remove) and the resource (remote directory), which is specific. It does not explicitly distinguish itself from sibling tools like ftp_delete, but the directory focus differentiates it enough from file-oriented tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as ftp_delete or ftp_mkdir. It does not mention the recursive parameter or when to set it, so the description offers no context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing effects, but it only says 'write content' without stating whether it overwrites existing files, creates missing directories, or what response is returned. This is a significant gap for a mutation tool, especially given that ftp_append exists for appending, so the overwrite behavior is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core operation without unnecessary words. It is appropriately concise and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool has a simple interface with only three well-documented parameters, the lack of annotations and output schema means the description should clarify the operation's effect (e.g., overwrite vs. append) and the expected return value. The current text is insufficient for the agent to fully understand the behavior, especially with sibling tools like ftp_append.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters with 100% coverage, so the description adds limited value. The phrase 'content directly' hints that content is a raw string rather than a file path, which is a minor supplement, but otherwise the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('write content') and the resource ('remote file'), which identifies the core purpose. However, it does not explicitly distinguish from sibling tools like ftp_append (which also writes content but appends) or ftp_upload (which transfers a local file), leaving some ambiguity about overwrite semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use ftp_write versus alternatives such as ftp_append or ftp_upload. It neither states the intended use case (e.g., writing raw string content) nor excludes other tools, so the agent must infer the appropriate choice from the sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the basic action but does not disclose that changing the directory affects subsequent operations, requires an active connection, or may fail on invalid paths. This is a minimal, bare-bones statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no extraneous words. It conveys the essential purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that changes state (the remote working directory), the description is incomplete. It does not mention that the change persists for subsequent operations, nor does it explain the need for an established connection. Given the low richness of annotations and absence of an output schema, this brief description leaves important context gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'path' and 'connection' described. The tool description adds no new information about parameters, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Change') and resource ('remote working directory'), clearly distinguishing it from sibling tools like ftp_pwd (which prints the working directory) and ftp_list (which lists contents).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as when a user needs to navigate before performing file operations. There is no mention of prerequisites like an active connection or the effect on subsequent commands.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the destructive behavior of deletion via 'with delete', which is critical. However, it does not mention irreversibility, permission requirements, or potential side effects, so the disclosure is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the key action. It is efficient but may be too terse for a tool of this complexity; however, it earns points for clarity and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with no output schema and no annotations, the description is under-specified. It omits usage guidance, warnings about irreversible deletion, and explanation of the important dryRun parameter in the context of a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the schema already provides the necessary semantics. The description adds no additional parameter meaning, fitting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a mirror operation with a specific verb ('Mirror') and resource ('remote directory to local or vice versa'), and distinguishes itself with 'one-way sync with delete'. It is clear but does not explicitly differentiate from the sibling tool 'ftp_sync'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 ftp_sync, ftp_upload_directory, or ftp_download_directory. The description implies usage for one-way syncing but lacks explicit exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It does not mention the potentially destructive deleteExtra behavior, dry-run capability, or any side effects, leaving the agent unaware of risks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is front-loaded with the verb and resource. The analogy adds clarity without unnecessary length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema richly documents all parameters, but the description lacks critical behavioral context (e.g., safety, dry-run, deletion implications) for a complex sync operation. It is minimally complete but leaves gaps for an agent evaluating tool safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for all six parameters, so the description does not need to add parameter details. It offers no additional meaning beyond the schema, earning the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool synchronizes local and remote directories, using a familiar analogy to FileZilla synchronized browsing. It conveys the core purpose but does not explicitly differentiate from similar sibling tools like ftp_mirror.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The FileZilla analogy hints at a use case, but there is no explicit when-to-use or exclusionary context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral aspects. It only states the action without mentioning what the tool returns (e.g., boolean), how errors are handled (e.g., connection failures), or any side effects. This lack of information is a significant gap for a tool that lacks 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It efficiently conveys the core purpose without any unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description is minimal but incomplete. It lacks critical context such as the return value format (e.g., true/false), error behavior, and any prerequisites like needing an active connection. Since there is no output schema, this information is essential for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning both 'path' and 'connection' are already documented in the schema. The description adds no additional parameter semantics 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Check') and resource ('remote path'). It is unambiguous and distinguishes from siblings like ftp_list or ftp_stat, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives such as ftp_stat or ftp_list. There is no mention of exclusions or prerequisite conditions, leaving the agent to infer usage solely from the tool's name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only restates the action 'Delete' without addressing permanence, permission requirements, or failure behavior. For a destructive operation, more context is needed to set user expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundant content. It is front-loaded and efficient, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with fully documented parameters, the description is minimally adequate. However, it lacks any mention of destructive implications or distinction from directory deletion, making it somewhat incomplete relative to the operation's risk and sibling tool context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% for both parameters (path and connection), each with clear descriptions. The tool description adds no additional semantic meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a remote file' uses a specific verb and resource, clearly distinguishing it from sibling tools like ftp_rmdir (delete directory) and ftp_remove_site (remove site). The intent is unambiguous and directly maps to the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool versus alternatives such as ftp_rmdir for directories or ftp_remove_site. The description merely states the action without mentioning exclusions, preconditions, or recommended contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the basic action without disclosing behavior like overwrite rules, directory creation, resume support, or what happens if the local path exists. This lacks the necessary detail for an agent to anticipate side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and the key objects. There is zero wasted text, making it appropriately concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters, all documented in the schema, and a straightforward operation. However, because there is no output schema and no additional behavior description, the agent may be missing information about return values, error conditions, or edge cases (e.g., existing files). It is minimally sufficient but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter semantics beyond what the schema already provides—it merely restates the action. The agent can rely on the schema, but no extra value is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'download' with a resource ('remote file') and destination ('local path'), clearly distinguishing it from sibling tools like ftp_upload and ftp_download_directory. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, such as 'for directories use ftp_download_directory,' nor any prerequisites or context where this tool would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds meaningful context by indicating a partial update ('specific fields') and that it operates on an existing saved site profile, but it omits details about reversibility, permissions, and error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words, and it front-loads the core action and target. It is efficient, though it could be slightly more informative without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, no annotations, and no output schema, this one-line description is insufficient. It does not clarify the return value, error conditions, or whether the site must already exist, leaving the agent without essential context for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The phrase 'specific fields' conveys that only provided parameters are updated, a key semantic not present in the schema. However, with only 11% schema description coverage and no parameter names listed, it doesn't compensate for the low coverage across 9 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'saved site profile', and specifies 'specific fields', indicating a partial modification. This distinguishes it from sibling tools like ftp_add_site and ftp_remove_site.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives, nor are prerequisites or exclusions mentioned. Usage is only vaguely implied by the verb 'Update', with no reference to sibling tools like ftp_add_site or ftp_connect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral transparency. It only states the basic operation ('Create a remote directory') and does not disclose behavior such as whether existing directories cause an error, whether permissions are required, or whether the recursive parameter is the only way to create parent directories. This leaves the agent to guess about side effects and error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It is appropriately sized for a simple tool and front-loads the core action. Every word earns its place, and the structure is clear and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is rich (100% parameter coverage) and the tool is relatively simple, so the description need not explain return values or all parameter details. However, it lacks contextual completeness regarding when to use the tool and potential side effects, which are not covered by the schema. Given no annotations and no output schema, the description is minimally adequate but leaves gaps in behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: each parameter (path, recursive, connection) has a description. The tool description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate. The recursive parameter's semantics ('Create parent directories if needed') are already captured in the schema, and the description does not reinforce or enrich this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a remote directory' uses a specific verb ('create') and resource ('remote directory'), making the tool's function immediately clear. It distinguishes from sibling tools like ftp_rmdir (remove) and ftp_upload_directory (upload contents), which also interact with directories but for different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as ftp_upload_directory (which may implicitly create directories) or ftp_mkdir's recursive option. There is no mention of prerequisites (e.g., needing an active connection) or exclusions. The agent must infer usage from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description offers only the basic operation without detailing side effects. It does not disclose whether the destination path will be overwritten, if directories are supported, or what happens to the source file, leaving the agent to infer behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words. It effectively communicates the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple move operation, the description is insufficiently detailed. It does not explain important behaviors such as overwrite handling, directory support, or success/failure reporting, which are critical for an agent invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides clear descriptions for all three parameters (connection, sourcePath, destPath), covering 100% of parameter semantics. The description adds no additional parameter information, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: moving a remote file to a new location. This verb-resource structure distinguishes it from sibling tools like ftp_copy (which duplicates) and ftp_delete (which removes), though it doesn't explicitly differentiate from ftp_rename.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention scenarios where move is preferred over copy or rename, nor any prerequisites for using the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool reads text contents but does not disclose return format, error behavior on missing files or binary data, maxSize enforcement, or whether it is safe/non-mutating. This is a significant gap for a tool with no structured annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundancy. It is appropriately minimal for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with full schema coverage, the description is mostly adequate, but it does not specify return value expectations or distinguish text-file reading from ftp_download for binary files. Given no output schema or annotations, this leaves modest ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds no additional parameter semantics beyond the schema, but no compensation is needed due to the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and resource ('remote text file'), clearly identifying the operation. It distinguishes from the sibling 'ftp_download' by limiting to text file contents, though it does not explicitly contrast it with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for reading remote text files, which gives reasonable context for selection. However, it provides no explicit when-to-use guidance or contrast with closely related siblings like ftp_download, ftp_grep, or ftp_stat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It indicates a mutating operation but doesn't disclose overwrite behavior, directory creation, error handling, or required connection state. The simple 'upload' statement lacks 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single clear sentence, front-loads the action and resource, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple upload operation, the description states the essential purpose, but with no output schema or annotations, it fails to clarify return values, side effects, or usage context among the many sibling FTP tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description covers 100% of parameters, so baseline is 3. The description adds no additional meaning beyond what the schema already provides for localPath, remotePath, connection, and mode.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly uses the verb 'Upload' and specifies the resource ('local file') and destination ('remote server'), making it distinct from sibling tools like ftp_upload_directory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., active connection) or exclusions (e.g., use ftp_upload_directory for folders).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only states the intended action and omits important details such as whether this is a read-only operation, whether an existing connection is required, or any potential side effects. This is a significant gap for a network operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states the action and purpose. It is front-loaded with the verb and resource, contains no unnecessary words, and every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a well-documented schema, the description lacks essential context for a tool with no output schema and no annotations. It does not specify the return format of the checksum, any dependencies (like connection state), or the default algorithm. This makes the description incomplete for understanding the full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema fully documents all parameters (path, algorithm, connection) with descriptions. The description adds no additional parameter semantics, leaving the schema to carry the burden. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Calculate checksum') and the resource ('remote file'), with a clear purpose ('for integrity verification'). It uniquely identifies the tool among siblings, none of which perform checksum calculation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for integrity verification' provides a clear context for use, but the description does not explicitly mention when to use this tool versus alternatives, nor does it state any exclusions or prerequisites. Given the large set of sibling FTP tools, more explicit guidance would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It simply says 'Connect' without explaining that this creates a named session, that subsequent FTP operations depend on this connection, that the connection should later be closed with ftp_disconnect, or what the return value looks like. For a stateful operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no filler. It is appropriately concise for a connection tool, stating the action and the two input modes without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters, no annotations, and no output schema, the description is underspecified. It fails to explain the session management model, the role of the 'name' parameter as a session identifier, or how this tool relates to the rest of the FTP command set. A more complete description would mention that a successful connection establishes a named session for subsequent operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with every parameter having a description. The tool description adds a high-level distinction between using credentials and using a saved site name, but it does not delve into parameter syntax or precedence beyond what the schema already provides. This aligns with the baseline 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Connect to an FTP/FTPS/SFTP server using credentials or a saved site name.' It uses a specific verb and resource, and it distinguishes itself from sibling tools that perform file operations or site management. The two connection methods (credentials or saved site) add useful precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is the initial step for establishing a connection, but it does not explicitly state when to use it vs alternatives, nor does it mention prerequisites like needing a pre-existing saved site or checking existing connections via ftp_connection_info. The usage context is only implied by the tool's name and sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It only discloses the recursive nature, but omits significant behaviors such as the default overwrite= true, whether local directories are created, or what happens on failure. The parameter 'overwrite' implies overwriting, but the description does not acknowledge it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a clear verb and object, front-loading the action and scope. No waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not mention return values, edge cases (e.g., non-existent remote path), or local path creation behavior. For a tool with 4 parameters and no output schema, the description is too minimal to fully inform an agent of expected outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% parameter description coverage, so the baseline is 3. The description adds marginal value by indicating that remotePath is a directory and that the operation is recursive, but it does not provide per-parameter details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Download an entire remote directory to a local path recursively'. It clearly distinguishes from siblings like ftp_download (single file) and ftp_upload_directory (reverse operation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (recursive full-directory download) but does not explicitly state when to use this over alternatives like ftp_download or ftp_sync. No exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only reveals that files are downloaded and searched, leaving unknown the return format, recursion behavior, handling of binary files, performance implications, and error conditions. This is insufficient for confident invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words. It front-loads the key action ('Search') and resource, making it appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema, no annotations), the description is too sparse. It fails to specify return values, search behavior on directories, or performance impacts, and relies entirely on schema for operational details, which is insufficient for a search tool that downloads files.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters have descriptions in the schema (100% coverage), so the baseline is 3. The tool description adds no additional parameter semantics beyond the schema, such as pattern syntax or how maxDepth/maxFiles interact, but the schema already provides adequate parameter-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search for text content within remote files' with a specific verb and resource. The parenthetical '(downloads and searches each file)' adds operational clarity, distinguishing it from file listing or reading tools like ftp_list and ftp_read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a content-search use case but does not explicitly state when to prefer this over siblings like ftp_find (filename search) or ftp_list. There is no mention of exclusions or alternative guidance, leaving usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It accurately indicates this is a read operation and specifies the returned attributes (size, modified date, permissions, type). However, it does not disclose behavior for missing paths, whether it follows symlinks, or any potential side effects, though for a stat-like operation these are minimal expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose and output. Every word earns its place, with no fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple metadata retrieval tool, the description is sufficient. It lists the key output fields and explicitly covers both files and directories. While there is no output schema, the described attributes give the agent a clear idea of what to expect. A slightly more detailed note on return format would be ideal, but the current description is substantively complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%—both parameters ('path' and 'connection') have descriptive text. The description adds no additional meaning about parameter formats or constraints beyond what the schema already 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets file or directory info, specifying the attributes (size, modified date, permissions, type). This is a specific verb+resource combination that distinguishes it from sibling tools like ftp_list (which lists entries) or ftp_exists (which checks existence), though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description implies it is for retrieving metadata, but it does not mention any exclusions, prerequisites, or comparisons to similar tools like ftp_dir_size or ftp_list. An agent would have to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only discloses that the operation is recursive. It does not mention overwrite behavior, directory creation, permissions, or side effects on existing remote files, which are important 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes meaning, and it is appropriately concise for the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool performs a complex recursive operation, but the description lacks important context: no success/failure behavior, no mention of overwrite semantics, no preconditions, and no explanation of how remote directories are handled. This is insufficient for an agent to reliably predict the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented. The description adds no extra parameter-level meaning beyond the overall directory-scope intent, matching the baseline for fully covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: uploading an entire local directory to a remote server recursively. This distinguishes it from sibling tools like ftp_upload (single file) and ftp_sync/ftp_mirror by emphasizing the recursive whole-directory scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for recursive directory uploads but does not explicitly say when to prefer it over alternatives such as ftp_upload, ftp_sync, or ftp_mirror, nor does it mention exclusions like single-file uploads.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the listing includes permissions, size, date, and type, which is useful. However, it doesn't address edge cases like error handling, sorting, or behavior with missing paths, so transparency is average.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core action and key output details without unnecessary words. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with a fully documented schema, the description is minimally viable. It doesn't explain the return format or when to use it, but the schema and sibling context make the tool usable. It could benefit from a note about default path behavior or hidden files, but the current description is not inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any semantics beyond the schema; it only hints at output details. Since all parameters are already described in the schema, no additional compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('directory contents') with explicit detail fields (permissions, size, date, type). It clearly distinguishes from sibling tools like ftp_tree or ftp_stat by focusing on directory listing with structured details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or any context that would help an agent choose between ftp_list and similar tools like ftp_tree, ftp_stat, or ftp_exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'List all active connections with status' and does not clarify whether the operation is read-only, how connections are identified, what happens with no active connections, or any side effects. This minimal disclosure is insufficient for a tool with zero annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that captures the core purpose without unnecessary words. It is appropriately sized for a simple list operation with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 explain return values. It mentions 'status' but does not specify what fields or format the agent should expect, nor does it clarify the scope (e.g., all sessions vs. current session). This is adequate but leaves notable gaps for such a minimal tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is 100%. Per the rubric, a baseline of 4 is appropriate because there are no parameter semantics to clarify, and the description correctly avoids inventing details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all active connections with status' uses a specific verb ('List') and clearly identifies the resource ('active connections') with an additional output detail ('status'). It distinguishes from sibling tools like ftp_connect and ftp_disconnect (actions) and ftp_connection_info (likely singular connection detail).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as ftp_connection_info. It does not mention any prerequisites, exclusions, or context, leaving the agent to infer the appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full responsibility for disclosing behavioral traits. It only states the action 'Remove' without mentioning irreversibility, side effects on active connections, or required permissions. For a destructive operation, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the key verb and resource. Every word is necessary and there is no redundancy or filler, making it appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema) and full schema coverage, the description covers the basic action. However, as a mutating operation with no annotations, it lacks details about consequences (e.g., permanent removal, no effect on active connections) that would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'name' parameter, which is already described as 'Site name to remove'. The tool description adds no additional meaning beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Remove' and clearly identifies the resource as 'a saved site from the site manager'. This distinguishes it from sibling tools like ftp_add_site, ftp_edit_site, and ftp_list_sites, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use when you want to remove a saved site from the site manager. However, it does not explicitly state when NOT to use it or mention alternatives (e.g., ftp_edit_site for modifying a site). No prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It discloses that the listing is recursive and has a depth limit, but does not mention other relevant behaviors like hidden files, sorting, or error handling. This is adequate but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the purpose and a key parameter (depth limit). It is front-loaded with the core action and contains no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the fully descriptive schema, and the straightforward read-only nature implied by 'list', the description is complete enough for an agent to understand the tool's function. The absence of an output schema is compensated by the obvious return of a tree structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema description covers 100% of the parameters, so the baseline is 3. The description does not add extra meaning beyond what the schema already provides, such as parameter syntax or format details, so it neither improves nor degrades the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Recursively list directory tree structure with depth limit' uses a specific verb and resource, clearly distinguishing it from sibling tools like ftp_list (a flat listing) and ftp_find (a search). It also conveys key scope constraints (recursiveness and depth).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as ftp_list or ftp_find. It implies usage for recursive tree listing, but lacks explicit context, exclusions, or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the key precondition that the file must exist, but does not state what happens if the file is missing, permission requirements, or whether a newline is added. Minimal behavioral disclosure beyond the core action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single declarative sentence of 8 words. It is front-loaded with the verb 'append' and directly states the object. No filler, redundant info, or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity and fully documented schema, the description is minimally viable but thin. It does not describe error scenarios or help differentiate from similar write tools (e.g., ftp_write). The 'existing' qualifier adds some context, but overall it lacks depth for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all parameters (path, content, connection). The tool description adds no extra parameter context, so the baseline of 3 applies per the rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Append') and the resource ('content to an existing remote file'). This distinguishes it from siblings like ftp_write (overwrite) and ftp_upload (transfer local file). The qualifier 'existing' adds an important scope condition, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit alternatives or when-not-to-use guidance is provided. The description implies a use case (adding content to a file that already exists) but does not contrast with ftp_write or mention prerequisites beyond the file's existence. The context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It states the core behavior but does not disclose side effects, error behavior if the connection doesn't exist, or whether the operation is idempotent. It is adequate for a simple disconnect but lacks deeper 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. Every word adds meaning, and it is appropriately sized for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required param, no nested objects, no output schema), the description is mostly sufficient for an agent to invoke it correctly. However, it doesn't clarify return behavior or failure conditions, which would be useful given the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the 'name' parameter with 100% coverage as 'Connection name to disconnect.' The description adds no additional meaning to the parameter beyond what is in the schema, so it remains at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Disconnect' with a resource ('a named connection'), clearly conveying the tool's action. It distinguishes itself from siblings like ftp_connect and ftp_list_connections by focusing on the teardown operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool vs alternatives, such as noting it should be called after ftp_connect or only on established connections. The usage is implied from the verb, but no context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It mentions 'recursively' and 'remote server', which are useful, but it does not explicitly state that this is a read-only, non-destructive operation or explain behaviors like result limits or path handling. The term 'search' implies safety, but it is not fully explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the main verb and resource, and it contains no filler or redundant information. It is maximally concise while conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the tool returns, but it does not (e.g., whether results are paths, whether directories are included by default). The moderate complexity (6 params, no output schema) leaves gaps in understanding the complete behavior, although the purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and every parameter has a description, including pattern, path, type, maxDepth, and maxResults. The tool description adds no parameter-specific meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (search), the resource (files), and the specific scope (by name pattern with glob, recursively on the remote server). This distinguishes it from siblings like ftp_list and ftp_grep by emphasizing name-based recursive matching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need to find files by name pattern recursively), but it does not explicitly mention alternatives or exclusions (e.g., 'for content search, use ftp_grep'). Guidance is implied rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only operation and states the output is a list of saved profiles. However, it does not disclose details such as whether the list includes full connection credentials, whether authentication is required, or if there are any side effects. This is minimal but adequate for a simple 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately communicates the purpose. Every word earns its place, with no filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should explain what the returned list contains (e.g., names only, full host/port details). It only says 'list all saved connection profiles,' which is somewhat incomplete for an agent that needs to use the results. The simplicity of the tool balances this, but more return-format detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the schema is empty, so there is no parameter information to provide. Per the guidelines, zero-parameter tools receive a baseline of 4. The description correctly adds no extraneous parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('List') and resource ('all saved connection profiles'). It distinguishes itself from siblings like ftp_list_connections (which likely lists active connections) and ftp_list (which lists files in a directory) by specifying 'saved connection profiles'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 ftp_list_connections or ftp_connection_info. The description provides no context, prerequisites, or exclusions, leaving the agent to infer the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only states the action and scope, but does not mention potential side effects, required privileges, or that the operation is a destructive write. This is minimal 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the essential purpose and scope without any wasted words. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema fully documents parameters, and the description adds the important SFTP-only constraint, the tool is adequately contextualized. The lack of an output schema is not a significant gap for a simple mutation operation, and no additional context seems necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all 4 parameters with 100% coverage, and the description adds no additional parameter context. Per the rubric, high schema coverage yields a baseline of 3, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Change file ownership' which is specific and distinguishes from sibling tools like ftp_chmod (permissions) and other file operations. The addition of '(SFTP only)' further scopes the tool, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear contextual constraint ('SFTP only') that tells the agent this tool should not be used for FTP connections. While it doesn't explicitly name alternatives like ftp_chmod for permissions, the scope is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the burden of disclosing behavior. It reveals a key trait: the copy is performed by downloading then re-uploading, indicating it is not a server-side copy and involves local bandwidth. However, it does not disclose whether an existing destination file is overwritten or other side effects, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and adds crucial mechanism context in a parenthetical. There is no fluff or redundancy; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with three well-documented parameters, the description provides sufficient context: the purpose and the download/re-upload mechanism. It lacks explicit mention of overwrite behavior and return values, but given the low complexity and no output schema, the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents all three parameters (connection, sourcePath, destPath) with clear descriptions, and coverage is 100%. The tool description adds no additional parameter semantics 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Copy' and resource 'a remote file', and the parenthetical '(downloads then re-uploads to new location)' distinguishes it from server-side copy operations and from siblings like ftp_move or ftp_rename. This is a specific and unambiguous action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for copying a remote file to another remote location, but it does not explicitly mention when to use it instead of alternatives like ftp_move (if you want to move) or ftp_download/ftp_upload (for local transfers). No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It accurately describes the operation as printing the current directory, implying a non-destructive read, but does not disclose prerequisite conditions such as an active connection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. Every word contributes to explaining the tool's function, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple pwd tool with one required parameter and no output schema, the description is sufficient and complete. It could mention the return format, but 'print' reasonably implies that the path is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully covers the only parameter ('connection') with a 'Connection name' description, achieving 100% coverage. The tool description adds no additional meaning beyond what the schema already provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Print') and clearly identifies the resource ('current working directory on the remote server'). It distinguishes from sibling tools like ftp_cd (change directory) and ftp_list, making its function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied: use when you need to know the remote working directory. No explicit alternatives or exclusions are mentioned, but the tool's niche is self-evident, so the absence of explicit guidance is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ftp-mcp MCP server](https://glama.ai/mcp/servers/kemalabuteliyte/ftp-mcp/badges/card.svg)](https://glama.ai/mcp/servers/kemalabuteliyte/ftp-mcp)

Score Badge

Copy to your README.md:

[![ftp-mcp MCP server](https://glama.ai/mcp/servers/kemalabuteliyte/ftp-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kemalabuteliyte/ftp-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kemalabuteliyte/ftp-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server