1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DocFS show directory tree of src" 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.

DocFS

by feli0x

Overview Schema Related Servers Score Discussions

TypeScript

DocFS

DocFS is a Model Context Protocol (MCP) server that exposes read-only file system tools to MCP clients. It supports multiple root directories, filters paths using .gitignore, and caches file metadata in an in-memory LRU cache for faster access. Requires Node.js 18 or later.

Tools

dir_tree – view directory structure as a tree
list_files – list directories and files
search_files – search text across files
read_files – read file contents

Related MCP server: mcp-file-lens

Differences from a generic filesystem MCP server

DocFS trades the broader read/write capabilities of a standard filesystem server for a narrower, read-only feature set with extra safety and convenience features:

Read-only operations only
Limited to dir_tree, list_files, search_files, and read_files
Enforces one or more user-specified root directories
Applies .gitignore rules and caches file metadata using an in-memory LRU cache

Quick Start

Add the server to any MCP-compatible client by including this JSON in its configuration:

JSON:

{
  "mcpServers": {
    "docfs": {
      "command": "npx",
      "args": ["-y", "docfs", "--root", "/path/to/project"]
    }
  }
}

Claude Code:

claude mcp add docfs -- npx -y docfs --root /path/to/project

Codex CLI:

[mcp_servers.docfs]
command = "npx"
args = ["-y", "docfs", "--root", "/path/to/project"]

Replace /path/to/project with the directory you want to expose. Repeat --root to allow multiple directories.

Development

pnpm install
pnpm format
pnpm lint
pnpm typecheck
pnpm test
pnpm build

Run DocFS on demand with npx:

npx -y docfs --root /path/to/project

License

MIT

Available Tools

4 tools

dir_treeB

Returns a nested directory tree for the specified path

ParametersJSON Schema

Name	Required	Description
`path`	No	Optional path within the root directories to list
`maxDepth`	No	Maximum directory depth to traverse (default: 5)
`includeHidden`	No	Whether to include hidden files and directories (default: false)

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It only states the basic function and does not mention edge cases, such as handling of non-existent paths, whether files are included in the tree, or how hidden files are treated. The description is too thin to be fully transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that focuses on the primary purpose. Every word earns its place, with no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has three optional parameters, no output schema, and no annotations. The description does not explain the format of the returned tree, whether it includes files, or how edge cases are handled. Given the lack of structural metadata, the description is insufficient for an agent to fully understand the tool's behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 all three parameters. The description only references the 'path' parameter and adds no extra meaning beyond what the schema provides for maxDepth and includeHidden. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the action ('Returns a nested directory tree') and the resource ('specified path'). It distinguishes itself from sibling tools like list_files (flat listing), search_files, and read_files by focusing on the tree structure.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies it should be used when a directory tree is needed, but it gives no explicit guidance on when to prefer this over list_files or search_files. No alternatives or exclusions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_filesB

Lists files and directories in the configured root directories and returns JSON data

ParametersJSON Schema

Name	Required	Description
`path`	No	Optional specific path within the root directories to list
`pattern`	No	Optional glob pattern to filter files (e.g., ".js", ".md")
`maxDepth`	No	Maximum directory depth to traverse (default: 10)
`recursive`	No	Whether to list files recursively (default: true)
`includeHidden`	No	Whether to include hidden files and directories (default: false)

TDQS

B3.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It adds useful context about the scope ('configured root directories') and output format ('returns JSON data'), but does not cover details like symlink handling, error behavior, or performance characteristics. These omissions are not critical for a read-only listing tool, but more depth would improve transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that directly states the action and output. Every word earns its place, and there is no unnecessary detail or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is relatively simple and the schema covers all parameters, but the description does not mention relationship to sibling tools or provide a return structure beyond 'JSON data'. A note on when to use this vs dir_tree would improve completeness, though the current text is minimally viable given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All five parameters are fully described in the input schema (100% coverage), so the description adds no additional parameter semantics. The baseline score of 3 applies because the schema handles parameter documentation adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists files and directories within configured root directories and returns JSON data. However, it does not explicitly distinguish this tool from the sibling 'dir_tree', which might present a similar listing in a different format.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 like search_files, read_files, or dir_tree. There is no context or exclusions, leaving the agent to infer the appropriate usage solely from the tool name and description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_filesB

Reads content from one or more files and returns JSON data

ParametersJSON Schema

