Skip to main content
Glama
bill-gtl-group

File Server MCP

by bill-gtl-group
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

File Server MCP

A Model Context Protocol (MCP) server that exposes documents from specific folders through configurable access.

Features

  • Configurable Folders: Expose specific folders like Documents, Reports, Desktop, etc.

  • File Type Filtering: Only allow specific file extensions for security

  • Size Limits: Configurable maximum file size limits

  • Tools Available:

    • list_files: List files in a configured folder with optional pattern matching

    • read_file: Read the content of a specific file

    • search_files: Search for files containing specific text

  • Resources: Access files through MCP resource URIs like file://documents/filename.txt

Related MCP server: LocalFiles MCP Server

Configuration

The server can be configured through environment variables or the config.json file:

Default Folders

  • documents: C:\Users\bill\Documents

  • reports: C:\Support

  • desktop: C:\Users\bill\Desktop

  • backup_scripts: C:\support

Environment Variables

  • FILE_SERVER_CONFIG: JSON string with custom configuration

  • DOCUMENTS_FOLDER: Override documents folder path

  • REPORTS_FOLDER: Override reports folder path

  • DESKTOP_FOLDER: Override desktop folder path

Configuration File

Edit config.json to customize:

{
  "folders": {
    "documents": "C:\\Users\\bill\\Documents",
    "reports": "C:\\Support",
    "desktop": "C:\\Users\\bill\\Desktop",
    "backup_scripts": "C:\\support"
  },
  "allowedExtensions": [".txt", ".md", ".pdf", ".docx", ".xlsx", ".csv", ".json", ".xml", ".log", ".ps1"],
  "maxFileSize": 10485760
}

Installation

