Claude MCP - How To Modify Your Servers To The Next Level

A practical workaround for Claude’s Model Context Protocol (MCP) limitations lets users add an “execute file” capability to a local file-system MCP server—turning a read/write tool into one that can run code, capture output, and even spin up a local website. The core idea is to run the MCP file system server locally (so it can be extended), then modify its TypeScript implementation to include a new tool that executes selected file types and returns stdout/stderr results. That single change unlocks workflows like generating Python scripts, running Node.js programs, and serving a web page from localhost.

The walkthrough starts with the official MCP file system server and narrows in on the “file system” service files (readme, index.ts, package.json, tsconfig.json). Instead of cloning everything, it creates a local “servers/file system” setup in a Cursor workspace, copies in the server code, and adds the necessary TypeScript configuration. A key operational step is generating or locating the Claude Desktop MCP configuration file (via a PowerShell command on Windows) and pointing it to the compiled server entry (index.js) inside the local MCP2 servers folder. After installing dependencies with npm install and launching Claude Desktop (run as admin on Windows), the file system tools appear and can save artifacts to an allowed directory.

To prove the extension works, the guide demonstrates writing Python code through the MCP file system tool—saving a script that adds two integers and writes the result to a file. Then it moves to the main modification: implementing an “execute file tool” inside the existing index.ts server. The new tool is designed to run Python and Node commands, capture standard output, and return execution results back to Claude. After rebuilding (npm run build) and restarting Claude Desktop, the tool count increases (e.g., from 11 to 12), and the new execute capability becomes available.

A test prompt writes a Python script to find the next prime number, then runs it via the execute tool. The output confirms the tool executes the saved file and captures results like “next prime,” with test cases such as inputs 10, 20, and 100 passing.

The final demonstration escalates from code execution to local web hosting. Using the execute capability, the guide attempts a “one-shot” build: creating a web page folder containing index.html, server.js, styles.css, and a main JS/TS file, then running server.js on localhost:3000. When npm and pip commands are initially missing from the allowed command set, the server configuration is updated to permit them, followed by another build and restart. With npm install enabled, dependencies can be installed, server.js can be launched, and the browser loads the retro terminal-styled landing page.

The closing takeaway is a tradeoff: enabling file execution increases risk, but the risk can be managed by restricting which file types and commands are allowed (the guide emphasizes avoiding dangerous executables like .exe). The result is a more capable MCP server that can be tailored to specific needs—whether extending the file system server itself or modifying other community MCP servers for custom workflows.