Click on "Deploy 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., "@VPS MCP Server List the files in my home directory and check the current disk usage"
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 MCP server that enables an AI agent to connect to and control a VPS (Virtual Private Server) via SSH.
connect_vps: Establish SSH connection (Host, Port, User, Password/Key).
disconnect_vps: Close the session.
list_directory: List files/folders in a path (supports relative paths to CWD).
create_directory: Create a new directory.
read_file: Read file contents.
write_file: Create or overwrite a file with content.
delete_item: Recursively delete a file or directory.
change_directory: Change the current working directory for subsequent commands.
get_current_directory: Get the current tracked working directory.
execute_command: Run shell commands.
Note: Commands are automatically prefixed with cd <current_working_directory>.
To change directory persistently, use change_directory instead of running cd here.
Related MCP server: MCP VPS Manager
Add the following configuration to your MCP client (e.g., Claude Desktop config file):
{
"mcpServers": {
"vps": {
"command": "npx",
"args": ["-y", "vps-mcp"]
}
}
}If you find this project useful, consider supporting me on Patreon:
or click here to donate.
Change the current working directory on the VPS.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Target directory path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Change') but doesn't describe what happens on failure (e.g., if the path doesn't exist), whether it affects other operations, or any side effects like permission requirements. This leaves significant gaps for a mutation tool with zero annotation coverage.
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, direct sentence with zero wasted words, making it highly concise and front-loaded. It efficiently communicates the core purpose without unnecessary elaboration, earning full marks for brevity and clarity in structure.
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 complexity of a directory change operation on a VPS, the description is incomplete. With no annotations, no output schema, and minimal behavioral details, it fails to cover important aspects like error handling, success indicators, or interaction with sibling tools (e.g., needing 'connect_vps' first). This is inadequate for a mutation tool in this 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?
The input schema has 100% description coverage, with the 'path' parameter clearly documented as 'Target directory path.' The description adds no additional semantic context beyond this, such as path format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Change') and resource ('current working directory on the VPS'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_current_directory' or 'create_directory', which would require more specific language about what distinguishes this operation from those.
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. It doesn't mention prerequisites (e.g., needing to be connected via 'connect_vps'), exclusions (e.g., invalid paths), or comparisons to siblings like 'create_directory' for new directories or 'get_current_directory' for checking the current location.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect to a VPS using SSH. Requires host, username, and either password or privateKey.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | Hostname or IP address of the VPS | |
| port | No | SSH port (default: 22) | |
| username | Yes | SSH username | |
| password | No | SSH password (optional if privateKey provided) | |
| privateKey | No | SSH private key (optional if password provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it states the tool establishes an SSH connection and lists authentication options, it doesn't describe what happens after connection (e.g., creates a session, returns connection status), potential failure modes, security implications, or whether this is a one-time or persistent connection. For a security-sensitive tool with zero annotation coverage, this is inadequate.
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 perfectly concise - a single sentence that states the purpose and key requirements with zero wasted words. It's front-loaded with the core action and immediately follows with essential constraints.
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 security-critical SSH connection tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns (connection handle, success status, error details), doesn't mention session management, and provides no information about error handling or security considerations. The context demands more comprehensive documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all 5 parameters. The description adds minimal value beyond the schema by mentioning the authentication alternatives (password or privateKey), but doesn't provide additional context about parameter relationships, validation rules, or usage examples. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Connect to a VPS using SSH') and identifies the required resources (host, username, and authentication credentials). It distinguishes this tool from siblings like execute_command or disconnect_vps by focusing on establishing the SSH connection itself rather than subsequent 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 implies usage context by mentioning SSH connection requirements, but doesn't explicitly state when to use this tool versus alternatives like disconnect_vps or execute_command. It provides basic prerequisites (host, username, authentication) but lacks guidance on timing or exclusion scenarios.
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 on the VPS.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path of the directory to create. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool creates a directory but doesn't mention permissions required, whether it overwrites existing directories, error conditions (e.g., invalid paths), or what happens on success/failure. This leaves significant behavioral gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with zero wasted information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after creation (e.g., success confirmation, error messages), doesn't address permissions or constraints, and leaves behavioral aspects unclear given the tool's complexity.
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, with the single parameter 'path' documented as 'Path of the directory to create.' The description doesn't add any additional parameter context beyond what the schema provides, so it meets 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 states the action ('Create') and resource ('a new directory on the VPS'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'change_directory' or 'list_directory', which prevents a perfect score.
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 'change_directory' or 'delete_item'. It doesn't mention prerequisites (e.g., needing to be connected to VPS first) or exclusions, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a file or directory on the VPS (recursive).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the file or directory to delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the deletion is recursive, which is a key behavioral trait beyond the basic action. However, it lacks details on permissions required, error handling (e.g., what happens if the path doesn't exist), side effects, or confirmation prompts, which are critical for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information (action, resource, environment, and recursive nature) with zero wasted words. It is appropriately sized for the tool's complexity.
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 destructive nature, lack of annotations, and no output schema, the description is minimally complete. It covers the basic purpose and scope but misses critical context like safety warnings, return values, or error conditions. It is adequate but has clear gaps for a high-risk operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'path' fully documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., no examples, format constraints, or special cases). Baseline 3 is appropriate as the schema handles the parameter documentation adequately.
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 specific action ('Delete') and resource ('a file or directory on the VPS'), with the additional detail of being recursive. It distinguishes itself from siblings like 'remove' or 'unlink' tools by specifying the scope and target environment.
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 deleting files/directories on a VPS, but does not explicitly state when to use this tool versus alternatives (e.g., no mention of prerequisites like needing an active VPS connection from 'connect_vps', or alternatives for non-destructive operations). It provides basic context but lacks explicit guidance on exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disconnect from the current VPS session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action but doesn't explain what 'disconnect' entails—whether it terminates processes, closes connections, requires authentication, or has side effects. This leaves significant behavioral gaps for a tool that likely ends a session.
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, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it immediately understandable without unnecessary elaboration.
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 likely complexity (ending a session) and lack of annotations or output schema, the description is insufficient. It doesn't cover what happens upon disconnection, return values, error conditions, or dependencies on other tools like 'connect_vps', leaving the agent with incomplete operational 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?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter details, and it correctly implies no inputs are required, earning a high baseline score for this context.
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 ('Disconnect from') and target resource ('the current VPS session'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'connect_vps' beyond the obvious opposite action, which prevents a perfect score.
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 or what conditions must be met. It doesn't mention prerequisites like needing an active VPS session or warn against misuse, leaving the agent with incomplete context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a shell command on the connected VPS and return the output. Runs in the current tracked directory.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The shell command to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions execution context ('current tracked directory') but doesn't disclose critical behavioral traits like security implications, permission requirements, error handling, timeout behavior, or whether commands run interactively. For a potentially dangerous shell execution tool, this leaves significant gaps in understanding its behavior.
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 perfectly concise with two sentences that each earn their place: the first states the core functionality, and the second adds important contextual constraint about execution directory. No wasted words, front-loaded with the main 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?
Given this is a potentially dangerous shell execution tool with no annotations and no output schema, the description is incomplete. It doesn't explain what kind of output is returned (stdout? stderr? exit code?), error conditions, security warnings, or limitations. The context about current directory is helpful but insufficient for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single 'command' parameter well-documented in the schema. The description adds no additional parameter semantics beyond what the schema provides about the command parameter. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Execute a shell command'), the target resource ('on the connected VPS'), and the outcome ('return the output'). It distinguishes itself from siblings like change_directory, list_directory, or read_file by focusing on arbitrary command execution rather than specific file 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 implies usage context by mentioning 'connected VPS' and 'current tracked directory', suggesting it should be used after establishing a connection and potentially after navigating directories. However, it doesn't explicitly state when to use this versus alternatives like specific file operations (read_file, write_file) or when not to use it (e.g., for simple directory listing vs. using list_directory).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current working directory path.
| 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 states what the tool does but doesn't disclose behavioral traits like whether this is a read-only operation (implied but not stated), what format the path returns (absolute vs relative), error conditions, or performance characteristics. For a tool with zero annotation coverage, this is inadequate.
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, clear sentence with zero waste. It's front-loaded with the essential information and appropriately sized for a simple tool. Every word earns its place, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is minimally complete. However, with no annotations and no output schema, it should ideally mention the return format (e.g., string path) or basic behavior. It's adequate but leaves gaps in understanding the tool's full 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?
The tool has zero parameters, and schema description coverage is 100% (though empty). The description doesn't need to explain parameters, so it appropriately focuses on the tool's purpose. Baseline for zero parameters is 4, as there's no parameter information to add beyond what's already covered.
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 ('Get') and resource ('current working directory path'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'list_directory' or 'change_directory', but the specificity of 'current working directory' versus general directory listing or navigation provides implicit distinction.
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. It doesn't mention when this is appropriate (e.g., to check location before file operations) or when other tools like 'list_directory' might be more suitable. There's no explicit or implied context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List contents of a directory on the VPS. Defaults to current working directory.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to list (relative to CWD or absolute). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it states the basic action (listing directory contents) and default behavior (current working directory), it doesn't describe important behavioral traits such as: what format the output takes (e.g., list of filenames, detailed metadata), whether it includes hidden files, error handling for invalid paths, permissions required, or any rate limits. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
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 (one sentence) and front-loaded with the core purpose. Every word earns its place: 'List contents of a directory on the VPS' establishes the primary action, and 'Defaults to current working directory' adds crucial behavioral context. There's no wasted verbiage or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (directory listing operation), lack of annotations, and absence of an output schema, the description is incomplete. It doesn't explain what the tool returns (file list format, metadata included), error conditions, permissions needed, or how it interacts with sibling tools like 'change_directory'. For a tool with no structured output documentation, the description should provide more complete context about the operation's results and constraints.
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 description mentions the default behavior ('Defaults to current working directory') which adds context beyond the schema's description of the 'path' parameter ('Path to list (relative to CWD or absolute)'). However, with 100% schema description coverage (the single parameter is fully documented in the schema), the description doesn't need to compensate heavily. It provides some additional semantic context about defaults, but doesn't explain parameter interactions or constraints beyond what's in 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 the verb ('List') and resource ('contents of a directory on the VPS'), making the purpose immediately understandable. It distinguishes from siblings like 'get_current_directory' (which returns only the current path) and 'read_file' (which reads file contents rather than listing directory contents). However, it doesn't explicitly mention what specific information is returned (e.g., files vs. directories, permissions, sizes).
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 context by stating 'Defaults to current working directory,' suggesting this tool should be used when you want to see directory contents, with an optional path parameter. However, it doesn't explicitly state when to use this versus alternatives like 'get_current_directory' (which only returns the current path without listing) or 'execute_command' (which could run custom listing commands). No explicit when-not-to-use guidance or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the contents of a file on the VPS.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the file. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Read' implies a non-destructive operation, it doesn't specify important behavioral aspects: whether it requires specific permissions, what happens if the file doesn't exist or path is invalid, if there are size limitations, or what format the content is returned in. For a file operation tool with zero 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?
The description is a single, efficient sentence that states exactly what the tool does with zero wasted words. It's appropriately sized for a simple read operation and front-loads the core functionality.
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 that this is a file system operation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens in error cases, what format the file contents are returned in, or any limitations. For a tool that reads files from a VPS, more context about behavior and output is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% (the 'path' parameter is fully documented in the schema), so the baseline is 3. The description doesn't add any meaningful parameter information beyond what the schema already provides about the single 'path' parameter.
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 ('Read') and resource ('contents of a file on the VPS'), making the purpose immediately understandable. However, it doesn't distinguish this tool from potential alternatives like 'get_current_directory' or 'list_directory' that might also involve reading file system information, so it doesn't reach the highest score.
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 about when to use this tool versus alternatives. It doesn't mention prerequisites (like needing to be connected to the VPS first), nor does it differentiate from sibling tools like 'list_directory' (which lists files) or 'get_current_directory' (which gets directory info).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or overwrite a file on the VPS.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the file. | |
| content | Yes | Content to write to the file. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool can 'create or overwrite,' implying mutation, but lacks details on permissions required, error handling (e.g., invalid paths), side effects (e.g., overwriting existing files), or response format. This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence with zero waste—it directly states the tool's function without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.
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 complexity (a mutation operation with potential side effects), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like safety, error cases, or return values, leaving significant gaps for the agent to operate 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?
The schema description coverage is 100%, with clear descriptions for both parameters ('path' and 'content'). The description adds no additional meaning beyond what the schema provides (e.g., no examples or constraints), so it meets the baseline score of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create or overwrite') and resource ('a file on the VPS'), making the purpose immediately understandable. It distinguishes from siblings like 'read_file' (read-only) and 'delete_item' (removal), though it doesn't explicitly differentiate from 'create_directory' (directory vs. file creation).
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. It doesn't mention prerequisites (e.g., needing to connect to VPS first), when not to use it (e.g., for directories), or alternatives like 'execute_command' for complex file operations. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.2change_directoryconnect_vpscreate_directorydelete_itemdisconnect_vpsexecute_commandget_current_directorylist_directoryread_filewrite_fileScored across 10 tools
Each tool has a clearly distinct purpose with no ambiguity. For example, change_directory modifies the working directory while get_current_directory retrieves it, and list_directory shows contents while read_file reads file data. The actions (change, connect, create, delete, etc.) and targets (directory, VPS, file) are consistently differentiated.
All tool names follow a consistent verb_noun pattern with snake_case throughout. Examples include change_directory, execute_command, and list_directory. There are no deviations in naming conventions, making the set predictable and readable.
With 10 tools, the count is well-scoped for managing a VPS via SSH. Each tool earns its place by covering essential operations like connection management, file system navigation, and command execution, without being excessive or insufficient for the domain.
The tool set provides strong coverage for core VPS management tasks, including connection handling, file CRUD operations, and directory navigation. A minor gap is the lack of tools for advanced operations like file permissions management or process monitoring, but agents can work around this using execute_command.
Scoped, audited SSH exec, sessions, and SFTP on your saved servers without exposing credentials
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
Let AI operate servers without SSH. Choose actions, approve risky changes, and audit every step.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