Prerequisites

  1. Install Node.js (https://nodejs.org/)

  2. Install npm dependencies:

    npm install

Build

npm run build

MCP Configuration

Add to your MCP settings file (C:\Users\bill\AppData\Roaming\Code\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json):

{
  "mcpServers": {
    "file-server": {
      "command": "node",
      "args": ["C:/Users/bill/Desktop/file-server/build/index.js"],
      "env": {
        "FILE_SERVER_CONFIG": "{\"folders\":{\"documents\":\"C:\\\\Users\\\\bill\\\\Documents\",\"reports\":\"C:\\\\Support\",\"desktop\":\"C:\\\\Users\\\\bill\\\\Desktop\",\"backup_scripts\":\"C:\\\\support\"}}"
      }
    }
  }
}

Usage Examples

Once installed, you can use the file server through MCP tools:

List Files

Use the list_files tool with folder="documents" to see all files in the Documents folder

Read a File

Use the read_file tool with folder="reports" and filename="backup-report.csv" to read a specific file

Search Files

Use the search_files tool with folder="backup_scripts" and searchText="SQLite" to find scripts containing "SQLite"

Access Resources

Access file://documents/ to get a list of files in Documents
Access file://reports/backup-report.csv to read a specific file

Security Features

  • Only configured folders are accessible

  • File type restrictions through allowedExtensions

  • File size limits to prevent large file access

  • Path traversal protection

  • Read-only access (no file modification)

Folder Structure

file-server/
├── package.json          # Node.js package configuration
├── tsconfig.json         # TypeScript configuration  
├── config.json          # Server configuration
├── README.md            # This file
├── src/
│   └── index.ts         # Main server implementation
└── build/               # Compiled JavaScript (after npm run build)
    └── index.js         # Executable MCP server

Development

# Watch mode for development
npm run dev

# Build for production
npm run build

# Test the server
npm start

Available Tools

3 tools
list_filesB

List files in a configured folder

ParametersJSON Schema
NameRequiredDescriptionDefault
folderYesFolder name to list files from. Available: documents, reports, desktop
patternNoOptional file pattern to match (e.g., "*.txt")

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 behavioral burden. 'List files' clearly implies a non-destructive enumeration, which is useful. However, it does not mention return format, recursion, hidden files, sorting, or how the pattern parameter affects results.

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?

One short sentence with no filler or redundant information. It is concise, front-loaded, and easy to parse.

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 description is adequate for a simple listing tool, and the schema covers parameters. But it lacks usage differentiation from sibling tools and does not describe the output or behavior with the optional pattern. No output schema exists, so a bit more return-value context would improve completeness.

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 baseline is 3. The description itself adds no parameter-level detail; the schema fully documents the folder enum and the optional pattern. No compensation is needed because the schema is already complete.

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 a clear action and object: 'List files in a configured folder.' The folder enum in the schema adds specificity, and the verb 'List' distinguishes it from read_file and search_files. However, 'configured folder' is a bit vague and does not explicitly contrast with siblings.

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 given for when to use this tool versus search_files or read_file. The context is implied by the name and description, but there are no explicit alternatives, exclusions, or conditions.

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

read_fileA

Read the content of a specific file

ParametersJSON Schema
NameRequiredDescriptionDefault
folderYesFolder name containing the file. Available: documents, reports, desktop
filenameYesName of the file to read

TDQS

A4.1/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. 'Read' implies a non-mutating operation, but the description gives no details about return format, encoding, error behavior, or side effects. It is acceptable for a simple read but minimal.

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?

Single sentence with no redundant words. The action and object are front-loaded, and every word contributes to meaning.

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 straightforward read tool with a well-defined schema and two clearly related siblings, the description is sufficient. The expected output—file content—is directly implied by 'Read the content'.

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%: both folder and filename are described, and folder includes an explicit enum. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.

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?

States a specific verb ('Read') and resource ('a specific file'), clearly distinguishing it from sibling tools list_files and search_files. The purpose is immediately understandable and 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 intended context is clear: use this tool when you need the contents of a known file, rather than listing or searching for files. It does not explicitly name alternatives or exclusion cases, but the contrast with siblings is implicit and strong.

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

search_filesA

Search for files containing specific text

ParametersJSON Schema
NameRequiredDescriptionDefault
folderYesFolder name to search in. Available: documents, reports, desktop
searchTextYesText to search for in file contents
caseSensitiveNoWhether search should be case sensitive

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. 'Search' conveys a read-only intent, and 'containing specific text' clarifies that it searches file contents rather than filenames. However, it does not describe the return format, whether search is recursive, or any other behavioral nuances such as limits or exclusions.

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, tight sentence with no wasted words. It conveys the core action and target resource immediately, making it easy for an agent to parse quickly.

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?

For a simple search tool, the core behavior and schema-defined parameters are sufficiently clear. However, there is no output schema and the description does not mention what the tool returns (e.g., file paths, matching lines), leaving a minor gap in completeness.

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 parameters are already well documented. The description adds no additional meaning beyond what the schema provides, which meets the baseline but does not exceed it.

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 states a specific verb and resource: searching files by text content. It clearly distinguishes this tool from siblings list_files and read_file, since the focus is on finding files that contain specific text rather than listing or reading files.

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 when to use the tool: when you need to locate files containing particular text. However, it does not explicitly mention alternatives or provide exclusion criteria, such as 'use list_files to enumerate files' or 'use read_file to view contents.'

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.

  1. 3 tool updatesv1.0.0
    • First observedlist_files
    • First observedread_file
    • First observedsearch_files
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored across 3 tools

Disambiguation5/5

Each tool targets a distinct operation: listing directory entries, reading one file's content, and searching for files by text. There is little risk of an agent selecting the wrong tool.

Naming Consistency5/5

All three tools follow a consistent verb_noun snake_case pattern (list_files, read_file, search_files). The singular/plural noun forms are conventional and do not create ambiguity.

Tool Count4/5

Three tools is minimal but reasonable for a narrowly scoped read-only file access server. It is slightly lean, but every tool covers a distinct and useful operation.

Completeness2/5

Despite the 'File Server' name, there are no create, write, update, move, or delete operations, leaving file modification workflows impossible. Agents can only read and search, so the surface is notably incomplete for general file management.

Resources

Related MCP Connectors

Related MCP Servers