mcp-ftp-server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct FTP operation, from connection management (connect/disconnect/status) to file operations (download/upload/read/write/delete) and directory operations (cd/list/mkdir/rmdir/rename). There is clear separation between similar actions like read (viewing remote text) and download (saving to local filesystem), and between write (writing content to remote) and upload (transferring a local file). No two tools have overlapping purposes.
Naming Consistency5/5
All tools follow a uniform 'ftp_' prefix with a lowercase snake_case verb or command (e.g., ftp_connect, ftp_list, ftp_rename). The naming pattern is predictable and consistent, making it easy to infer functionality from the name.
Tool Count5/5
15 tools is well-scoped for an FTP server, covering connection management, navigation, file transfer, text editing, and directory operations. The count is within the ideal range and each tool earns its place, with no unnecessary or redundant additions.
Completeness5/5
The tool set provides comprehensive lifecycle coverage for FTP operations: connect/disconnect, directory management (pwd, cd, list, mkdir, rmdir), file operations (download, upload, read, write, delete, rename), and meta-operations (size, status). There are no obvious gaps for typical FTP workflows.
Average 3.4/5 across 15 of 15 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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 of behavioral disclosure. It only states the basic direction of transfer but does not disclose whether an existing connection is required, whether local files will be overwritten, or any side effects. This is insufficient 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 names the action and both endpoints. It earns its place without redundancy or unnecessary detail.
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 no annotations and no output schema, this description is too minimal. It does not mention the need for an active FTP connection, behavior on existing local files, or any potential failure modes. The schema covers parameters, but the overall operational context is incomplete.
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 both parameters (remotePath and localPath) with clear descriptions, achieving 100% coverage. The tool description adds no additional parameter details, but since the schema already provides complete definitions, 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 downloads a file from an FTP server to the local filesystem, using a specific verb and resource. It distinguishes from the obvious sibling 'upload' but does not explicitly differentiate from 'read' or other related operations.
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_read' or 'ftp_upload', and no prerequisites like an active FTP connection are mentioned. The usage context is only implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosure. It does not indicate whether writing overwrites existing content, creates the file if missing, or requires specific permissions. This lack of detail is a significant gap 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, concise sentence that immediately communicates the tool's purpose. There is no unnecessary information, and it is well-structured for quick parsing.
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 write operation, the description is minimal but omits critical context such as overwrite behavior, directory creation, or return values. Since there are no annotations and no output schema, the description should provide more to fully inform the agent.
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 params ('remotePath' and 'content') already well described in the input schema. The tool description adds no extra parameter semantics beyond what the schema provides, so 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 (write) and resource (remote file) with a specific object (content). It is unambiguous about the core operation, but it does not differentiate from the sibling tool ftp_upload, which also writes to a remote file (though likely from a local file).
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_upload. The description does not mention use cases, prerequisites, or conditions under which this tool is preferred.
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 full burden. It only states that the tool deletes a file, which is a destructive operation, but does not disclose irreversibility, error behavior, or permission requirements. The description adds little beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential purpose without any wasted words. Every word contributes to understanding the tool's 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?
While the tool is simple (one parameter), the description omits critical context for a destructive operation: no mention of prerequisites, return values, error cases, or behavioral nuances. With no annotations and no output schema, the description leaves significant gaps for an agent to infer safe and correct usage.
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 provides a description for the sole parameter 'path' ('Remote path on the FTP server'), achieving 100% schema_description_coverage. The tool description adds no additional semantic detail beyond labeling the target as a 'file', which is the baseline for high 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 action ('Delete') and the object ('a file on FTP server'), which distinguishes it from the sibling tool ftp_rmdir (used for deleting directories). This is a specific verb+resource combination.
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 like ftp_rmdir or ftp_rename. It does not mention prerequisites (e.g., an active FTP connection) or edge cases (e.g., cannot delete directories).
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 states the action and target, without mentioning that this is a destructive operation, that a non-empty directory requires the 'recursive' flag, or any failure modes. The recursive parameter is completely absent from the description, leaving its effect unclear.
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. It is not verbose and contains no filler, earning its place without unnecessary words.
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 operation is simple, the tool is destructive and has a recursive option with significant side effects. The description omits return values, failure modes, and necessary context like connection requirements. Given no output schema or annotations, the description should provide more detail to be fully useful.
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%: both 'path' and 'recursive' are described in the input schema. The description adds no additional parameter details, so the baseline score of 3 is appropriate when the schema handles the semantics.
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 ('Remove') and the target ('a directory on FTP server'), making it distinct from sibling tools like ftp_delete (presumably for files) and ftp_mkdir (directory creation). The noun 'directory' is specific and 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 prerequisites (e.g., an active FTP connection) or whether the directory must be empty unless recursive is set. No exclusions or alternative recommendations are given.
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 states the action ('Change current directory') without explaining that it affects subsequent FTP commands, whether it requires an authenticated session, or what happens on an invalid path. Minimal behavioral transparency.
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, front-loaded sentence with zero wasted words. It states the exact purpose without elaboration.
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 cd command with one parameter and no output schema, the description is minimally viable. However, it lacks the context that the directory change affects subsequent operations and that a connection must exist. Given the sibling set includes connect/disconnect, this missing context is a clear 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?
Schema description coverage is 100% (the only parameter 'path' has a description: 'Remote path on the FTP server'). The description adds no extra parameter meaning, but the schema already provides sufficient semantics, 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 ('Change') and resource ('current directory') with context ('on FTP server'), clearly distinguishing it from sibling tools like ftp_list or ftp_upload. It precisely states what the tool does.
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, nor are prerequisites mentioned (e.g., requiring an active connection via ftp_connect). The need for a prior connection is implied by the sibling tool list but not 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?
The description only states the basic upload action and does not disclose whether it overwrites existing remote files, requires an active FTP session, or creates remote directories. With no annotations, this leaves important behavioral traits unclear.
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 of ten words with no filler, efficiently stating 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 two-parameter tool, the description covers the basic purpose, but it omits critical context like the need for an existing FTP connection and the tool's behavior relative to sibling ftp_write. This constitutes a clear gap in an otherwise minimal viable description.
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 clear descriptions of localPath and remotePath. The tool description adds no additional parameter context, so it relies entirely on the schema, earning the baseline score of 3.
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 'upload' with a clear source ('local filesystem') and destination ('FTP server'), distinguishing it from sibling tools like ftp_download or ftp_write.
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 about when to use this tool versus alternatives like ftp_write or ftp_put, nor any prerequisites such as establishing a connection via 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?
No annotations are provided, so the description carries full burden of behavioral disclosure. It only states the basic listing action, without mentioning whether it is read-only, whether it follows symbolic links, whether it includes hidden files, or what the output format looks like. This is insufficient for an agent to anticipate side effects or return data.
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 to the purpose, making it highly concise and easy to parse.
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 should explain return values and any side effects. It simply says 'list', but does not specify whether the output is a simple list of names, detailed directory listings, or whether it is recursive. For a tool with minimal schema and no output schema, this is incomplete.
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 parameter 'path' with a description and default value, so schema coverage is 100%. The description's phrase 'in a path' adds no meaningful detail beyond the schema, so it is at the baseline of 3.
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: 'List files and directories in a path on FTP server'. The verb 'list' and resource 'files and directories' are specific, and it distinguishes from sibling tools like ftp_download/upload/read/write which involve file content operations.
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 by stating its core function, but it does not explicitly provide guidance on when to use this tool versus alternatives like ftp_pwd or ftp_cd. There are no exclusions or alternative suggestions, so it only meets the 'implied usage' level.
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 of behavioral disclosure. It only states the purpose and does not disclose important behaviors such as whether it returns the size in bytes, what happens if the file does not exist, how errors are handled, or whether it works for directories. For a read operation, some of this may be assumed, but the lack of any behavioral detail leaves significant 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, concise sentence: 'Get the size of a file on FTP server.' It is front-loaded with the action and contains no unnecessary words. Every word earns its place, making it highly efficient.
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?
This is a simple tool with one parameter and no output schema, but the description fails to explain what the tool returns or how to handle errors. The agent is left without knowing whether the size is in bytes, kilobytes, or a formatted string, and whether it returns an error if the path is invalid. Without annotations or an output schema, this gap makes the description incomplete for reliable 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 has 100% coverage for the single parameter 'path' with a clear description ('Remote path on the FTP server'). The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate. The schema does the heavy lifting for parameter understanding.
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: 'Get the size of a file on FTP server.' It uses a specific verb ('get') and resource ('size of a file'), making it distinct from sibling FTP tools like ftp_list or ftp_download. 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the description: call this tool when you need the size of a specific file on an FTP server. However, there is no explicit guidance on when not to use it or alternatives (e.g., ftp_list might show sizes in directory listings). The simplicity of the operation makes the usage fairly obvious, but it lacks explicit exclusionary or comparative guidance.
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 of behavioral disclosure. It says 'Read the content' which suggests it returns the file content as a string, but it does not mention whether an active FTP connection is required, what happens for large files (could be memory-heavy), whether it returns an error for missing files, or if the entire file is read at once. The only behavioral detail is the 'text files only' limitation.
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 fully conveys the core action and constraint. It is front-loaded with the verb, has no redundant words, and every part earns its place. This is an excellent example of concise, efficient documentation.
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, and the tool is part of an FTP suite. The description is adequate for a simple read operation but does not mention the need for an established connection, the return format, or any size limitations. Given the simplicity, it is not a serious gap, but it would benefit from a brief note about using ftp_download for binary or large 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?
The input schema has 100% description coverage: 'remotePath' is described as 'Remote file path to read' and 'encoding' as 'File encoding (default: utf-8)'. The tool description does not add any extra semantics beyond these. Since the schema fully documents both parameters, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' with the resource 'remote file', and the parenthetical '(text files only)' clearly distinguishes this from ftp_download (which likely saves to a local file) and ftp_list (which lists directory contents). It is immediately clear what the tool does and how it differs from siblings.
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 provides a clear constraint ('text files only') which implies it should not be used for binary files, but it does not explicitly mention when to use this tool over alternatives like ftp_download. There is no explicit 'when to use' or 'when not to use' guidance, only an implied restriction.
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 of behavioral disclosure. It only states what the tool does ('get status') but does not explain what the status entails (e.g., connected/disconnected, error states, latency), nor whether it has side effects or requires authentication. The description is a near-tautology and lacks behavioral depth.
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 words. It is front-loaded and every word earns its place, making it highly efficient.
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 tool with no parameters and no output schema, the description is minimal. While it conveys the basic purpose, it does not explain the return value or possible status values, which would be necessary for an agent to fully understand the output. The description is adequate but leaves a gap in what 'status' means.
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 already fully covers this (100% coverage by vacuity). According to the baseline for 0 params, a score of 4 is appropriate. The description adds no parameter information, but none 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 'Get current FTP connection status' uses a specific verb and resource, clearly indicating that the tool retrieves the status of the FTP connection. It is distinct from sibling tools like ftp_connect, ftp_disconnect, and ftp_list, which perform different actions.
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 gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., 'after connecting') or situations where this status check would be useful, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only disclosed behavior is the fallback to FTP_HOST, FTP_USER, and FTP_PASSWORD environment variables if the tool is not called. It does not describe what happens on success (e.g., whether a global connection is created), what occurs if already connected, error handling, or security implications of using plain FTP vs FTPS. With no annotations, the description carries the full burden but only covers a minor aspect.
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 extremely concise—two short sentences—and immediately conveys the primary action. It contains no filler or redundant information with the schema.
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 connection tool with no output schema, the description omits critical contextual details: what the connection state is, how it affects subsequent sibling tools, whether it opens a persistent connection, what permissions or prerequisites exist (e.g., network access), and what happens if the connection fails. The env var fallback is useful but not sufficient for an agent to use this tool reliably.
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 schema already provides descriptions for all five parameters (100% coverage). The description adds value by explaining that host, user, and password can be overridden by environment variables if the tool is not called, which supplements the parameter meanings beyond the schema's static descriptions.
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 verb and resource: 'Connect to an FTP server.' It is distinct from its siblings, which are all FTP operations that require an established connection. This makes it the obvious connection initializer.
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?
Usage is implied: one should call this before using other FTP tools, and if not called, environment variables will be used. However, there is no explicit 'when to use' or 'when not to use' guidance, nor mention of alternatives like using environment variables directly.
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 behavior. It simply states 'Disconnect' without explaining side effects (e.g., session closure, error if not connected), idempotency, or connection state requirements. This minimal disclosure is a 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, direct sentence that immediately conveys the purpose. There is no wasted text, and the structure is appropriate for such a simple tool.
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 (no parameters, no output schema, low complexity), the description is largely complete. However, it lacks any context about when to call it (e.g., after other FTP operations) which would be helpful for agent orchestration, so it is not a perfect 5.
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 input schema is empty, so there are no parameters to explain. The description adds no parameter information, but this is unnecessary given the schema coverage of 100%. Baseline for 0 parameters is 4.
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 'Disconnect from the FTP server' clearly states the action (disconnect) and the resource (FTP server). It is easily distinguished from sibling tools like ftp_connect, ftp_list, etc., which perform other specific FTP operations.
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 or when not to use it. It does not mention prerequisites (e.g., an active connection) or alternatives (e.g., no sibling for disconnecting). Users must infer usage from 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?
No annotations are provided, so the description carries the full burden. It discloses the core operation but omits behavioral details such as whether the operation overwrites existing files, whether it works across directories, or what happens on failure. A mutation tool with no annotation support requires more explicit disclosure.
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 action and resource. Every word earns its place, with no redundant information.
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 rename/move operation, the description covers the core functionality. However, with no output schema and no annotations, it lacks details about return values, error scenarios, or edge cases (e.g., overwriting), leaving some context incomplete.
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 oldPath and newPath described. The tool description adds no extra meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Rename or move') and the resource ('a file/directory on FTP server'). This distinguishes it from sibling operations like delete, mkdir, and upload, making the tool's 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 implicitly indicates when to use this tool: whenever a path or name change is needed on the FTP server. It does not explicitly name alternatives or exclusions, but the context is clear enough that an agent can 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 exist, so the description bears full responsibility for behavioral disclosure. It only states the operation is to 'Get' a directory but does not disclose whether an active FTP connection is required, what the response format is, or any error/state affects. This is minimal behavioral disclosure.
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?
Single sentence, zero fluff, front-loads the action and object. Every word contributes.
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 trivial zero-parameter read-only query, the description states the core function clearly. It lacks explicit mention of connection prerequisites or return type, but these may be inferred from FTP context and sibling tools; still, a small gap prevents a 5.
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, so schema coverage is trivially 100% and there are no parameter semantics to explain. Baseline 4 for zero-parameter tools 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?
Description uses specific verb 'Get' and resource 'current working directory on FTP server', clearly distinguishing from sibling tools like ftp_cd (change directory) and ftp_list (list files). It precisely states the tool's function with no ambiguity.
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 purpose is self-evident, implying use whenever the agent needs to know the current directory after connecting. However, no explicit guidance is given about when to prefer this over alternatives or what prerequisites (e.g., active connection) are needed.
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 burden of behavioral disclosure. It adds the non-obvious fact that parent directories are created recursively, which is valuable. However, it does not mention behavior when the directory already exists, permission requirements, or success/error feedback.
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 entire description is one efficient sentence, front-loaded with the action and resource. The parenthetical note adds key behavior without padding.
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 mkdir tool with one parameter and no output schema, the description covers purpose and a key behavioral nuance. It is adequate for basic usage, though it could benefit from noting error conditions or return values.
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 provides 100% coverage for the single 'path' parameter, describing it as 'Remote path on the FTP server'. The description adds little beyond implying nested paths are acceptable, 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 action ('Create a directory') and resource ('FTP server'), and includes a distinctive behavior (creates parent directories). This differentiates it from siblings like ftp_rmdir and ftp_upload.
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 intended use is obvious from the description—use this when you need to create a remote directory. It doesn't explicitly name alternatives or exclusions, but the context is clear and no competing mkdir sibling exists.
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:

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

Score Badge

Copy to your README.md:

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

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/rhayalcantara/mcp-ftp-server'

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