Skip to main content
Glama
Preston-Harrison

Filesystem MCP Server

move_file

Move or rename files within allowed directories. Specify source and destination paths to relocate or rename files while maintaining directory restrictions.

Instructions

Move or rename a file from source to destination.

Args: src (str): Source file path (absolute or relative to allowed directories) dst (str): Destination file path (absolute or relative to allowed directories)

Returns: str: Success message with source and destination paths, or error message if failed

Note: - Both paths must be within allowed directory roots - Fails if destination already exists - Creates parent directories for destination if needed

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
srcYes
dstYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • main.py:258-282 (handler)
    The handler function for the 'move_file' MCP tool, including its @mcp.tool decorator for registration. It resolves source and destination paths, checks if destination exists, creates necessary parent directories, renames/moves the file, and handles errors gracefully.
    @mcp.tool
    def move_file(src: str, dst: str) -> str:
        """Move or rename a file from source to destination.
    
        Args:
            src (str): Source file path (absolute or relative to allowed directories)
            dst (str): Destination file path (absolute or relative to allowed directories)
    
        Returns:
            str: Success message with source and destination paths, or error message if failed
    
        Note:
            - Both paths must be within allowed directory roots
            - Fails if destination already exists
            - Creates parent directories for destination if needed
        """
        try:
            src_p, dst_p = _resolve(src), _resolve(dst)
            if dst_p.exists():
                return f"Error moving file: destination '{dst_p}' already exists"
            dst_p.parent.mkdir(parents=True, exist_ok=True)
            src_p.rename(dst_p)
            return f"Moved {src_p} → {dst_p}"
        except Exception as e:
            return _human_error(e, "moving file")
Behavior4/5

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

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: path constraints ('within allowed directory roots'), failure conditions ('fails if destination already exists'), and side effects ('creates parent directories for destination if needed'). It doesn't cover permissions or rate limits, but provides substantial operational context.

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

Conciseness5/5

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

Perfectly structured and front-loaded: purpose statement first, followed by organized sections for Args, Returns, and Note. Every sentence earns its place by providing essential information without redundancy. The description is appropriately sized for a 2-parameter tool with behavioral complexity.

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 2 parameters, no annotations, but with output schema (Returns section), the description is mostly complete. It covers purpose, parameters, constraints, and behavior well. Minor gaps include lack of explicit error handling details beyond 'error message if failed' and no mention of atomicity or transaction behavior for the move operation.

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?

Schema description coverage is 0%, so the description must compensate. It clearly explains both parameters: 'src' as 'Source file path (absolute or relative to allowed directories)' and 'dst' as 'Destination file path (absolute or relative to allowed directories)', adding meaningful context about path formats and constraints 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 ('Move or rename a file') and identifies the resource ('a file from source to destination'). It distinguishes from siblings like 'delete_file' (destructive removal) and 'edit_file' (content modification) by focusing on relocation/renaming.

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

Usage Guidelines4/5

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

The description provides clear context for usage through the 'Note' section (e.g., paths must be within allowed directories, fails if destination exists). However, it doesn't explicitly state when to use alternatives like 'rename' vs 'move' scenarios or compare to siblings like 'create_file' for new files.

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/Preston-Harrison/fs-mcp-py'

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