Local File System MCP Server
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Local File System MCP Servercheck disk usage of my Downloads folder"
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.
mon_serveur_mcp
Serveur MCP local exposant deux outils :
disk_usage(path)— taille totale d'un dossier (info système)find_files(directory, keyword)— recherche de fichiers par mot-clé (outil personnel)
Installation (macOS)
cd mon_serveur_mcp
python3 -m venv .venv
source .venv/bin/activate
pip install mcpRelated MCP server: Local Filesystem MCP Server
Vérifier que le serveur démarre
python server.py(Le serveur attend des messages sur l'entrée standard : il semble "ne rien faire", c'est normal. Aucune erreur = démarrage OK. Ctrl+C pour quitter.)
Brancher dans Claude Desktop
Éditer le fichier :
~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"mon-serveur": {
"command": "/CHEMIN/ABSOLU/mon_serveur_mcp/.venv/bin/python",
"args": ["/CHEMIN/ABSOLU/mon_serveur_mcp/server.py"]
}
}
}IMPORTANT : command doit pointer vers le python du venv (où mcp
est installé), pas vers un python générique — sinon Claude Desktop ne
trouvera pas le module mcp.
Puis quitter complètement Claude Desktop (Cmd+Q) et le relancer.
Available Tools
2 toolsdisk_usageA
Calcule la taille totale d'un dossier en mégaoctets.
Args: path: chemin local du dossier, ex: ~/Downloads
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the basic function without revealing traits like read-only nature, permission requirements, or traversal behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: the first states purpose, the second explains the parameter. No wasted words and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and presence of an output schema, the description is minimally adequate but could mention recursion or error handling for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides the parameter name 'path'. The description adds meaningful context: it specifies a local folder path and gives an example, compensating for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates total folder size in megabytes, using a specific verb and resource. It distinguishes from the sibling 'find_files' which is for file searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking folder size but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_filesC
Cherche dans un dossier les fichiers dont le nom contient un mot-clé.
Args: directory: dossier où chercher, ex: ~/Documents keyword: mot à trouver dans les noms de fichiers, ex: rapport
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | ||
| directory | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not disclose behavior like recursion into subdirectories, case sensitivity, hidden files, or permissions. The description is too minimal for an agent to predict side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by an args list in a structured docstring format. It is front-loaded with the purpose and is concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (per context), the description need not explain return values. However, the tool is simple but missing behavioral details like recursion or case sensitivity, which would be expected for file search. The description is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It provides examples for directory and keyword (e.g., ~/Documents, rapport), which adds some meaning beyond type string. However, no constraints or additional semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for files by name keyword in a directory. The verb 'cherche' and resource 'fichiers' are specific. The sibling tool disk_usage is different, but no explicit differentiation is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as disk_usage. There is no mention of exclusions, prerequisites, or context beyond the basic search operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Both tools have clearly distinct purposes: one calculates folder size, the other searches for files by name. There is no overlap or ambiguity.
Both use snake_case, but disk_usage is noun_noun while find_files is verb_noun, showing a minor inconsistency in pattern.
Only 2 tools for a file system server is too few; essential operations like listing, reading, writing, deleting files are missing, making the tool set feel incomplete.
The tools cover only disk usage and file search, leaving out basic file CRUD operations, which are necessary for a file system utility.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Manage files and folders directly from your workspace. Read and write files, list directories, cre…
Search ATProto writing, annotations, identity, agents, and forum posts. 12 read-only tools.
Securely search and manage workspace context files for AI agents and teams.
Provides tools for searching Google Workspace documentation and much more.
Related MCP Servers
- FlicenseAqualityDmaintenanceProvides file search functionality with tools for both partial keyword matching and exact word search, returning detailed results with line numbers and column positions.2
- -licenseNot gradedqualityNot gradedmaintenanceEnables exploration and search of local filesystems using glob pattern matching to find files and grep to search for text patterns within files.
- FlicenseNot gradedqualityNot gradedmaintenanceEnables exploration and search of local filesystems using glob pattern matching to find files and grep to search for text patterns within files.
- FlicenseAqualityDmaintenanceProvides tools to monitor host system health including CPU load, disk usage, and network status while enabling file system management tasks like searching and moving files. It includes built-in safety guards to prevent operations on critical system directories.11
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/MomoSGM/Mcp_mohamedNour'
If you have feedback or need assistance with the MCP directory API, please join our Discord server