Provides comprehensive Git repository management including initialization, cloning, staging, commits, branch operations, push/pull, and commit history inspection.
Enables GitHub integration through CLI for creating pull requests and managing repositories.
Supports Mercurial version control system integration for repository synchronization.
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., "@AI FileSystem MCP find all Python files modified in the last week and show me their complexity scores"
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.
Your AI agent's Edit isn't atomic. This MCP makes it so.
A single-tool MCP server for atomic multi-file changes with automatic rollback — built for Claude Code, Codex CLI, Cursor agents, and other modern coding agents.
Those agents ship with excellent built-in tools for reading, writing, searching, editing, and shell. They do not ship with a primitive for "apply these N file operations as one transaction; if any of them fail, revert everything." That is the one and only thing this MCP provides.
transaction — apply a batch of file operations atomically.
{
"name": "transaction",
"arguments": {
"operations": [
{ "type": "create", "path": "src/feature.ts", "content": "..." },
{ "type": "write", "path": "src/index.ts", "content": "..." },
{ "type": "update", "path": "src/lib/util.ts",
"updates": [{ "oldText": "foo()", "newText": "foo(arg)" }] },
{ "type": "move", "path": "src/old.ts", "destination": "src/legacy/old.ts" },
{ "type": "delete", "path": "src/dead.ts" }
],
"rollbackOnError": true
}
}If operation 4 fails, operations 1-3 are restored from backup before the call returns. If everything succeeds, backups are cleaned up.
| Required fields | What it does |
|
| Make a new file (creates parent dirs). |
|
| Overwrite an existing file. |
|
| In-place |
|
| Rename |
|
| Remove a file or directory (recursive). |
Related MCP server: File Operation MCP Server
Earlier 2.x versions shipped 39 commands: file I/O, search, git, code analysis, shell, archives, diffs, metadata, encryption, file watcher. Modern coding agents already do all of that better with their own Read / Edit / Write / Grep / Glob / Bash tools — wrapping those in MCP only adds latency and a new failure surface.
What an agent's Edit cannot do is treat several file changes as one
unit of work. If op 4 of 5 fails, ops 1-3 are already on disk. Until
the agent grows a real transaction primitive, that gap is filled
externally — which is the entire job of this server.
You probably don't need it for a typical "fix this bug" turn. You do need it when a single logical change must touch several files together:
DB migration: schema file + matching ORM model + matching test fixtures must all land or all revert.
Cross-cutting rename / refactor that spans many files and would half-apply if the agent crashes or runs out of context mid-stream.
Generated-code updates where the generator output and the hand-edited glue must stay in sync.
Config + corresponding code change (e.g. routing table entry + handler), where the half state is broken.
If your edit fits in one file, just use the agent's Edit. If it
fits in one shell command, just use Bash. Reach for transaction
only when "all or nothing" actually matters.
Requires Node.js ≥ 18.
npm install -g ai-filesystem-mcpOr from source:
git clone https://github.com/proofmath-owner/ai-filesystem-mcp.git
cd ai-filesystem-mcp
npm install
npm run build
node dist/index.js{
"mcpServers": {
"ai-filesystem": {
"command": "node",
"args": ["/absolute/path/to/ai-filesystem-mcp/dist/index.js"]
}
}
}Speaks stdio JSON-RPC. No network ports.
Runs locally beside a trusted AI agent as the user that started it. There is no path sandbox; the trust boundary is your machine. Do not expose to untrusted clients.
npm install
npm run dev # tsx watch on src/index.ts
npm run build # tsc -> dist/
npm run lint
npm run formattsc errors fail the build. No tsc || true.
MIT
Apply a batch of file create/write/update/move/delete operations atomically. If any operation fails (and rollbackOnError is true, the default), all prior operations in the batch are reverted from on-disk backups. This is the one thing the agent's built-in per-file Edit cannot do.
| Name | Required | Description | Default |
|---|---|---|---|
| operations | Yes | Ordered list of file operations to execute as one atomic batch. | |
| rollbackOnError | No | When true (default), any failure rolls all completed ops in the batch back from backup. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Disclosures atomicity, rollback on failure, and default behavior of rollbackOnError. No annotations provided, so description carries full burden; it adequately informs about core behavior but does not mention success outcomes or side effects beyond rollback.
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?
Two concise sentences, front-loaded with the core purpose, followed by a key differentiator. No superfluous information.
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's complexity (two parameters, one nested array) and no output schema, the description covers atomicity, rollback, and operation types adequately. Lacks explanation of return value or error handling details, but the core use case is clear.
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 100%, so the schema already documents parameters fully. The description adds minimal extra context (e.g., 'from on-disk backups') but does not significantly enhance understanding beyond the schema.
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?
Clearly states the verb 'apply', resource 'batch of file operations', and atomicity. Distinguishes from the agent's built-in Edit by noting this is something it cannot do, providing sibling differentiation.
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?
Explicitly contrasts with the agent's per-file Edit, implying when to use this tool (for atomic batch operations). Lacks explicit when-not-to-use or alternatives beyond that single comparison.
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.
v4.0.0analyze_codebatch_operationschange_permissionscompress_filescreate_directorydecrypt_filediff_filesencrypt_fileexecute_shellextract_archivefile_watcherformat_codefuzzy_searchget_file_metadatagit_addgit_branchgit_checkoutgit_clonegit_commitgit_initgit_loggit_pullgit_pushgit_statusgithub_create_prlist_directorymodify_codemove_fileread_fileread_filesscan_secretssearch_contentsearch_filessecurity_auditsemantic_searchshellsuggest_refactoringtransaction11 fields changedInput schema / properties / operations / descriptionPrevious value: -"List of file operations to execute"New value: +"Ordered list of file operations to execute as one atomic batch."Input schema / properties / operations / items / additionalPropertiesAdded value: +falseInput schema / properties / operations / items / properties / content / descriptionPrevious value: -"Content for create/update operations"New value: +"Required for \"create\" and \"write\"."Input schema / properties / operations / items / properties / destinationAdded value: +{
+ "description": "Required for \"move\" (new path).",
+ "type": "string"
+}Input schema / properties / operations / items / properties / encodingRemoved value: -{
- "default": "utf8",
- "description": "File encoding",
- "type": "string"
-}Input schema / properties / operations / items / properties / path / descriptionPrevious value: -"File path for the operation"New value: +"Target file or directory path."Input schema / properties / operations / items / properties / type / descriptionPrevious value: -"Type of operation"New value: +"Operation kind. create=new file, write=overwrite, update=text replace, move=rename, delete=remove."Input schema / properties / operations / items / properties / type / enumPrevious value: -[
- "create",
- "read",
- "update",
- "delete"
-]New value: +[
+ "create",
+ "write",
+ "update",
+ "move",
+ "delete"
+]Input schema / properties / operations / items / properties / updatesAdded value: +{
+ "description": "Required for \"update\". Each entry is { oldText, newText } and is applied in order via string replace.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "newText": {
+ "type": "string"
+ },
+ "oldText": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "oldText",
+ "newText"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Input schema / properties / operations / minItemsAdded value: +1Input schema / properties / rollbackOnError / descriptionPrevious value: -"Whether to rollback all operations if any fails"New value: +"When true (default), any failure rolls all completed ops in the batch back from backup."update_filewrite_filev2.0.0analyze_codebatch_operationschange_permissionscompress_filescreate_directorydecrypt_filediff_filesencrypt_fileexecute_shellextract_archivefile_watcherformat_codefuzzy_searchget_file_metadatagit_addgit_branchgit_checkoutgit_clonegit_commitgit_initgit_loggit_pullgit_pushgit_statusgithub_create_prlist_directorymodify_codemove_fileread_fileread_filesscan_secretssearch_contentsearch_filessecurity_auditsemantic_searchshellsuggest_refactoringtransactionupdate_filewrite_fileWith only one tool, there is no ambiguity between tools. The single tool has a clearly defined purpose.
With a single tool, naming is trivially consistent. The name 'transaction' is descriptive and fits the tool's purpose.
A single tool for a file system server is too few. The server's purpose implies a need for multiple operations, but only a batch transaction tool is provided.
The server severely lacks basic file operations (read, write, list, etc.). It only offers a batch transaction tool, which is a narrow supplement, not a complete file system interface.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Manage files and folders directly from your workspace. Read and write files, list directories, cre…
Access the GitHub API, enabling file operations, repository management, search functionality, and…
Securely search and manage workspace context files for AI agents and teams.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/proofmath-owner/ai-filesystem-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server