Skip to main content
Glama
Preston-Harrison

Filesystem MCP Server

create_file

Create new files with UTF-8 content at specified paths. The tool automatically creates parent directories and ensures files don't already exist within allowed directory boundaries.

Instructions

Create a new file with specified content.

Args: path (str): File path to create (absolute or relative to allowed directories) content (str): UTF-8 text content to write to the file

Returns: str: Success message with created file path, or error message if failed

Note: - Fails if the file already exists - Creates parent directories if they don't exist - Path must be within allowed directory roots

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
contentYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • main.py:206-230 (handler)
    The handler function for the 'create_file' MCP tool. It is registered via the @mcp.tool decorator and implements the core logic: path resolution, directory creation, file writing with UTF-8 encoding, and error handling.
    @mcp.tool
    def create_file(path: str, content: str) -> str:
        """Create a new file with specified content.
    
        Args:
            path (str): File path to create (absolute or relative to allowed directories)
            content (str): UTF-8 text content to write to the file
    
        Returns:
            str: Success message with created file path, or error message if failed
    
        Note:
            - Fails if the file already exists
            - Creates parent directories if they don't exist
            - Path must be within allowed directory roots
        """
        try:
            rp = _resolve(path)
            rp.parent.mkdir(parents=True, exist_ok=True)
            with rp.open("x", encoding="utf-8") as f:
                f.write(content)
            return f"Created {rp}"
        except Exception as e:
            return _human_error(e, "creating file")
Behavior5/5

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

With no annotations provided, the description carries the full burden and excels by disclosing key behavioral traits: it fails if the file exists (idempotency/error handling), creates parent directories automatically (side effects), and enforces path restrictions (security constraints). This goes beyond basic parameter documentation to explain how the tool behaves in practice.

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 well-structured and front-loaded with the core purpose, followed by organized sections (Args, Returns, Note). Every sentence adds value: the Args section clarifies parameters, Returns sets expectations, and the Note covers critical behavioral nuances without redundancy.

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

Completeness5/5

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

Given a mutation tool with no annotations, 2 parameters (0% schema coverage), and an output schema, the description is complete. It explains the tool's purpose, parameters, return value, and key behaviors (failure conditions, side effects, restrictions). The output schema handles return details, so the description focuses on contextual gaps effectively.

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 adds meaningful semantics: 'path' is explained as 'absolute or relative to allowed directories' with a note on restrictions, and 'content' is specified as 'UTF-8 text content'. This clarifies usage beyond the bare schema, though it doesn't detail format constraints (e.g., line endings).

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

Purpose5/5

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

The description clearly states the tool's purpose with a specific verb ('Create') and resource ('new file'), distinguishing it from siblings like 'edit_file' (modifies existing) or 'create_directory' (creates folders). It specifies 'with specified content' to differentiate from tools that might create empty files.

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 when to use this tool (to create a new file with content) and implicitly when not to use it (if the file already exists, use 'edit_file' instead). It doesn't explicitly name alternatives like 'edit_file' for existing files, but the 'Fails if the file already exists' note strongly implies the distinction.

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