Click on "Install 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., "@FastApply MCP Server dry run adding error handling to parse_config in src/utils.py"
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.
A streamlined Model Context Protocol server for efficient AI-powered code editing using FastApply. Inspired by opencode-fast-apply's simplicity and partial editing approach.
FastApply MCP Server provides intelligent code editing through partial file editing, achieving 80-98% token savings compared to full-file approaches. The server uses smart matching to locate and replace code sections automatically, making it ideal for editing large files efficiently.
Related MCP server: AI Diff Review MCP
Partial File Editing: Edit only the sections you need (50-500 lines recommended)
Smart Matching: Automatic exact and normalized whitespace matching
XML Safety: Built-in protection against prompt injection
Token Efficiency: 80-98% token savings vs full-file editing
Binary Detection: Automatic detection and rejection of binary files
Atomic Operations: Safe file writes with automatic rollback on failure
Clear Error Messages: Actionable suggestions for troubleshooting
Python 3.13 or higher
FastApply-compatible server (LM Studio, Ollama, or OpenAI-compatible endpoint)
Run directly without installation:
uvx fastapply-mcpgit clone https://github.com/your-org/fastapply-mcp.git
cd fastapply-mcp
# Using uv
uv sync
source .venv/bin/activate
uv pip install -e .
# Or using pip
pip install -e .Configure the server with just 3 environment variables:
# .env file
FAST_APPLY_URL=http://localhost:1234/v1
FAST_APPLY_MODEL=fastapply-1.5b
FAST_APPLY_API_KEY=optional-api-keyThat's it! No complex configuration needed.
Add to your Claude Desktop configuration:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"fastapply": {
"command": "uvx",
"args": ["fastapply-mcp"],
"env": {
"FAST_APPLY_URL": "http://localhost:1234/v1",
"FAST_APPLY_MODEL": "fastapply-1.5b"
}
}
}
}{
"mcpServers": {
"fastapply": {
"command": "python",
"args": ["/path/to/fastapply-mcp/src/fastapply_mcp/main.py"],
"env": {
"FAST_APPLY_URL": "http://localhost:1234/v1",
"FAST_APPLY_MODEL": "fastapply-1.5b"
}
}
}
}The server implements the standard MCP protocol and works with any compatible client.
The server provides a single, focused tool for efficient code editing.
target_filepath (required): Path to the file to edit (relative or absolute)
original_code (required): The exact section of code to modify (50-500 lines recommended)
code_edit (required): The changes to apply
Read the file to get current content
Extract the relevant section (50-500 lines with context)
Call FastApply API with partial content
Smart match finds the section in the full file
Replace the section atomically
Generate diff for verification
{
"target_filepath": "src/utils.py",
"original_code": "def parse_config(path):\n with open(path) as f:\n return json.load(f)",
"code_edit": "def parse_config(path):\n try:\n with open(path) as f:\n return json.load(f)\n except FileNotFoundError:\n raise ConfigError(f'Config not found: {path}')"
}Use ... existing code ... markers for unchanged sections:
# ... existing code ...
def updated_function():
return "modified"
# ... existing code ...This tells the AI to skip regenerating unchanged parts, making edits faster.
Partial editing provides massive token savings:
File Size | Full File | Partial (100 lines) | Savings |
100 lines | 2,500 tokens | 500 tokens | 80% |
500 lines | 12,500 tokens | 1,000 tokens | 92% |
1000 lines | 25,000 tokens | 1,500 tokens | 94% |
5000 lines | 125,000 tokens | 2,000 tokens | 98% |
The tool uses a two-tier matching system:
Finds exact string match in the file.
Handles CRLF/LF differences automatically:
Normalizes \r\n ā \n
Normalizes \r ā \n
Matches whitespace-normalized content
Ensures the section appears only once in the file to prevent ambiguous replacements.
Built-in protection against prompt injection:
# User code with XML tags
original_code = "<code>malicious</code>"
# Automatically escaped before API call
# "<code>malicious</code>"
# Safely processed and unescaped afterAll XML special characters (&, <, >, ", ') are automatically escaped and unescaped.
Install LM Studio from https://lmstudio.ai
Download a FastApply-compatible model
Start the local server (default: http://localhost:1234)
Configure FAST_APPLY_URL=http://localhost:1234/v1
# Install Ollama
curl -fsSL https://ollama.com/install.sh | sh
# Pull a FastApply model
ollama pull fastapply-1.5b
# Start the server
ollama serveConfigure FAST_APPLY_URL=http://localhost:11434/v1
Any OpenAI-compatible API works:
FAST_APPLY_URL=https://api.openai.com/v1
FAST_APPLY_MODEL=gpt-4
FAST_APPLY_API_KEY=sk-...Workspace Isolation: All operations confined to current working directory
Path Validation: Prevents directory traversal attacks
File Size Limits: 10MB default maximum
Binary Detection: Rejects binary files automatically
UTF-8 Validation: Ensures proper file encoding
Atomic Writes: Safe file operations with rollback
Clear, actionable error messages:
ā Error: Cannot locate original_code in file (whitespace mismatch detected).
š” Troubleshooting:
1. Re-read the file to get current content
2. Ensure original_code matches exactly (including whitespace)
3. Provide more context to make the section uniqueVerify your FastApply server is running:
curl http://localhost:1234/v1/modelsUse the tool only for existing files. For new files, use your MCP client's write tool.
Re-read the file to get current content
Ensure whitespace matches exactly (tabs vs spaces)
Provide more context to make the section unique
The tool handles CRLF/LF differences automatically, but tabs vs spaces must match exactly.
fastapply-mcp/
āāā src/
ā āāā fastapply_mcp/
ā āāā __init__.py
ā āāā main.py # Single-file implementation (~487 lines)
āāā .env.example
āāā pyproject.toml
āāā README.md# Format code
ruff format .
# Lint code
ruff check .
# Type checking
mypy src/
# Syntax check
python -m py_compile src/fastapply_mcp/main.pyThis implementation follows these principles:
Do one thing well - Focus on efficient file editing
Trust the client - MCP client handles undo, concurrency, etc.
Optimize for common case - Partial editing is 10x more efficient
Clear errors - Help users fix problems quickly
No premature optimization - Remove unused features
Read: 5000 lines
Send to API: 125,000 tokens
Process: ~30 seconds
Cost: High
Read: 5000 lines (send only 100)
Send to API: 2,000 tokens
Process: ~3 seconds
Cost: 98% cheaper
Contributions are welcome! Please:
Fork the repository and create a feature branch
Write tests for new functionality
Ensure code meets quality standards
Submit a pull request with clear description
MIT License - see LICENSE file for details.
Inspiration: opencode-fast-apply for the partial editing approach
MCP Community: For the Model Context Protocol specification
FastApply: For the efficient code merging models
GitHub Issues: Report bugs and request features
Discussions: Ask questions and share ideas
Documentation: See inline code comments for implementation details
Handle tool calls.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| arguments | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Handle tool calls' reveals almost nothing about the tool's behavior - it doesn't indicate whether this executes tools, validates calls, routes requests, or performs other operations. It provides no information about permissions, side effects, error handling, or response characteristics.
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 maximally concise at just three words. There's no wasted language or unnecessary elaboration. While this conciseness comes at the expense of clarity, the description itself is efficiently structured with zero 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 that this appears to be a core tool invocation mechanism with 2 required parameters, nested objects in the schema, and an output schema, the description is completely inadequate. 'Handle tool calls' doesn't explain what the tool does, how to use it, what it returns, or how it relates to the sibling 'list_tools' tool. The presence of an output schema helps, but the description provides insufficient context for 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 0%, so the description must compensate for the completely undocumented parameters. The description provides no information about what 'name' and 'arguments' represent, their expected formats, or how they should be used. With 2 required parameters that have no schema documentation, this represents a significant gap.
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 'Handle tool calls' is tautological - it essentially restates the tool name 'call_tool' without adding meaningful specificity. It doesn't clarify what 'handle' means in this context (invoke? execute? manage?) or what types of tools are being called. While it distinguishes from 'list_tools' by implying action rather than listing, the purpose remains vague.
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 about when to use this tool versus alternatives. The description doesn't indicate whether this is for invoking specific tools, executing tool workflows, or managing tool calls. With a sibling tool 'list_tools' available, there's no indication of the relationship between listing tools and calling them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return metadata for available tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does without behavioral details. It doesn't disclose if it's read-only, has rate limits, authentication needs, or what metadata format is returned, which is insufficient for a 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, clear sentence with no wasted words, effectively front-loading the core functionality. It's appropriately sized for a simple tool with no parameters.
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 has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, it lacks behavioral context and usage guidelines, which are gaps despite the structured data covering parameters and outputs.
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, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add param info, but that's acceptable here, warranting a baseline score above 3 due to the lack of parameters.
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 ('Return') and resource ('metadata for available tools'), making the purpose unambiguous. However, it doesn't differentiate from its sibling 'call_tool', which appears to be an execution tool versus this metadata retrieval tool, missing explicit sibling 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?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about its role relative to 'call_tool' or any prerequisites, leaving usage unclear beyond the basic purpose.
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. Dates show when Glama detected each change.
call_toollist_toolsThe two tools have clearly distinct purposes: call_tool handles tool execution, while list_tools provides metadata about available tools. There is no overlap or ambiguity between these functions, making it easy for an agent to select the correct tool.
Both tools follow a consistent verb_noun naming pattern (call_tool and list_tools) with the same snake_case convention. This predictability aids in understanding and usage without any deviations.
With only 2 tools, this server feels thin and under-scoped for most practical applications. While it covers basic MCP functionality, it lacks domain-specific operations that would justify a dedicated server, making the count too low for effective agent use.
The tool surface is severely incomplete for any meaningful domain. It only provides meta-operations (calling and listing tools) without any actual functionality for a specific purpose, leaving obvious gaps that will cause agent failures in real-world tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP-native collaborative markdown editor with real-time AI document editing
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
Adaptive plan/build/review cycles for AI coding assistants, persisted across sessions.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tickernelz/fastapply-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
