Filesystem MCP Server

Official

by modelcontextprotocol

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2026.7.10
Disambiguation3/5
Some tools overlap in purpose: list_directory and list_directory_with_sizes are nearly identical except for size output; read_file is deprecated in favor of read_text_file, causing confusion. Other tools are distinct but descriptions could be clearer to avoid misselection.
Naming Consistency4/5
Most tools follow a verb_noun pattern (e.g., create_directory, edit_file, read_text_file). directory_tree is a minor deviation as noun_noun. Overall consistent with one exception.
Tool Count5/5
14 tools is well-scoped for a filesystem server. Each tool serves a clear purpose, covering reading, writing, editing, listing, searching, and metadata retrieval without unnecessary bloat.
Completeness2/5
Missing critical operations: there is no tool to delete files or directories, and no copy functionality. This creates significant gaps that will hinder agents from performing basic file management tasks.
Average 3.9/5 across 14 of 14 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 348 of 437 community issues answered or closed in the last 6 months
- 33 commits in the last 12 weeks
- Last stable release on July 10, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Inno Setup License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds that output prefixes [FILE] and [DIR] and the allowed-directories constraint, but does not disclose other behavioral aspects like recursive behavior or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences that are efficient and front-loaded. No wasted words, though could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool with one parameter and an output schema. Covers purpose, output format, and a constraint. Lacks error handling details but that is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It mentions 'specified path' but provides no details on path format, validation, or behavior (e.g., relative vs absolute).
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?
Clearly states it gets a detailed listing of files/directories with specific prefixes. Distinguishes from siblings implicitly but does not name alternatives.
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?
Only mentions the constraint 'Only works within allowed directories', but provides no guidance on when to use this tool versus sibling tools like directory_tree or list_directory_with_sizes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=false. The description adds that results use [FILE] and [DIR] prefixes and include sizes, which is useful behavioral context, but does not mention sorting behavior or performance implications. Moderate value added beyond annotations.
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 two sentences, directly addressing purpose, output format, utility, and a key constraint. No unnecessary words, well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, it's appropriate not to detail return values. The description covers output format (prefixes), purpose, and scope. It mentions nothing about the sortBy parameter, but the overall information is sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 50% of parameters have schema descriptions (sortBy is described, path is not). The description only says 'specified path' without adding format, restrictions, or examples for the path parameter, offering minimal help beyond the schema.
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 states it lists files/directories with sizes and distinguishes with prefixes, making the purpose clear. However, it does not explicitly differentiate from sibling tool 'list_directory', which may only list names without sizes, but the distinction is implied.
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 says it's useful for understanding structure and finding files, and mentions the allowed-directories constraint. It does not provide explicit guidance on when to use this tool versus siblings like 'directory_tree' or 'list_directory', leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, and the description adds behavioral details such as base64 encoding, MIME type determination, and handling of image/audio vs other file types. It also mentions directory constraints, adding value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is contained in a single sentence that front-loads the purpose. It is succinct without waste, but could benefit from slightly more structure (e.g., separate sentences for constraints).
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?
Given the output schema exists, description does not need to detail return values. However, it lacks full context about file size limits, allowed MIME types specifically, and clear differentiation from similar siblings (read_file, read_text_file). Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. It only mentions 'within allowed directories' for the path parameter, but does not explain path format, absolute/relative, or any additional constraints. The schema only defines path as a string, leaving ambiguity.
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 'Read a file and return it as a base64-encoded content block with its MIME type', specifying the exact action and output format. It distinguishes from siblings like read_file or read_text_file by emphasizing base64 encoding and MIME type handling.
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?
The description only notes 'Only works within allowed directories' but does not provide explicit guidance on when to use this tool versus alternatives. It lacks 'when-not' or comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description adds valuable behavioral details: output structure with children arrays, formatting, recursion, and the constraint of working only within allowed directories.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, concise and front-loaded with the main purpose. It could be slightly improved by structuring parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and two parameters, the description covers output structure, recursion, and allowed directories. It lacks discussion of performance implications but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the tool description provides no explanation for the 'path' or 'excludePatterns' parameters, leaving their meaning and usage unclear.
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 returns a recursive tree view of files and directories as JSON, using specific verb and resource. It distinguishes from sibling tools like list_directory which provides a flat list.
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 lacks explicit guidance on when to use this tool vs alternatives. It implies recursive use but does not compare to siblings like list_directory or list_directory_with_sizes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already show destructiveHint=true and readOnlyHint=false. The description adds that edits replace exact line sequences and returns a diff. However, it does not disclose behavior when oldText is not found or multiple matches occur, which is needed given the destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main action. No wasted words, though could include the dryRun preview mention more prominently. Efficient for the information provided.
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?
Given the destructive nature and the availability of an output schema (not shown but noted), the description covers the main behavior and return (git-style diff). However, it lacks guidance on dryRun usage, error cases, or safety, leaving some gaps for a tool that modifies files.
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 33%; only dryRun has a description. The description adds that each edit replaces exact line sequences and that oldText must match exactly, providing some meaning beyond the schema for the edits parameter, but does not fully compensate for missing parameter descriptions, especially path.
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 specific verbs and resources ('Make line-based edits to a text file'), clearly distinguishes from siblings like write_file by focusing on line-based edits and returning a diff. It is unambiguous and actionable.
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 states a constraint ('Only works within allowed directories') but does not explicitly guide when to use this tool vs alternatives like write_file or search_files. Usage context is implied but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent behavior. The description adds valuable context: 'Handle text content with proper encoding' and 'Only works within allowed directories', which are beyond annotation and aid safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently cover purpose, caution, encoding, and scope. No redundancy, though additional parameter details could be added without bloating.
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?
Given the simple tool with two parameters and an output schema, the description covers key behavioral points but lacks parameter detail. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters, but it only mentions 'text content' without specifying path format or content constraints. No examples or additional semantic guidance is provided.
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 explicitly states the tool creates a new file or completely overwrites an existing file, distinguishing it from siblings like edit_file. The verb 'create' and 'overwrite' plus resource 'file' leave no ambiguity.
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 caution about overwriting without warning provides usage guidance, but it does not explicitly compare with edit_file or state when to use this over other file tools. The sibling list implies alternatives, but direct guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so description's 'read' is consistent. It adds that head/tail can limit lines, but no additional side effects, auth needs, or rate limits. Beyond annotations, adds moderate context.
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?
Two sentences: first states action, second delivers deprecation notice. Front-loaded, no redundant phrasing. Every sentence is useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is deprecated and has identical functionality as read_text_file (a sibling), the description covers purpose, deprecation, and alternative. Output schema exists (not shown), so no need to explain return values. Complete for its context.
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 67% (head and tail have descriptions, path lacks one). Description mentions 'complete contents' implying path is the file, but does not elaborate on other parameters beyond what schema already provides. Baseline mid-level due to partial 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?
Description states 'Read the complete contents of a file as text' with specific verb and resource. Explicitly notes deprecation and recommends 'read_text_file', distinguishing it from sibling tools.
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?
Explicitly indicates deprecation and directs to use 'read_text_file'. This is strong guidance, but does not cover other contexts where head/tail parameters might be used or call out alternatives for those cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and openWorldHint, which are consistent. The description adds value by noting that 'Failed reads for individual files won't stop the entire operation', which is a key behavioral trait not captured by annotations. This helps the agent understand partial failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the core purpose. It avoids redundancy and each sentence offers useful information. Slightly longer than minimal but justified by the additional behavioral details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool handles multiple files with partial failures, the description covers efficiency, batch operation, failure handling, and directory restriction. With an output schema present, return format is documented. It provides sufficient context for an agent to use 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 coverage is 100%, so baseline is 3. The description reinforces that each path must be a string within allowed directories, but adds no new meaning beyond the schema's description. It does hint at the output format (content with path reference), but that's more about return values than parameter semantics.
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 starts with 'Read the contents of multiple files simultaneously', clearly stating the verb and resource. It distinguishes from sibling tools like 'read_file' by highlighting batch efficiency and the ability to handle multiple files at once.
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 says this tool is 'more efficient than reading files one by one', providing a clear use case. It also mentions that failed reads won't stop the operation and that it only works within allowed directories, offering practical guidance. However, it could explicitly 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description adds specific behavioral details: the operation fails if the destination exists, and it works across directories. It also notes the allowed directories constraint. These details help the agent understand error conditions and scope, which annotations alone do not provide.
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 concise with five sentences, each adding distinct value: primary function, combined operation capability, failure condition, cross-directory scope, and directory constraint. No redundant or irrelevant information. Information is front-loaded and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, straightforward purpose), the description covers all key aspects: action, success conditions, failure conditions, and constraints. The existence of an output schema means return values need not be described. The description is complete for an agent to decide when and how to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate but only adds the constraint that both paths must be within allowed directories. It does not explain format (absolute/relative), validation rules, or the meaning of source vs destination beyond their names. The names are self-explanatory, but the description adds minimal value for parameter understanding.
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 moves or renames files and directories, with specific verbs and resource. It distinguishes from sibling tools like edit_file and write_file by focusing on relocation/rename rather than content modification. The mention of 'single operation' and 'within allowed directories' further clarifies its scope.
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 provides clear context: it can move between directories and rename within the same directory. It states a critical condition ('If the destination exists, the operation will fail') and a constraint ('Both source and destination must be within allowed directories'). However, it lacks explicit alternatives or when-not-to-use guidance, but the context is sufficient for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds that it returns full paths, recursively searches, and is limited to allowed directories. It does not mention hidden files or case sensitivity, but it is sufficient for a read-only tool.
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 paragraph of five sentences, front-loaded with the main action, and every sentence adds necessary information without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the search behavior, pattern syntax, and allowed scope. Since an output schema exists, return values need not be explained. It is fairly complete, but could mention the role of the path parameter and the excludePatterns functionality.
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?
The schema has 0% coverage, so the description must compensate. It explains the pattern parameter in detail with examples but does not explain the path parameter (the starting directory) or the excludePatterns parameter. Thus it adds meaning for one key parameter but leaves gaps for others.
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 it recursively searches for files and directories matching a glob-style pattern, and the verb 'search_files' combined with the explanation differentiates it from siblings like list_directory and get_file_info. It is specific about pattern types and scope.
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 provides clear context: 'Great for finding files when you don't know their exact location' and notes it only searches within allowed directories. However, it does not explicitly exclude alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and closed-world behavior. The description adds specific metadata fields returned and the directory restriction, providing useful context beyond annotations.
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?
Three sentences, each providing distinct value: purpose, return details, and usage constraint. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with an output schema, the description covers purpose, behavior, and constraints adequately. The output schema handles return value documentation.
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?
The single 'path' parameter has 0% schema description coverage. The description clarifies it expects a file or directory within allowed directories, but lacks format details or examples. This partially compensates for the missing schema docs.
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 retrieves detailed metadata (size, time, permissions, type) for files or directories, distinguishing it from siblings that read content or list entries.
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 explains when to use (to understand file characteristics without reading content) and includes a constraint (only works within allowed directories). However, it does not explicitly list alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description adds useful behavioral details: handles various text encodings, provides detailed error messages, and operates as text regardless of extension. No contradictions.
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?
Four sentences, front-loaded with purpose, each sentence adds value: encoding handling, usage context, parameter details, and restrictions. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool, the description covers purpose, usage context, parameter guidance, restrictions, and behavioral details. Output schema exists, so return format is not needed. It is thorough for the tool's 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?
The description explains the head and tail parameters (first N lines, last N lines), but these descriptions largely repeat the schema. The path parameter is not elaborated beyond the name. Given 67% schema coverage, the description adds marginal value.
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 specifies a clear verb ('Read') and resource ('file as text'), and distinguishes from siblings like read_multiple_files by stating 'single file'. It also mentions handling encodings and error messages, making the purpose unambiguous.
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 explicitly states when to use this tool ('examine contents of a single file') and provides guidance on head/tail parameters. However, it does not explicitly mention when not to use it or compare with other tools like read_file.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint=true and destructiveHint=false, and the description elaborates by explaining that nested directories can be created in one operation and that existing directories are handled silently. The constraint of allowed directories is also stated, adding transparency beyond structured data.
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 concise with four clear sentences. Each sentence adds unique value: core function, nested/idempotent behavior, use case, and access restriction. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description covers creation behavior, idempotency, nesting, and allowed-directories constraint. It is complete enough for an agent to understand when and how to invoke the tool.
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?
With 0% schema description coverage, the description carries the full burden. It implies the path parameter supports nested creation, but does not detail format (e.g., absolute vs relative, trailing slash). The meaning is sufficient but not fully explicit.
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 creates directories or ensures they exist, with nested creation capability. The verb 'Create' and resource 'directory' are specific, and the scope 'Only works within allowed directories' differentiates it from siblings that operate on files or list directories.
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 provides context suggesting use for setting up directory structures or ensuring paths exist, but does not explicitly compare to alternatives or state when not to use. However, given no sibling tool duplicates this functionality, the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that subdirectories within allowed directories are also accessible, which is not covered by annotations (readOnlyHint, openWorldHint). This provides useful context beyond the structured fields. No contradictions.
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?
Two sentences, each earning its place: first states the purpose, second provides usage guidance. No redundant or unnecessary words. Front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool with an output schema, the description is complete. It explains what is returned, that subdirectories are included, and when to use it. No gaps given the tool's simplicity and the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is complete. Baseline for 0 params is 4. The description indirectly explains the output (list of directories), but since there are no parameters, no additional semantics are needed.
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 ('Returns the list') and resource ('directories'), clearly distinguishing it from siblings like list_directory which list contents of a directory. It unambiguously states what the tool does.
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?
Provides explicit guidance: 'Use this to understand which directories and their nested paths are available before trying to access files.' It tells the agent when to use the tool, though it doesn't explicitly mention when not to use it or alternatives. For a simple zero-parameter tool, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![filesystem MCP server](https://glama.ai/mcp/servers/modelcontextprotocol/filesystem/badges/card.svg)](https://glama.ai/mcp/servers/modelcontextprotocol/filesystem)

Score Badge

Copy to your README.md:

[![filesystem MCP server](https://glama.ai/mcp/servers/modelcontextprotocol/filesystem/badges/score.svg)](https://glama.ai/mcp/servers/modelcontextprotocol/filesystem)

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/modelcontextprotocol/filesystem'

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