MCP servers that can read a file
5 verified servers expose a tool that can read a file's contents
Plenty of agent work starts with reading a file it did not write: a config in a repo, a note in a vault, a document on a server. A read-file tool fetches the contents by path so the model can reason over what is actually there, not a guess about it.
These verified servers let an agent read a file's contents, across repos, vaults, and storage.
GitHub
GitHub
GitHub's official remote MCP server for repos, issues, pull requests, Actions, and code search.
get_file_contents
get_file_contents reads a file or directory from a GitHub repository at a chosen ref, the first call a coding agent makes before it proposes an edit.
Obsidian
MarkusPfundstein
Let an agent read, search, and edit your Obsidian vault through the Local REST API plugin.
get_file_contents
get_file_contents returns a single note from your Obsidian vault, for agents reasoning over a personal or team knowledge base kept in Markdown.
Gitea
Gitea
Gitea's official MCP server for repos, branches, issues, pull request reviews, releases, Actions, and wikis on any Gitea instance.
get_file_content
get_file_content returns a file's content and metadata from a self-hosted Gitea repo, the same read step on a forge you run in-house.
Nextcloud
Chris Coutinho
Production-ready community MCP server for Nextcloud: files, notes, calendar, contacts, tables, deck, talk, and more across 110+ tools.
nc_webdav_read_file
nc_webdav_read_file reads a file over WebDAV, the way in when the document lives in Nextcloud storage rather than a code host.
MediaWiki
Professional Wiki
A maintained MCP server that connects an agent to any MediaWiki — including Wikipedia — to search, read, create, and edit pages.
get-file
get-file fetches a file page from a MediaWiki instance, useful when the content an agent needs sits in a wiki.
What to know
Where the file lives shapes the tool. A code-host read pulls a file from a repository at a branch or commit, which is what a coding agent needs before it edits. A vault or wiki read fetches a note by its path in a knowledge base. A storage read pulls bytes over a protocol like WebDAV. They all return contents, but the addressing differs: a repo path and ref, a vault-relative path, a storage URL.
Reading is cheap and repeatable, so there is rarely a reason to cache the bytes. What is worth remembering is what the agent learned from the file, the config value or the function signature, so a later session starts from that instead of re-reading the same file to recover it.
Questions
- Can the agent read a file at a specific commit?
- On the code hosts, yes. GitHub's get_file_contents and Gitea's get_file_content take a branch, tag, or commit, so an agent can read a file as it was at a point in history, not just the current tip. The vault and storage reads return the current file at its path.
- What is the difference between these reads?
- The addressing. A repo read needs a path and a ref; a vault read uses a path relative to the vault; a WebDAV read uses a storage path. All return the file's contents, so pick the server that matches where your file actually lives.