Name	Required	Description	Default
`path`	No	Single file path to read (alternative to paths array)
`paths`	No	Array of file paths to read (maximum 10 files)
`endLine`	No	Ending line number (1-based, optional)
`encoding`	No	File encoding (default: utf-8)	utf-8
`startLine`	No	Starting line number (1-based, optional)
`maxFileSize`	No	Maximum file size to read in bytes (default: 1MB)
`showLineNumbers`	No	Whether to show line numbers (default: true)

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It clearly states the core behavior (reads files and returns JSON), implying a read-only operation. However, it does not disclose error handling, file size limits, or return format details, leaving some behavioral aspects undocumented.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. It efficiently conveys the tool's purpose without unnecessary verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 7 parameters and no output schema. The description only says 'returns JSON data' without specifying the structure or fields returned. It also omits information about error behavior, line range handling, or multiple file output, which are relevant for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds no parameter information beyond what the schema already provides. The mention of 'one or more files' is already captured by the path/paths properties.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reads content from one or more files and returns JSON data. This specific verb (reads) and resource (files) clearly distinguishes it from sibling tools like list_files, search_files, and dir_tree.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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. It does not state that list_files is for listing file names, search_files for searching, etc., nor does it offer any context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_filesA

Searches for text content within files and returns JSON data

ParametersJSON Schema

Name	Required	Description
`query`	Yes	The text to search for within files
`maxDepth`	No	Maximum directory depth to traverse when searching (defaults to 10)
`wholeWord`	No	Whether to match whole words only (default: false)
`maxResults`	No	Maximum number of results to return (default: 100, max: 1000)
`filePattern`	No	Optional glob pattern to filter files to search (e.g., ".js", ".md")
`contextLines`	No	Number of lines of context to show around matches (default: 2, max: 10)
`caseSensitive`	No	Whether the search should be case sensitive (default: false)

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions returning JSON data, omitting important behaviors like recursive traversal, default case-insensitivity, or result truncation. Some defaults are in the schema, but the description adds no behavioral context beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. It efficiently communicates the core function without wasting words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 7 parameters, no output schema, and no annotations, yet the description provides minimal context. It does not explain the JSON return format, result ordering, error behavior, or traversal details, leaving significant gaps for an agent to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 all 7 parameters clearly. The description adds little beyond 'text content within files', which is echoed in the query parameter description. This matches the baseline for full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Searches') and resource ('text content within files'), clearly distinguishing it from sibling tools like list_files, read_files, and dir_tree. The scope is immediately understandable and not a tautology.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies its usage: use this tool when you need to find text content within files, as opposed to listing files (list_files), reading files (read_files), or exploring structure (dir_tree). However, it does not explicitly name alternatives or state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv0.4.1Aug 2, 2026
- First observeddir_tree
- First observedlist_files
- First observedread_files
- First observedsearch_files

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation4/5

list_files and dir_tree both provide directory listings, which could cause confusion, but dir_tree is specifically a nested tree while list_files is a flat listing of files and directories. read_files and search_files are clearly distinct: one retrieves content, the other finds text within files.

Naming Consistency4/5

Three tools follow the consistent verb_noun pattern: list_files, search_files, read_files. dir_tree breaks this pattern by using a noun phrase instead of a verb_noun structure, though it is still readable and follows underscore conventions.

Tool Count5/5

Four tools form a well-scoped set for a read-only document/file access server. Each tool addresses a distinct core operation: listing, searching, reading, and showing structure, without unnecessary bloat.

Completeness4/5

The read-side workflows are well covered: discovering files, viewing directory structure, searching content, and reading file contents. Missing write/update/delete operations are likely out of scope for a read-only document server, but if the intent is a full file system, these would be notable gaps.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Git Diff Mcp
io.github.varvararatta
MCP server for git_diff_mcp
Version Control Developer Tools
2
Moxt Workspace
ai.moxt
Browse and manage files in your Moxt AI workspace from any MCP client.
File Systems Developer Tools
2
saagarpatel.dev Portfolio A
io.github.saagpatel
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Search Documentation Access
82
neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320

Related MCP Servers

MCP Filesystem Python
File Systems Code Execution Developer Tools
mtunell
-
license
Not graded
quality
Not graded
maintenance
A secure MCP server enabling read-only access and file search capabilities within a specified directory, while respecting .gitignore patterns.
Updated 2 years ago (2025-01-04 20:06 UTC)
-
mcp-file-lens
File Systems Code Analysis Developer Tools
solatis
A
license
Not graded
quality
C
maintenance
An MCP server that provides a flexible lens into directory structures and files, enabling LLM clients to efficiently navigate and understand codebases with minimal noise. It offers secure, gitignore-aware file access with tools like directory listing, file reading, and grep-like search.
Updated a year ago (2025-06-22 07:50 UTC)
1
MIT
MCP Filesystem Python
File Systems Developer Tools
gary109
A
license
B
quality
D
maintenance
A secure, read-only MCP server for browsing and searching files in a specified directory with path traversal protection and .gitignore support.
Updated 2 years ago (2025-01-05 05:05 UTC)
3
MIT
filesystem-gitignore
File Systems Developer Tools
mvecchiett
A
license
Not graded
quality
D
maintenance
A professional MCP server that provides filesystem operations while automatically respecting .gitignore patterns, enabling efficient and token-friendly file access for Claude.
Updated 10 months ago (2025-11-20 16:03 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/feli0x/docfs'

If you have feedback or need assistance with the MCP directory API, please join our Discord server