MCP servers that can delete a file

4 verified servers expose a tool that can delete a file

Cleanup is part of the job: a stale config, a temp artifact, an obsolete doc that should not linger. A delete-file tool removes it at a path, on a code host or a storage service, so an agent can tidy up after itself rather than leave debris.

These verified servers let an agent delete a file.

Top pick

GitHub

GitHub

Official

GitHub's official remote MCP server for repos, issues, pull requests, Actions, and code search.

version-control30,334
Tool:
  • delete_file

On GitHub, delete_file removes a file as a commit, so the deletion is reviewable and recoverable from history like any other change.

Pick 2

Obsidian

MarkusPfundstein

Community

Let an agent read, search, and edit your Obsidian vault through the Local REST API plugin.

knowledge-base3,823
Tool:
  • delete_file

Obsidian's delete_file removes a file or a whole directory from a vault, for an agent pruning a Markdown knowledge base.

Pick 3

Gitea

Gitea

Official

Gitea's official MCP server for repos, branches, issues, pull request reviews, releases, Actions, and wikis on any Gitea instance.

version-control73
Tool:
  • delete_file

Self-hosted forges get the same: delete_file removes a file from a Gitea repository as a commit you can trace.

Pick 4

MinIO

MinIO

Official

MinIO's official MCP server lets agents browse buckets, read and write objects, manage tags and versioning, and ask AI questions about stored objects.

file-storage41
Tool:
  • delete_object

delete_object removes an object, or a specific version, from a MinIO bucket, the object-storage case where versioning decides whether it is recoverable.

What to know

Deleting is the one file operation you cannot take back, so it earns more care than a read or a write. On a code host the delete lands as a commit, which makes it recoverable from history and reviewable like any change; point it at a branch, not main, where you can. On object storage it removes an object, sometimes a specific version, and whether that is recoverable depends on whether versioning is on. Confirm the path before the call: a wrong delete is cheap to make and expensive to undo.

The real danger with an agent is a delete it does not remember making. If one run removes a file another run still expects, the second fails in a confusing way. A record of what was deleted, and why, turns a silent gap into something traceable.

Questions

Is a deleted file recoverable?
It depends where it lived. A repo delete is a commit, so the file stays in history and can be restored. An object-storage delete is recoverable only if versioning was on; otherwise it is gone. Treat object deletes as permanent unless you know versioning is enabled.
Should an agent delete straight from main?
Prefer a branch where the host supports it, the same as writing. A delete on a feature branch goes through review before it lands, which matters more once an agent can remove files on its own. Reserve direct deletes for low-stakes paths.