Skip to main content
Glama

vm_file_push

Transfer files from local host to remote virtual machines using SCP protocol. Specify VM name, local file path, and remote destination path to copy files.

Instructions

Push a file from the local host to a remote host via SCP.

Args:
    vm: Name of the host (as configured in hosts.toml).
    local_path: Path to the file on the local host.
    remote_path: Absolute destination path on the remote host.

Returns:
    Success confirmation or error message.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
vmYes
local_pathYes
remote_pathYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • MCP tool handler decorated with @mcp.tool() that wraps the core implementation. Handles errors and returns user-friendly messages. This is the main entry point for MCP clients calling the tool.
    async def vm_file_push(
        vm: str,
        local_path: str,
        remote_path: str,
    ) -> str:
        """Push a file from the local host to a remote host via SCP.
    
        Args:
            vm: Name of the host (as configured in hosts.toml).
            local_path: Path to the file on the local host.
            remote_path: Absolute destination path on the remote host.
    
        Returns:
            Success confirmation or error message.
        """
        try:
            result = await _vm_file_push(vm, local_path, remote_path)
            if result.exit_code == 0:
                return f"Successfully pushed {local_path} -> {vm}:{remote_path}"
            return f"ERROR pushing file: {result.stderr.strip()}"
        except (ValueError, KeyError, FileNotFoundError, RuntimeError, OSError) as e:
            return f"ERROR: {e}"
  • Core implementation of vm_file_push that performs SCP file transfer from local host to remote host. Validates paths, checks file existence, and executes the SCP command.
    async def vm_file_push(
        vm: str,
        local_path: str,
        remote_path: str,
    ) -> ExecResult:
        """Push a file from the local host to a remote host via SCP.
    
        Args:
            vm: Name of the host (as configured in hosts.toml).
            local_path: Path to the file on the local host.
            remote_path: Absolute destination path on the remote host.
    
        Returns:
            ExecResult with operation details.
        """
        host = _resolve_host(vm)
        _validate_local_path(local_path)
        _validate_path(remote_path)
    
        if not Path(local_path).is_file():
            raise FileNotFoundError(f"Local file not found: {local_path}")
    
        return await _run_scp(
            host,
            [local_path, f"{host.scp_prefix}{remote_path}"],
        )
  • Input validation functions _validate_path and _validate_local_path that validate remote and local file paths (check for empty strings, null bytes, and absolute paths).
    def _validate_path(path: str) -> None:
        """Validate a file path on the remote host (basic safety checks)."""
        if not path or not path.strip():
            raise ValueError("Path cannot be empty")
        if "\x00" in path:
            raise ValueError("Path cannot contain null bytes")
        if not path.startswith("/"):
            raise ValueError(f"Path must be absolute (start with /): '{path}'")
    
    
    def _validate_local_path(path: str) -> None:
        """Validate a local file path on the host."""
        if not path or not path.strip():
            raise ValueError("Local path cannot be empty")
        if "\x00" in path:
            raise ValueError("Path cannot contain null bytes")
  • ExecResult dataclass defining the return type structure with stdout, stderr, and exit_code fields used by the vm_file_push function.
    @dataclass
    class ExecResult:
        """Result of running a command on a remote host."""
    
        stdout: str
        stderr: str
        exit_code: int
  • Import statement that imports vm_file_push from transport module as _vm_file_push, connecting the MCP handler to the core implementation.
    vm_file_push as _vm_file_push,
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the transfer mechanism (SCP) and return values, but lacks details on permissions required, error handling, file size limits, or network behavior. For a file transfer tool with zero annotation coverage, this is a significant gap in transparency.

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

Conciseness5/5

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

The description is efficiently structured with a clear purpose statement followed by well-organized sections for Args and Returns. Each sentence earns its place by providing essential information without redundancy, making it easy to parse and understand.

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

Completeness4/5

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

Given the tool's complexity (file transfer with SCP), no annotations, and an output schema present (which covers return values), the description is reasonably complete. It explains the purpose, parameters, and return expectation, though it could benefit from more behavioral details like authentication requirements or transfer limitations.

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

Parameters4/5

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

The description adds meaningful semantics for all three parameters: 'vm' is explained as a host name from configuration, 'local_path' as a path on the local host, and 'remote_path' as an absolute destination path. With 0% schema description coverage, this fully compensates by providing clear parameter context beyond the bare schema.

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

Purpose5/5

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

The description clearly states the specific action ('Push a file'), the mechanism ('via SCP'), and the resources involved ('from the local host to a remote host'). It distinguishes this tool from sibling tools like 'vm_file_pull' (which would move files in the opposite direction) and 'vm_file_write' (which likely writes content rather than transferring files).

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

Usage Guidelines3/5

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

The description implies usage for file transfer to a remote host, but does not explicitly state when to use this tool versus alternatives like 'vm_file_pull' or 'vm_file_write'. It mentions the 'vm' parameter references a host 'as configured in hosts.toml', which provides some context but no explicit guidance on exclusions or prerequisites.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bobbyhiddn/Sympathy-MCP'

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