Detects PHP Composer projects through composer.json files for project type identification and dependency analysis
Detects and analyzes Docker configurations including Dockerfile and docker-compose.yml files as part of project type detection
Automatically identifies and prioritizes .env environment files as important configuration files in project analysis
Provides Git repository integration including commit history, branch information, working directory status, and diff visualization for project analysis
Identifies Java/Android projects through build.gradle files for project type detection and build configuration analysis
Provides Node.js project detection and analysis through package.json files, enabling project type identification and dependency management understanding
Detects PHP projects through composer.json files and provides PHP-specific project analysis
Detects Python projects through requirements.txt files and provides Python-specific project analysis capabilities
Identifies Ruby projects through Gemfile detection and provides Ruby-specific project context
Identifies Rust projects through Cargo.toml files and provides Rust-specific project context analysis
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., "@Enhanced Directory Context MCP Server show me the project structure of the current directory"
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.
TL;DR: A powerful MCP server that gives AI assistants full directory analysis and file editing capabilities.
📁 Analyze directories - Get project structure, find files, search content
✏️ Edit files - Create, update, delete, rename files and folders
🔍 Smart search - Find code/text across multiple files with regex support
🔄 Git integration - View commits, branches, and changes
🛡️ Safe operations - Auto-backups and transaction rollback
Related MCP server: AI FileSystem MCP
Install dependencies: npm install
Add to your Claude Desktop config:
{
"mcpServers": {
"directory-context": {
"command": "node",
"args": ["path/to/server.js"]
}
}
}Tool | What It Does |
| Set the folder to work in |
| Show folder/file tree |
| Find text in files |
| Make new files |
| Edit existing files |
| Remove files (with backup) |
| Do multiple operations at once |
A comprehensive Model Context Protocol (MCP) server that provides advanced directory analysis and file management capabilities for AI assistants like Claude. This server combines directory context extraction with full file editing capabilities, making it a powerful tool for code analysis, project management, and file operations.
Complete Directory Structure: Get detailed tree views of any directory with metadata
Intelligent Project Analysis: Automatic project type detection and context summary
Smart File Search: Regex and text-based search across multiple file types
Git Integration: Extract repository context, commit history, and working directory status
File Statistics: Comprehensive analysis of file types, sizes, and modification dates
Create Files: Generate new files with specified content
Update Files: Sophisticated search-and-replace operations with regex support
Append Content: Add content to existing files with formatting options
Delete Files: Remove files with optional backup creation
Rename/Move Files: Relocate and rename files with collision detection
Directory Management: Create directory structures recursively
Batch Operations: Execute multiple file operations in a single transaction
Automatic Backups: Optional backup creation for destructive operations
Transaction Rollback: Rollback capability for failed batch operations
Resource Exposure: Automatic exposure of important project files as MCP resources
Error Handling: Comprehensive error handling with detailed feedback
Node.js 18.0.0 or higher
npm or yarn package manager
Clone or download the MCP server files
Install dependencies:
npm installConfigure your MCP client (Claude Desktop, etc.) to use this server:
Claude Desktop Configuration:
Add to your claude_desktop_config.json:
{
"mcpServers": {
"directory-context": {
"command": "node",
"args": ["path/to/your/server.js"],
"cwd": "your-default-working-directory"
}
}
}Alternative Configuration:
Use the provided mcp-json-config.json as a template and update the paths accordingly.
Before using any features, set your working directory:
set_working_directory(directory="/path/to/your/project")get_directory_structure(
max_depth=10, // Maximum traversal depth
include_hidden=false, // Include hidden files/directories
file_types=[".js", ".py", ".md"] // Filter by extensions
)analyze_project_context(
include_code_analysis=true, // Include complexity analysis
focus_files=["specific_file.js"] // Focus on specific files
)search_files(
query="function myFunction", // Search query
file_types=[".js", ".ts"], // File types to search
is_regex=false, // Use regex matching
max_results=50 // Maximum results
)get_git_context(
include_diff=true, // Include working directory changes
commit_count=10 // Number of recent commits
)create_file(
path="src/new-component.js",
content="const MyComponent = () => { ... }",
encoding="utf8",
overwrite=false
)update_file(
path="src/config.js",
updates=[
{
search: "oldValue: 'old'",
replace: "newValue: 'new'",
regex: false,
all: true
}
],
backup=true
)append_to_file(
path="README.md",
content="## New Section\nContent here...",
newline_before=true
)delete_file(
path="old-file.js",
backup=true // Creates .deleted backup
)rename_file(
old_path="old-name.js",
new_path="new-name.js",
overwrite=false
)create_directory(
path="src/components/new-feature",
recursive=true
)Execute multiple operations atomically:
batch_file_operations(
operations=[
{
operation: "create",
params: {
path: "src/component.js",
content: "export default () => {}"
}
},
{
operation: "update",
params: {
path: "src/index.js",
updates: [...]
}
}
],
rollback_on_error=true
)The server automatically detects project types based on configuration files:
Node.js/JavaScript: package.json
Python: requirements.txt
Rust: Cargo.toml
Go: go.mod
Java: pom.xml, build.gradle
PHP: composer.json
Ruby: Gemfile
Docker: Dockerfile, docker-compose.yml
And more...
The server identifies important files automatically:
Configuration files (package.json, config.js, etc.)
Entry points (index.js, main.py, app.js)
Documentation (README.md, docs)
Docker files
Environment files (.env)
Important files are automatically exposed as MCP resources, making them easily accessible to AI assistants without explicit file reading requests.
Backup Creation: Automatic backups for destructive operations
Collision Detection: Prevents accidental overwrites
Transaction Rollback: Batch operations can be fully rolled back on error
Path Validation: Ensures operations stay within working directory bounds
Detailed Error Messages: Comprehensive error reporting for debugging
Tool | Description | Required Parameters |
| Set the working directory |
|
| Get directory tree | None |
| Read multiple files |
|
| Search within files |
|
| Analyze project | None |
| Git repository info | None |
Tool | Description | Required Parameters |
| Create new file |
|
| Update existing file |
|
| Append to file |
|
| Delete file |
|
| Rename/move file |
|
| Create directory |
|
| Multiple operations |
|
Working Directory: Set via set_working_directory or during initialization
File Type Filters: Configurable file extension filtering
Search Limits: Configurable maximum search results
Backup Policies: Optional backup creation for destructive operations
Configure the server in your MCP client with appropriate command and arguments. The server communicates via stdio and requires no additional network configuration.
enhanced-directory-context-mcp/
├── server.js # Main MCP server implementation
├── package.json # Node.js package configuration
├── mcp-json-config.json # Example MCP client configuration
└── README.md # This documentation@modelcontextprotocol/sdk: Core MCP functionality
Node.js built-in modules: fs, path, child_process
npm run devThis starts the server with Node.js inspector enabled for debugging.
MIT License - See package.json for details.
For issues, feature requests, or contributions, please refer to the repository's issue tracker.
Note: This MCP server provides powerful file system access. Ensure you trust the AI assistant and understand the operations being performed, especially destructive operations like file deletion or modification.
Analyze the project structure and provide intelligent context summary
| Name | Required | Description | Default |
|---|---|---|---|
| include_code_analysis | No | Include code complexity and dependency analysis | |
| focus_files | No | Specific files to focus analysis on |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'intelligent context summary' but doesn't explain what that means in practice - what kind of analysis is performed, what the output format looks like, whether it's computationally intensive, or what permissions might be required. This leaves significant gaps for a tool that presumably performs complex analysis.
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, efficient sentence that gets straight to the point. It's appropriately sized for a tool with two parameters and no annotations, though it could potentially be more specific about what 'intelligent context summary' entails.
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?
For a tool that performs project analysis with no annotations and no output schema, the description is insufficient. It doesn't explain what 'intelligent context summary' means, what kind of analysis is performed, or what the output looks like. Given the complexity implied by 'analyze' and 'intelligent,' more behavioral context is needed.
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?
With 100% schema description coverage, the schema already documents both parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. The baseline score of 3 reflects adequate parameter documentation through the schema alone.
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's purpose with a specific verb ('analyze') and resource ('project structure'), and specifies the output ('intelligent context summary'). However, it doesn't explicitly differentiate from sibling tools like 'get_directory_structure' or 'get_git_context' that might provide related but different functionality.
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 provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_directory_structure' and 'get_git_context' available, there's no indication of when this analysis tool is preferable or what specific context it provides that others don't.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Append content to the end of a file
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | File path relative to working directory | |
| content | Yes | Content to append | |
| newline_before | No | Add newline before appending |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'append' implies a non-destructive write operation, it doesn't specify permissions needed, whether it creates files if they don't exist, encoding considerations, or what happens on failure. The description lacks crucial behavioral context for a file mutation tool.
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, clear sentence with zero wasted words. It's front-loaded with the core functionality and appropriately sized for the tool's complexity. Every word earns its place.
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?
For a file mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens on success/failure, return values, error conditions, or how it differs from sibling tools. The description should provide more context given the tool's potential side effects.
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 description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline score of 3 reflects adequate schema coverage without description enhancement.
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 action ('append content') and target ('to the end of a file'), which is specific and unambiguous. However, it doesn't distinguish this tool from its sibling 'update_file' or explain how appending differs from other file modification operations.
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 provides no guidance on when to use this tool versus alternatives like 'update_file' or 'create_file'. There's no mention of prerequisites (e.g., file must exist), error conditions, or typical use cases for appending versus other file operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform multiple file operations in a single transaction
| Name | Required | Description | Default |
|---|---|---|---|
| operations | Yes | Array of file operations to perform | |
| rollback_on_error | No | Rollback all operations if any fails |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions transactional behavior ('single transaction') and implies atomicity with rollback, but doesn't disclose critical details like whether operations are executed in order, what happens on partial failures, authentication requirements, rate limits, or error handling. For a batch mutation tool with zero annotation coverage, this is a significant gap in behavioral context.
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, efficient sentence: 'Perform multiple file operations in a single transaction.' It is front-loaded with the core purpose, has zero wasted words, and appropriately sized for the tool's complexity, earning its place clearly.
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 tool's complexity (batch mutations with transactional behavior), lack of annotations, and no output schema, the description is incomplete. It doesn't explain return values, error cases, or detailed behavioral traits needed for safe invocation. The description should do more to compensate for the missing structured data, especially for a mutation tool.
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 description coverage is 100%, so the schema already documents both parameters (operations and rollback_on_error) with good detail. The description adds no additional parameter semantics beyond implying batching and transactionality, which is partially covered by the schema's rollback description. Baseline 3 is appropriate as the schema does the heavy lifting.
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's purpose: 'Perform multiple file operations in a single transaction.' It specifies the verb ('perform') and resource ('file operations'), and the transactional aspect distinguishes it from single-operation siblings like create_file or delete_file. However, it doesn't explicitly differentiate from all siblings (e.g., batch vs. individual operations could be more clearly contrasted).
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 context through 'multiple file operations in a single transaction,' suggesting it should be used when batching operations for atomicity. However, it doesn't explicitly state when to use this tool versus alternatives (e.g., using individual tools like create_file for single operations) or mention any prerequisites or exclusions, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new directory
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Directory path relative to working directory | |
| recursive | No | Create parent directories if needed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states the action ('Create a new directory') but doesn't disclose permissions needed, error conditions (e.g., if path exists), side effects, or response format. For a mutation tool without annotations, this is inadequate.
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 extremely concise with a single sentence ('Create a new directory'), front-loaded and zero waste. It efficiently conveys the core purpose without unnecessary elaboration, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on permissions, error handling, return values, and how it integrates with sibling tools like 'create_file'. For a tool that modifies the filesystem, more context is needed for safe and effective use.
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 description coverage is 100%, so the schema fully documents both parameters ('path' and 'recursive'). The description adds no additional parameter semantics beyond what's in the schema, such as path format examples or recursive behavior implications, meeting the baseline for high schema 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 verb ('Create') and resource ('directory'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create_file' or 'batch_file_operations', which would require mentioning it specifically creates directories rather than files or performing batch operations.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'create_directory' over 'create_file' for file creation, or how it relates to 'set_working_directory' for path management, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new file with specified content
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | File path relative to working directory | |
| content | Yes | Content to write to the file | |
| encoding | No | File encoding (default: utf8) | utf8 |
| overwrite | No | Overwrite if file already exists |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it creates a file but doesn't mention permissions needed, error conditions (e.g., if path is invalid), or what happens on failure. For a write operation, this leaves significant gaps in understanding its 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 a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.
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?
For a file creation tool with no annotations and no output schema, the description is insufficient. It doesn't explain return values, error handling, or interaction with sibling tools like 'overwrite' behavior implications. Given the complexity of file operations, more context is needed.
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 description coverage is 100%, so parameters are fully documented in the schema. The description adds no additional semantic context beyond implying 'content' is written, which the schema already covers. This meets the baseline for high schema 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 action ('Create') and resource ('a new file with specified content'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'update_file' or 'append_to_file' which also modify files, so it doesn't reach the highest score.
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 provides no guidance on when to use this tool versus alternatives like 'update_file' or 'append_to_file'. It doesn't mention prerequisites, constraints, or typical use cases, leaving the agent with no contextual decision-making help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a file
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | File path relative to working directory | |
| backup | No | Create backup before deleting (.deleted extension) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Delete a file' implies a destructive mutation, but it doesn't specify if deletion is permanent, reversible, requires permissions, or has side effects. The input schema hints at a backup option, but the description doesn't mention this behavior, leaving critical gaps for a destructive operation.
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 'Delete a file' is extremely concise with zero wasted words, making it front-loaded and easy to parse. However, it may be overly terse for a destructive tool, potentially under-specifying critical details. It earns a high score for efficiency but loses a point for lacking necessary context in its brevity.
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 tool's complexity (destructive operation with 2 parameters) and the absence of annotations and output schema, the description is incomplete. It fails to address key aspects like safety (e.g., backup behavior), error handling, or return values. For a delete tool, this minimal description leaves too many unknowns for safe and effective use.
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 description coverage is 100%, so the input schema fully documents the parameters (path and backup). The description adds no additional meaning beyond what the schema provides, such as explaining parameter interactions or use cases. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 'Delete a file' states the basic action (delete) and resource (file), which is clear but minimal. It distinguishes from siblings like 'rename_file' or 'update_file' by specifying deletion, but lacks specificity about scope or constraints. It's not tautological but remains vague about what 'delete' entails beyond the obvious.
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 provides no guidance on when to use this tool versus alternatives. For example, it doesn't mention if this is for permanent deletion or if there are safer options like moving to trash, nor does it reference sibling tools like 'batch_file_operations' for multiple deletions. Without any context, usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the complete directory structure with file metadata
| Name | Required | Description | Default |
|---|---|---|---|
| max_depth | No | Maximum depth to traverse (default: 10) | |
| include_hidden | No | Include hidden files and directories | |
| file_types | No | Filter by file extensions (e.g., [".js", ".py", ".md"]) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Get' implies a read-only operation, the description doesn't address important behavioral aspects like performance characteristics (could be slow for large directories), whether it traverses symlinks, what metadata is included, or how results are structured. The description is too minimal for a tool that returns potentially complex directory structures.
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, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a tool with well-documented parameters and no output schema, making it easy to parse and understand at a glance.
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?
For a tool that returns directory structures with metadata and has no output schema, the description is insufficient. It doesn't explain what 'file metadata' includes (size, permissions, timestamps, etc.), how the structure is organized, whether it's recursive by default, or what format the output takes. Given the complexity of directory traversal and the lack of output schema, more context is needed.
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 input schema has 100% description coverage, with all three parameters well-documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema descriptions, so it meets the baseline of 3 where the schema does the heavy lifting.
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 verb ('Get') and resource ('complete directory structure with file metadata'), making the purpose immediately understandable. It doesn't explicitly distinguish from sibling tools like 'search_files' or 'get_file_contents', but the scope ('complete directory structure') provides some implicit differentiation.
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 provides no guidance on when to use this tool versus alternatives like 'search_files' (for targeted searches) or 'get_file_contents' (for reading specific files). There's no mention of prerequisites, typical use cases, or when this tool would be preferred over other file system operations available in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read contents of specific files
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | Array of file paths to read | |
| encoding | No | File encoding (default: utf8) | utf8 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Read contents' which implies a read-only operation, but doesn't mention potential limitations like file size constraints, permission requirements, error handling for missing files, or whether it returns raw text or structured data. This leaves significant gaps for a tool that interacts with file systems.
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, efficient sentence that directly states the tool's function without any unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly.
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 complexity of file operations and the lack of annotations and output schema, the description is insufficient. It doesn't cover behavioral aspects like what happens if files don't exist, how large files are handled, or the format of returned content. For a tool with no structured safety or output information, more context is needed.
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 description coverage is 100%, with clear documentation for both parameters ('files' as an array of file paths and 'encoding' with a default). The description adds no additional parameter semantics beyond what the schema provides, such as examples of valid file paths or encoding options. This meets the baseline for high schema 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 'Read contents of specific files' clearly states the verb ('Read') and resource ('contents of specific files'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_files' or 'get_directory_structure' that might also involve file content access, so it doesn't reach the highest score.
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 provides no guidance on when to use this tool versus alternatives. With siblings like 'search_files' (which might return file contents as part of results) or 'get_directory_structure' (which might include content summaries), there's no indication of when this specific read operation is preferred, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract Git repository context (branch, recent commits, status)
| Name | Required | Description | Default |
|---|---|---|---|
| include_diff | No | Include current working directory changes | |
| commit_count | No | Number of recent commits to include |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool extracts but doesn't describe how it behaves: it doesn't mention whether it reads from the current directory, requires Git to be installed, handles errors (e.g., if not in a Git repo), or what the output format looks like. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operational traits.
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 highly concise and front-loaded, using a single sentence that efficiently conveys the core purpose without unnecessary words. Every element ('Extract', 'Git repository context', 'branch, recent commits, status') earns its place by specifying the action and key outputs. There's no redundancy or wasted phrasing.
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 complexity of a Git context tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., error handling, dependencies), output format, and usage context. While the schema covers parameters well, the description doesn't provide enough information for an agent to fully understand how to invoke and interpret results, especially without structured output documentation.
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 description adds no parameter-specific information beyond what the input schema provides. With 100% schema description coverage, the schema fully documents both parameters ('include_diff' and 'commit_count') with descriptions and defaults. The baseline is 3, as the description doesn't compensate with additional context like examples or edge cases, but it also doesn't detract from the schema's completeness.
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's purpose with specific verbs ('Extract') and resources ('Git repository context'), listing the key elements retrieved (branch, recent commits, status). It distinguishes from siblings like 'get_directory_structure' or 'get_file_contents' by focusing on Git metadata rather than file system operations. However, it doesn't explicitly differentiate from all siblings (e.g., 'analyze_project_context' might overlap in scope).
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., requires a Git repository), exclusions (e.g., not for non-Git projects), or comparisons with siblings like 'analyze_project_context' that might offer similar functionality. Usage is implied by the name and purpose but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename or move a file
| Name | Required | Description | Default |
|---|---|---|---|
| old_path | Yes | Current file path | |
| new_path | Yes | New file path | |
| overwrite | No | Overwrite if destination exists |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'rename or move' implies a mutation operation, it lacks details on permissions required, error conditions (e.g., if paths don't exist), whether the operation is atomic or reversible, or any rate limits. This is a significant gap for a tool that modifies files.
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, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by directly conveying the tool's purpose.
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 complexity of a file mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like error handling, permissions, or what the tool returns, leaving gaps that could hinder an AI agent's ability to use it correctly in various contexts.
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 description coverage is 100%, so the schema already documents all three parameters (old_path, new_path, overwrite) with clear descriptions. The description adds no additional meaning beyond what the schema provides, such as path format examples or implications of the overwrite parameter, meeting the baseline for high schema 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 verb 'rename or move' and resource 'a file', making the purpose immediately understandable. However, it doesn't differentiate this tool from potential alternatives like 'update_file' or 'batch_file_operations' among the sibling tools, which would require more specificity for a perfect score.
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 provides no guidance on when to use this tool versus alternatives. With sibling tools like 'update_file' and 'batch_file_operations' available, there's no indication of scenarios where renaming/moving is preferred over other file modification methods, nor any prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for content within files using regex or text matching
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (text or regex pattern) | |
| file_types | No | File extensions to search in | |
| is_regex | No | Whether the query is a regex pattern | |
| max_results | No | Maximum number of results to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the search method (regex or text matching) but lacks details on permissions required, rate limits, whether it's read-only or has side effects, or what the output looks like (e.g., list of matches with file paths). For a search tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence that front-loads the core purpose without unnecessary words. It directly states what the tool does ('Search for content within files') and the method ('using regex or text matching'), making it easy to parse and understand quickly.
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 tool's complexity (searching files with multiple parameters) and lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects like safety, permissions, or output format, and while the schema handles parameters well, the overall context for effective agent use is insufficient. A more comprehensive description would enhance usability.
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 input schema has 100% description coverage, clearly documenting all parameters (query, file_types, is_regex, max_results). The description adds minimal value beyond the schema by implying regex/text matching, but it doesn't provide additional context like search scope (e.g., current directory vs. recursive) or parameter interactions. With high schema coverage, the baseline score of 3 is appropriate.
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's purpose as 'Search for content within files using regex or text matching,' which specifies the verb (search), resource (content within files), and method (regex or text matching). However, it doesn't explicitly distinguish this tool from sibling tools like 'get_file_contents' or 'analyze_project_context,' which might also involve file content access, so it lacks sibling differentiation.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios like searching for specific text across multiple files, filtering by file types, or how it differs from tools like 'get_file_contents' (which retrieves content) or 'analyze_project_context' (which might involve broader analysis). Without such context, the agent has minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the working directory for context extraction
| Name | Required | Description | Default |
|---|---|---|---|
| directory | Yes | Path to the directory to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'Set' and 'context extraction' but doesn't disclose behavioral traits such as whether this affects subsequent operations, requires specific permissions, or has side effects. This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence with no wasted words. It's appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary elaboration.
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 tool's complexity as a mutation operation with no annotations and no output schema, the description is insufficient. It lacks details on behavior, effects, or integration with sibling tools, making it incomplete for effective agent use.
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 description coverage is 100%, so the input schema already documents the 'directory' parameter. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints, resulting in a baseline score.
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 action ('Set') and the target ('working directory for context extraction'), making the purpose understandable. However, it doesn't distinguish this tool from potential alternatives like 'create_directory' or specify what 'context extraction' entails, preventing a perfect score.
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 is provided on when to use this tool versus alternatives. With siblings like 'create_directory', 'get_directory_structure', and 'analyze_project_context', the description lacks context about prerequisites, timing, or comparisons, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update specific parts of a file using search and replace
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | File path relative to working directory | |
| updates | Yes | Array of search/replace operations | |
| backup | No | Create backup before updating (.bak extension) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions the search/replace mechanism. It doesn't disclose critical behavioral traits like whether updates are atomic, if file permissions are required, error handling for missing files, or what happens on failure. For a mutation tool with zero annotation coverage, this is insufficient.
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, efficient sentence that immediately conveys the core functionality without any wasted words. It's appropriately sized and front-loaded with the essential information.
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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens on success/failure, return values, or important constraints like file size limits or encoding considerations. Given the complexity of file updates, more context is needed.
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 description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond implying search/replace operations, which is already covered in the schema's updates property description. Baseline 3 is appropriate when schema does the heavy lifting.
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 verb 'update' and resource 'file' with specific method 'using search and replace', distinguishing it from siblings like append_to_file (adds content) or rename_file (changes name). It precisely communicates the tool's function beyond just the name.
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 is provided on when to use this tool versus alternatives like append_to_file (for adding content without replacement) or batch_file_operations (for multiple files). The description only states what it does, not when it's appropriate compared to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
analyze_project_contextappend_to_filebatch_file_operationscreate_directorycreate_filedelete_fileget_directory_structureget_file_contentsget_git_contextrename_filesearch_filesset_working_directoryupdate_fileMost tools have distinct purposes targeting specific file/directory operations, but some overlap exists: 'update_file' and 'append_to_file' both modify file content, and 'get_directory_structure' and 'analyze_project_context' both provide structural insights, though descriptions help differentiate them.
All tools follow a consistent verb_noun pattern with clear, descriptive names (e.g., 'create_file', 'delete_file', 'get_file_contents'). There are no deviations in naming conventions, making the set predictable and readable.
With 13 tools, this server is well-scoped for directory and file management, covering essential operations like create, read, update, delete, search, and context extraction. Each tool serves a clear purpose without bloat.
The toolset provides comprehensive coverage for file system operations, including CRUD for files/directories, content manipulation, searching, and context extraction (e.g., Git, project analysis). There are no obvious gaps that would hinder agent workflows in this domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Manage files and folders directly from your workspace. Read and write files, list directories, cre…
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/PWalaGov/File-Control-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
