Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ftp-mcp sync local dist/ to remote staging with dry run"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An enterprise-grade Model Context Protocol (MCP) server providing sophisticated FTP and SFTP operations optimized specifically for AI coding assistants. Features smart synchronization, connection pooling, directory caching, unified diff patching, and comprehensive security controls.
Your AI can:
spin up a VPS
install a web server
build your entire app
…and then gets stuck trying to upload files.
So it writes a Python script.
Then forgets it exists.
Then writes it again next session.
This fixes that.
One connection. One call. Done.
Built for AI to install. Designed for AI to use.
Related MCP server: mcp-dev-tools
Connection Pooling & Caching: Sustains underlying connections across tool calls and leverages strict memory caching with smart aggressive invalidation for extreme sub-15ms performance.
AI-Optimized Tooling: Implements chunking (startLine/endLine) for huge files, cursor-paginated limit bounds for vast directories, and diff-based local file morphing native to FTP without pulling heavy files.
Security & Authorization: Native support for SSH Key exchanges (both direct and Agent-forwarding), Pass-phrase authentication, and explicit readOnly: true config profiling to sandbox dangerous modifications.
Smart Directory Syncing: Deep hash-and-size sync algorithms for minimal network payload deployments, complete with --dryRun toggling that logs differences back to the LLM without modifying live directories.
Git & Node Aware: Automatically unpacks .gitignore and .ftpignore environments. Semantically evaluates package.json for smart context summarization.
AI-Guided Initialization: A dedicated "AI-First" configuration track (--init) that provides highly verbose instruction context during setup, ensuring AI assistants absorb server capabilities and operational constraints directly into their working memory.
Interactive Initializer: Simple scaffolding of configurations natively via the CLI for human users.
Audit Logging: Robust instrumentation generating structured .ftp-mcp-audit.log traces on all filesystem mutations.
Comprehensive E2E Testing: Guaranteed operational functionality validated continuously by Node-based MCP IO test orchestration.
Run this in your target project directory to scaffold the configuration securely:
npx ftp-mcp --initThis will run an interactive initialization wizard dropping a .ftpconfig instance natively into your working directory. Then install the package globally so your MCP client can access it universally:
npm install -g ftp-mcpOption A: Project Config File (Recommended)
Your .ftpconfig can hold dozens of isolated environments.
{
"production": {
"host": "ftp.example.com",
"user": "prod-user",
"password": "your-password",
"port": 21,
"secure": false,
"readOnly": true
},
"staging": {
"host": "sftp://staging.example.com",
"user": "staging-user",
"privateKey": "./keys/id_rsa",
"passphrase": "my-secure-key",
"port": 22
},
"default": {
"host": "ftp.mysite.com",
"user": "default-user",
"password": "your-password"
}
}The server automatically identifies .ftpconfig relative to your execution layer and falls back to environment properties.
Option B: Environment Variables
Required:
# Windows
setx FTPMCP_HOST "ftp.example.com"
setx FTPMCP_USER "username"
setx FTPMCP_PASSWORD "password"
# Linux/Mac
export FTPMCP_HOST="ftp.example.com"
export FTPMCP_USER="username"
export FTPMCP_PASSWORD="password"Advanced SFTP Keys:
export FTPMCP_PRIVATE_KEY="/path/to/id_rsa"
export FTPMCP_PASSPHRASE="optional-phrase"
export FTPMCP_AGENT="pageant"Register the MCP server directly to your AI Code Editor (Cursor, Cline, Claude Desktop, Windsurf, etc.).
Example integration:
Command: npx
Arguments: -y ftp-mcp
When navigating large remote codebases, AI assistants conventionally hit token-overflow limits. ftp_get_contents supports startLine and endLine parameters. ftp-mcp intercepts the inbound download stream at the bytecode layer and cleanly drops data outside your strict index bounds, returning only the exact lines requested without destroying context.
Instead of requesting a 5,000-line remote file, making a 2-line edit locally, and pushing the huge file back, ftp-mcp exposes an ftp_patch_file command. Simply provide a standard Unified Diff patch string, and ftp-mcp will read the live destination, map diff logic, and commit the modification directly over SCP.
Calling ftp_analyze_workspace will traverse the remote filesystem natively investigating configurations (package.json, composer.json). It will evaluate structure patterns and package dependencies, instantly reporting exact context of the remote language mapping (e.g. "Node.js Environment operating React mapping to Express").
The server provides built-in prompts that guide AI agents through complex workflows:
audit-project: Instructs the agent on how to perform a deep security and architectural audit of a remote codebase.
deploy-checklist: Provides a standard safety checklist for agents to verify before performing production deployments or massive synchronizations.
Access remote files as standard MCP resources without explicitly calling a tool:
URI Template: mcp://remote-file/{path}
Supports direct UTF-8 reading and respects all PolicyEngine security boundaries and path-traversal guards.
Real-time Logging: Emits protocol-native logging notifications for internal events like connection pooling, cache reuse, and transfer lifecycle steps.
Progress Tracking: Long-running operations (ftp_sync, ftp_batch_upload, etc.) emit granular progress updates (0-100%) so the AI agent and user can monitor large transfers in real-time.
Set "readOnly": true in any .ftpconfig profile. AI interactions over ftp_delete, ftp_patch_file, ftp_put_contents, or ftp_sync(direction: "upload") will immediately halt with a standardized sandbox violation, keeping production environments entirely safe from hallucinated tool executions.
Deploy environments utilizing deep comparison trees via ftp_sync.
Use dryRun: true to have the system safely evaluate the entire sync matrix, printing standard output natively to the context console reporting exactly what logic would have executed.
ftp_sync deeply integrates with standard .gitignore indexing and custom .ftpignore pattern files perfectly out-of-the-box.
ftp_connect: Switch between named FTP profiles.
ftp_get_contents: Read file content directly from the server utilizing paginated line extraction.
ftp_put_contents: Write content directly to a remote file.
ftp_patch_file: Apply unified diff modifications cleanly over the network.
ftp_summarize_file: Generates token-light structural signatures representing the files contents natively.
ftp_stat: Get detailed metadata regarding permissions, bytes, and modification arrays.
ftp_exists: Conditional logic pipeline for execution paths without traversing subdirectories.
ftp_disk_space: System OS level free-byte parsing (SFTP ONLY).
ftp_analyze_workspace: Pull complex semantic environments based on workspace root configuration definitions.
ftp_list: List all files/directories subject to limit and offset token bounding rules.
ftp_tree: Build full recursive maps.
ftp_search: Target files by wildcard properties instantly down the document tree.
ftp_mkdir / ftp_rmdir: Folder creation and complex recursive destruction commands.
ftp_upload / ftp_download: Strict file 1-to-1 transports.
ftp_batch_upload / ftp_batch_download: Multi-mapped array uploads avoiding multi-tool overhead.
ftp_sync: Advanced deep-logic size-tree mappings dropping into deployment synchronization pools.
ftp_delete: Drop target properties.
ftp_copy: OS level SSH file duplications ignoring massive TCP IO transport arrays.
ftp_rename: Target displacement mappings.
ftp_chmod: OS level Permission flags executing bit-mask rules natively on SFTP sockets.
Audit Logging is continuously enabled. Ensure the terminal running the MCP protocol maintains structural write-permissions to the local project deployment folder.
Ensure any currentConfig caching resets are tied exclusively to ftp_connect profile pivoting.
See CHANGELOG.md for a detailed list of changes in each release.
Author: Kynlo Akari
Introspect the remote directory to identify technical environments (e.g., Node.js, PHP, Python) and read dependency manifests. Use this to gain architectural context of a new codebase.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Remote directory to analyze (defaults to current server root). | . |
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 describes the tool as introspective and read-only (identify, read), which is sufficient behavioral disclosure. It does not mention any destructive side effects, which aligns with the introspective nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences that are directly informative, with no extraneous words. The verb and purpose are front-loaded, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one optional parameter), the description provides enough context for an AI agent to understand its purpose and when to use it among many sibling tools. The absence of an output schema is acceptable because the description indicates that the result provides architectural context, which is a natural expectation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the only parameter 'path' has a description). The tool description adds minimal additional meaning beyond the schema: it reiterates that the directory is remote and can be defaulted. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Introspect' and clearly states the resource (remote directory) and the actions (identify technical environments, read dependency manifests) with a clear purpose (gain architectural context). This distinguishes it from sibling tools like ftp_list or ftp_get_contents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The last sentence explicitly states when to use the tool: 'Use this to gain architectural context of a new codebase.' While it does not explicitly mention when not to use or name alternatives, the context of sibling tools makes the intended use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a selection of remote files to local destinations. HIGHLY RECOMMENDED for bulk downloads to leverage stable socket persistence.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | A list of objects mapping remote sources to local destinations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It mentions 'stable socket persistence' as a behavioral trait. However, it fails to disclose other important behaviors such as idempotency, error handling, concurrency limits, or whether existing local files are overwritten.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences, front-loaded with the primary action. Every word serves a purpose, with zero extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers purpose and usage recommendation adequately. However, it could be enriched with notes on concurrency, file conflict behavior, or error reporting to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameter properties with descriptions, providing clear structure. The tool description itself adds no additional semantics beyond the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (download), resource (remote files to local destinations), and recommends it for bulk downloads. It effectively distinguishes from siblings like ftp_download (single file) and ftp_batch_upload (upload direction), providing a specific verb+resource scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends this tool for bulk downloads to leverage stable socket persistence, implying when to use. However, it does not provide explicit when-not-to-use guidance or name alternative tools for single file downloads.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a collection of local files to remote destinations in a single operation. HIGHLY RECOMMENDED for multiple files to minimize connection handshaking overhead and drastically improve performance.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | A list of objects, each defining a local source and a remote destination. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions 'single operation' and performance, but fails to disclose critical behavioral traits such as atomicity, error handling for partial failures, ordering, authentication requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose. Every word adds value: 'Upload a collection of local files to remote destinations in a single operation' is concise and informative. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple batch upload with one parameter and no output schema, the description covers the basic operation and benefit. However, it omits expected return information (e.g., success/failure reporting, results metadata) and does not address potential constraints like maximum file count or size. Given the tool's simplicity, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents the files parameter with localPath and remotePath. The tool description adds 'in a single operation' but does not enhance parameter meaning beyond that. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Upload a collection of local files to remote destinations in a single operation' with a specific verb ('Upload'), resource ('collection of local files'), and scope ('remote destinations in a single operation'). This clearly distinguishes it from singular tools like ftp_upload and batch download ftp_batch_download.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using this tool for multiple files to minimize connection overhead and improve performance. This gives clear when-to-use guidance, though it does not explicitly mention when not to use (e.g., single files) or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change remote file permissions. CRITICAL: Only supported on SFTP connections.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | Standard octal permission string (e.g., '755' for executable, '644' for read-write). | |
| path | Yes | Remote file path to modify. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the mutation behavior and the critical SFTP-only constraint, but lacks details on permissions required, side effects, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at two sentences, with no wasted words. The first sentence states purpose, the second adds a critical warning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required params, no output schema), the description is adequate but incomplete. It does not mention return behavior, success/failure indication, or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters have descriptions), so baseline is 3. The description does not add meaning beyond the schema; it merely restates the action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Change' and resource 'remote file permissions', making the purpose explicit. It distinguishes from sibling tools since none are specifically for permissions, but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a constraint ('Only supported on SFTP connections') but provides no guidance on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Establish or switch the active connection to a specific remote server profile defined in your .ftpconfig (e.g., 'production', 'staging'). This is the first step before performing any remote operations.
| Name | Required | Description | Default |
|---|---|---|---|
| useEnv | No | If true, bypasses .ftpconfig and connects using global environment variables (FTPMCP_HOST, etc.) | |
| profile | No | The named profile key from your .ftpconfig file. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the tool's purpose and connection method (.ftpconfig or env vars). However, it omits details like authentication handling, timeout, or side effects (e.g., disconnecting previous connection).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy, front-loaded with action and context. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setup tool with two optional params and no output schema, the description adequately covers purpose and usage. Could mention return value or success indicator, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value by explaining 'profile' as a key from .ftpconfig and 'useEnv' as bypassing config for env vars, providing context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb-resource pairing ('establish or switch the active connection to a specific remote server profile') and clarifies it is the first step, distinguishing it from sibling tools like ftp_list or ftp_upload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly states it is the first step before remote operations, implying when to use. No explicit when-not-to-use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Directly duplicate a file on the remote server without downloading and re-uploading. CRITICAL: Only supported on SFTP connections.
| Name | Required | Description | Default |
|---|---|---|---|
| destPath | Yes | Target remote destination path. | |
| sourcePath | Yes | Qualified remote source path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the direct duplication behavior and the SFTP restriction, which are key traits. However, it does not mention whether the destination file is overwritten or what happens to permissions, but the core behavioral insight is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loading the verb and resource. Every sentence adds value, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, lack of output schema, and the presence of sibling tools, the description adequately covers purpose and a critical limitation. It is complete enough for an agent to understand the tool's basic behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add any additional meaning about the parameters beyond what is in the schema, but no compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it duplicates a file directly on the remote server, emphasizing it avoids download/upload, and includes a critical note about SFTP-only support. This distinguishes it well from siblings like ftp_upload, ftp_download, and ftp_rename.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a critical limitation (SFTP only) but lacks explicit guidance on when to use this tool versus alternatives like ftp_rename or ftp_upload+download. The context is clear but does not fully exclude inappropriate uses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently remove a file from the remote server. Use with caution.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | The remote file path to be destroyed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that deletion is permanent ('Permanently remove') and includes a caution. However, with no annotations, it fails to mention other behavioral traits such as whether deletion is recursive, whether confirmation is required, or if there are authentication or permission implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two short phrases. It front-loads the core action and adds a caution. No extraneous text, though it could be slightly more structured (e.g., separating purpose from warnings).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the essential purpose and behavior. However, given the many sibling tools, additional context about file scope (e.g., only files, not directories) or a reference to ftp_rmdir for directories would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter schema coverage is 100%, and the description adds no significant meaning beyond the schema's own description ('The remote file path to be destroyed'). The tool description implies the path is a file path, but the schema already conveys this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool permanently removes a file from the remote server. The verb 'remove' and resource 'file' are specific, and it distinguishes from sibling tools like ftp_rmdir (removes directories) and ftp_list (lists files).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like ftp_rmdir or ftp_batch_upload. The only advisory is 'use with caution,' which is too vague for an AI agent to select the correct tool among many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a pre-defined deployment preset from .ftpconfig. This typically maps a specific local folder to a remote target with pre-configured exclusion rules.
| Name | Required | Description | Default |
|---|---|---|---|
| deployment | Yes | The name of the deployment preset (e.g., 'web-app', 'api-server'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided so the description carries full burden. It mentions execution of a preset which involves file transfer, but does not disclose whether action is destructive (overwrites), requires a connection, or details error handling. Minimal transparency beyond basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose. Every sentence adds value: first states action, second adds context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (one parameter, no output schema), the description adequately covers what, how (via .ftpconfig), and typical usage. Lacks details on return values or failure modes, but not critical for a straightforward command.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'deployment'. Description adds value by specifying it is a preset name from .ftpconfig and providing examples ('web-app', 'api-server'), which goes beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: executing a pre-defined deployment preset from .ftpconfig. It further explains the mapping of a local folder to a remote target with exclusion rules, which distinguishes it from sibling tools like ftp_upload or ftp_sync.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for predefined deployment presets but does not explicitly state when to use this tool over alternatives like ftp_upload or ftp_sync. No exclusions or prerequisite conditions are mentioned meaning the agent lacks clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the remote server for available disk space. CRITICAL: Only available on SFTP connections.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Remote filesystem path to check (defaults to server root). | . |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source of behavioral info. It indicates a read-only operation ('Query') and a connection-type constraint. No side effects, rate limits, or authentication details are given, but for a simple query tool it is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short sentences: the first states the purpose, the second adds a critical constraint. Every word is necessary; no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema. The description covers the core action and a key constraint. It does not mention the return format, but for a disk space query this is often a standard string, and the sibling tools may set expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter 'path' (described as 'Remote filesystem path to check (defaults to server root).'). The description adds no further meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Query' and resource 'remote server for available disk space', clearly stating the tool's action. It distinguishes the tool from 27 sibling tools, none of which mention disk space queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Only available on SFTP connections', providing a critical constraint on when to use this tool. It does not mention alternatives, but the constraint is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Standard single-file transport from the remote server. For bulk downloads, favor ftp_batch_download.
| Name | Required | Description | Default |
|---|---|---|---|
| localPath | Yes | Destination location on your local machine. | |
| remotePath | Yes | Source file location on the remote server. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states 'standard single-file transport' but misses important behavioral details like overwrite behavior, error handling, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, no wasted words, and the purpose is front-loaded. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is too minimal. It does not explain return values, error conditions, or other contextual information that would help an agent use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already fully describes both parameters. The description adds no additional parameter meaning beyond what the schema provides, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Standard single-file transport from the remote server', clearly indicating it downloads a single file. It also distinguishes from ftp_batch_download for bulk operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'For bulk downloads, favor ftp_batch_download', which helps an agent decide when to use this tool vs the sibling. However, it does not cover other potential alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check for the existence of a file or folder without performing heavy file operations. Use this for conditional logic workflows.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Remote target path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the tool avoids heavy operations, but does not disclose return values, error behavior, or whether it is read-only. Additional detail would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The action is front-loaded, and every sentence adds value. It is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is mostly complete for a simple existence check, but lacks explanation of return values (e.g., boolean) and error handling. Without an output schema, this gap reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'path' parameter, which has its own description. The tool description adds no further meaning beyond what the schema provides, earning a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks for the existence of a file or folder, using a specific verb and resource. It distinguishes itself from sibling tools by noting it avoids heavy file operations, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises use for conditional logic workflows, providing clear context. However, it does not explicitly mention when not to use it or list alternatives, though the lightweight nature is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the source text of a remote file. CRITICAL: For large files, use 'startLine' and 'endLine' to extract specific chunks and prevent hitting the LLM context limit.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute or relative remote path to the file. | |
| endLine | No | Optional: The last line to include (inclusive, 1-indexed). | |
| startLine | No | Optional: The first line to include in the output (1-indexed). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It implies a read-only operation but does not explicitly state safety, permission needs, or performance characteristics beyond the large file note.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. The CRITICAL callout effectively highlights an important usage note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers tool purpose and parameter usage for large files. Could be slightly improved by noting that output is plain text, but not necessary given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds value by explaining the critical use of startLine/endLine for large files, going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read the source text of a remote file' with a specific verb and resource. It distinguishes from siblings like ftp_put_contents (write) and other FTP tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to use startLine/endLine for large files to avoid LLM context limits. Does not explicitly contrast with sibling tools but offers practical usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files and directories in a remote path. Use 'limit' and 'offset' for pagination when dealing with directories containing hundreds of files to avoid context overflow.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Remote directory path (defaults to current working directory). | . |
| limit | No | Maximum results to return in this chunk. | |
| offset | No | Starting position in the file list for pagination. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description omits critical behavioral details such as whether the operation is read-only, the format of the returned data, or any side effects. The pagination advice is helpful but insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no extra words. The action is front-loaded, and the guidance on pagination is directly relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should indicate what the list returns (e.g., an array of file names). This is a key omission for an agent to use the tool's output effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value beyond the schema by explaining the purpose of pagination (avoiding context overflow), reinforcing the use of limit and offset.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'files and directories in a remote path', distinguishing it from sibling tools like ftp_list_transactions or ftp_get_contents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on using limit and offset for pagination to avoid context overflow, but does not mention when not to use this tool or point to alternatives like ftp_tree for recursive listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available deployment presets from .ftpconfig
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a read operation but does not disclose behaviors like error handling if .ftpconfig is missing, side effects, or whether the list is cached.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description is adequate for a simple list tool, it lacks details about output format, potential errors, and the nature of deployment presets, which could confuse an agent without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (no parameters), so baseline is 3. Description adds no parameter information because none exist, but the schema already conveys this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List) and the specific resource (deployment presets) with a source (.ftpconfig). It distinguishes itself from sibling tools like ftp_list_transactions or ftp_deploy by focusing on presets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as ftp_deploy or ftp_list_transactions. The description lacks context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Expose all recent mutations currently stored in the system's SnapshotManager. Essential for planning rollbacks.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not explicitly state that the operation is read-only, nor does it define 'recent' or disclose any side effects. The word 'Expose' implies read access, but this is not guaranteed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys purpose and use case. It is front-loaded but could be slightly more precise (e.g., specifying 'read-only').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is missing details about return structure, data freshness, and whether the operation is safe. It covers purpose and context but not enough for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters, 100% coverage), so description cannot add parameter semantics. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Expose' and clearly identifies the resource as 'recent mutations currently stored in the system's SnapshotManager'. It distinguishes from siblings like ftp_rollback (action vs. list) and ftp_list_deployments (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'Essential for planning rollbacks', which provides a clear context for when to use this tool. However, it does not explicitly exclude alternatives or state when not to use, but the sibling tool ftp_rollback suggests this is a preparatory step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new directory structure on the remote server. Supports nested creation (mkdir -p).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | The remote directory path to create. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries burden. It mentions nested creation (mkdir -p) but lacks behavior like error handling, directory existence handling, or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with action. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple 1-param tool, description covers basic behavior. Missing error handling, success indicators, and guidance among 28 siblings. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and describes the path parameter. Description adds no further parameter specifics beyond the schema, keeping baseline at 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool creates directory structures and supports nested creation, distinguishing it from siblings like ftp_rmdir (deletion) and ftp_upload (file transfer).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies use for creating directories, but no explicit when-to-use or when-not-to-use compared to alternatives. Context is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply a Unified Diff patch to a remote file. RECOMMENDED: Use this instead of ftp_put_contents for updating existing files to minimize bandwidth and ensure atomic-like updates. For new files, use ftp_put_contents.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Remote path to the existing file to be patched. | |
| patch | Yes | The Unified Diff formatted string containing your local changes. | |
| createBackup | No | Generate a .bak copy of the remote file before applying the changes. | |
| expectedHash | No | Optional (but recommended): The SHA-256 hash of the remote file before patching to prevent race conditions (drift protection). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions 'atomic-like updates' but does not detail failure behavior, security requirements, or race condition handling (despite expectedHash parameter). Lacks depth in 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. Core action, recommendation, and alternative are front-loaded. Highly concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and no annotations, the description covers purpose, usage guidance, and key recommendation. It omits error behavior and prerequisites, but these are less critical given tool simplicity and sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds minimal extra meaning beyond schema; it mentions 'Unified Diff formatted string' but that repeats the schema. No enrichment of parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Apply a Unified Diff patch') and resource ('remote file'), and explicitly distinguishes from sibling tool ftp_put_contents by stating when to use each for updating vs. new files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use this tool ('for updating existing files') and when to use the alternative ('For new files, use ftp_put_contents'), and highlights benefits (minimize bandwidth, atomic-like updates).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan the remote server to determine supported filesystem features (e.g., chmod availability, symlink support, disk space querying). Helpful for troubleshooting capabilities.
| Name | Required | Description | Default |
|---|---|---|---|
| testPath | No | A safe, ephemeral directory to run capability benchmarks in. | . |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, yet the description does not disclose behavioral traits such as whether the scan is read-only or requires specific permissions. It does not mention side effects or safety considerations, leaving the agent with insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief (two sentences) and front-loaded with the action. Every sentence contributes, though it could be more structured (e.g., using bullet points).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with one parameter and no output schema. The description is adequate but missing details about return values or how results are presented, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter testPath, and the schema description already explains its purpose. The tool description adds no extra meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool scans a remote server to determine supported filesystem features like chmod, symlink support, and disk space querying. The verb 'scan' and resource 'capabilities' are specific, and it distinguishes from sibling tools that perform specific operations (e.g., ftp_chmod, ftp_disk_space).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for troubleshooting capabilities but does not explicitly state when to use this tool versus alternatives (e.g., checking disk space via ftp_disk_space). No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write raw text directly to a remote destination. Best for creating NEW files. For modifying existing files, prefer ftp_patch_file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Remote destination path. | |
| content | Yes | The full string content to write. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states writing raw text and creating new files, but does not disclose behavior if the path already exists (overwrite vs fail), permissions needed, or side effects. This leaves some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loads the verb and purpose, and every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (raw text write), the description is largely complete. It could mention return value or error cases, but the core function and guidance are clear. Slightly lacking in comparison to sibling tools that might handle files (e.g., ftp_upload).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described adequately. The tool description adds no additional 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('write raw text') and the resource ('remote destination'), and explicitly distinguishes from sibling tools by noting it is best for creating new files, with ftp_patch_file for modifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use (creating new files) and when-not-to-use (modifying existing files) with a direct alternative (ftp_patch_file), giving clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move or rename files and directories on the remote server.
| Name | Required | Description | Default |
|---|---|---|---|
| newPath | Yes | New desired remote location. | |
| oldPath | Yes | Current remote location. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states 'move or rename' without detailing side effects, permission requirements, or behavior when paths overlap. Minimal context for a 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise, though it could be slightly expanded to include key behavioral notes without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 required parameters, no output schema, no annotations), the description covers the basic concept but misses behavioral and edge-case details that would fully inform an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds little beyond the parameter names. It implies the operation changes location/name but does not specify format constraints or path resolution details. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: moving or renaming files and directories on a remote server. This is a specific verb-resource combination that distinguishes it from siblings like ftp_copy or ftp_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as ftp_copy for duplication or ftp_upload for new files. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a directory from the remote server.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | The remote directory path to remove. | |
| recursive | No | If true, deletes all files and subdirectories within the target directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only states 'Delete a directory,' omitting details like that non-empty directories require the recursive flag, or that the operation is destructive and irreversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it sacrifices necessary detail for brevity. It could include more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters, no output schema, and no annotations, the description is too minimal. It does not mention error handling, preconditions (e.g., connected state), or return values, leaving gaps for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters described in the schema. The description adds no additional meaning beyond the schema's descriptions, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a directory from the remote server,' specifying the verb and resource. It distinguishes from siblings like ftp_delete (deletes files) and ftp_mkdir (creates directories), but does not explicitly name these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as ftp_delete for files. The description does not mention conditions for use or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Undo a previous file mutation by restoring it from a system-generated snapshot. This provides safety during complex refactoring tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| transactionId | Yes | Specific ID associated with the snapshot (e.g., 'tx_12345'). Get this from ftp_list_transactions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It states 'restoring from a system-generated snapshot' but does not disclose whether the operation is reversible, what permissions are needed, or any 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The primary action is front-loaded: 'Undo a previous file mutation...' and context follows. Every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description adequately explains purpose and parameter source. It could mention what the return value indicates (success/failure), but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter. Description adds value by specifying the source of the parameter ('Get this from ftp_list_transactions'), which goes beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the tool undoes a previous file mutation by restoring from a system-generated snapshot, which is a unique action among siblings (no other tool offers undo/rollback). The verb 'Undo' and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage during complex refactoring tasks for safety, but does not explicitly state when not to use it or list alternatives. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Advanced remote file search. Supports finding files by name (wildcards), extension, or content regex (grep-like). Use this to find specific code patterns across the remote workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Remote directory to start the recursive search in. | . |
| limit | No | Maximum matches to return. | |
| offset | No | Skip initial matches for pagination. | |
| pattern | No | File name pattern (e.g. `*.js`, `db_*`). | |
| extension | No | Restrict search to specific file extensions (e.g. `.css`). | |
| contentPattern | No | Regex pattern to search inside file contents. Highly efficient for finding variable usage or specific logic. | |
| findLikelyConfigs | No | Prioritize searching for project manifests and config files (package.json, .env, etc.) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should fully disclose behavior. It only mentions search capabilities but omits details like recursion, performance impact, or required permissions, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key purpose, no superfluous words. Efficiently conveys the tool's role.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no output schema, the description provides adequate but incomplete context. It mentions search types but not return format, behavior on no matches, or recursion (though schema indicates recursion via path description).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value by mapping parameters to search types (name, extension, content regex) and explaining findLikelyConfigs. Some parameters like path, limit, offset have only schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is an advanced remote file search tool that supports finding files by name, extension, or content regex. It distinguishes from basic list operations but does not differentiate from similar sibling like ftp_analyze_workspace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use this to find specific code patterns across the remote workspace,' providing implicit guidance. However, it lacks when-not-to-use instructions or explicit comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve comprehensive metadata for a remote property, including size, modification timestamps, and UNIX permissions.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Remote file or directory path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only lists returned attributes without disclosing side effects, auth requirements, error behavior, or whether it is read-only. For a tool with no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is concise and front-loaded with the core purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks details on output format, error handling for missing paths, or behavior for directories. Given low complexity (1 param, no output schema), it is minimally adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a clear description of the 'path' parameter. The tool description adds no new semantics beyond confirming it accesses a 'remote property', so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves comprehensive metadata (size, timestamps, permissions) for a remote property, using a specific verb 'retrieve' and resource. This distinguishes it from siblings like ftp_list (list files) or ftp_get_contents (get content).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies usage for metadata retrieval but does not mention when not to use it or contrast with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deploy entire project folders using smart synchronization. Analyzes local and remote directory trees and only transfers files that have changed in size or modification date. Automatically respects .gitignore and .ftpignore.
| Name | Required | Description | Default |
|---|---|---|---|
| dryRun | No | If true, logs exactly which files would be changed without performing any actual transfers. | |
| direction | No | Sync direction. Currently only 'upload' is implemented for safety. | upload |
| localPath | Yes | The source directory on your local machine. | |
| remotePath | Yes | The target destination directory on the remote server. | |
| useManifest | No | Enables the local manifest cache for extremely fast delta detection on subsequent syncs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that only changed files are transferred and that ignore files are respected, but omits details on side effects (e.g., directory creation, potential deletions), permission requirements, and the upload-only direction (present in schema but not description).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three succinct sentences with no fluff. It front-loads the main purpose, explains the core mechanism, and mentions a key feature (ignore files). Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema's rich parameter descriptions (100% coverage) and no output schema, the description adequately covers the tool's intelligence and ignores file handling. It lacks explicit mention of dry-run and manifest features, but those are in schema. Overall, sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all parameters. The description adds value by mentioning ignore file behavior, but does not elaborate on individual parameters like dryRun or useManifest beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool does smart synchronization for deploying entire project folders, only transferring changed files. It distinguishes from siblings like ftp_upload or ftp_deploy by emphasizing delta detection and ignore file support.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., ftp_upload, ftp_batch_upload). It does not specify when not to use it or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve internal performance metrics, including average latency, connection pool health, and total processed bytes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. States it retrieves metrics but omits whether it's read-only, requires permissions, or has rate limits. Basic but functional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with zero wasted words. Front-loaded verb and resource, then specifics. Efficient for a parameterless tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should partially compensate. While it names metric categories, it doesn't specify format, units, or structure. Adequate for simple telemetry but could include return type hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters (schema coverage 100%), so baseline is 4. Description adds value by enumerating metric categories (latency, pool health, bytes), helping agent understand output scope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Retrieve' and resource 'internal performance metrics', listing examples like latency and pool health. Clearly distinct from sibling tools focused on files or deployments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs siblings like ftp_analyze_workspace or ftp_list_transactions. Does not specify context (e.g., debugging, monitoring) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a complete recursive directory map. Use this to visualize project structure, but be cautious with 'maxDepth' in very large remote repositories to avoid excessive network payload.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Remote directory path to start mapping from (defaults to root). | . |
| maxDepth | No | Maximum recursion depth to prevent infinite loops or huge payloads. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It warns about excessive payload with maxDepth, but does not disclose error handling (e.g., nonexistent path), permissions, or network behavior. Partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences, front-loaded with action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and low complexity, description covers purpose and a key risk. Missing error handling details but sufficient for basic usage. Sibling tools exist for deeper analysis, so this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description restates parameter defaults and purpose without adding new meaning. No additional syntax, constraints, or examples beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a recursive directory map, which is distinct from siblings like ftp_list (flat listing) and ftp_stat (file details). The verb 'generate' and resource 'directory map' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use for visualization of project structure, and a caution about maxDepth in large repos. However, it does not explicitly compare to alternatives (e.g., use ftp_list for flat listing) or say when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Standard single-file transport to the remote server. For bulk transfers, favor ftp_batch_upload.
| Name | Required | Description | Default |
|---|---|---|---|
| localPath | Yes | Source path on your local machine. | |
| remotePath | Yes | Target location on the remote server. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present; description only calls it 'standard single-file transport' without mentioning overwrite behavior, failure modes, or size limits. Needs more behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose and immediate alternative guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Low complexity tool with 2 parameters and no output schema; however, missing behavioral details (e.g., overwrite, size limits) reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have descriptions; description adds no extra meaning beyond the schema. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'single-file transport to the remote server', specifying verb and resource. Distinguishes from 'ftp_batch_upload' for bulk transfers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use 'ftp_batch_upload' for bulk transfers, providing clear when-not and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose, with descriptions that differentiate similar operations like single vs batch upload/download, and patch vs put for file content updates. No tools appear to overlap in functionality.
All tools follow a consistent ftp_verb_noun or ftp_verb pattern in snake_case, with no deviation in naming convention. This makes the tool set predictable and easy to navigate.
With 28 tools, the set is extensive but each tool serves a specific purpose (connection, file operations, batch processing, deployment, rollback, telemetry). While slightly above typical, the count is justified by the comprehensive feature set.
The tool set covers nearly all FTP operations including connect, list, get, put, patch, delete, rename, mkdir, rmdir, chmod, search, tree, sync, and batch transfers. Advanced features like rollback and workspace analysis add completeness, with no obvious gaps for standard FTP workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Cloud-hosted MCP server for secure AI access to enterprise data sources via CData Connect AI.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
Egnyte's remote MCP server for secure AI access, search, upload and file management in your account.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Kynlos/ftp-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
