vulcan-file-ops

by n0zer0d4y

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: v1.2.14
Disambiguation4/5
Most tools have clearly distinct purposes, but there is minor overlap between 'move_file' (single atomic move/rename) and 'file_operations' (bulk move/copy/rename). The descriptions are clear enough to differentiate, but the redundancy slightly lowers the score.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., 'delete_files', 'read_file', 'list_directory'). Even multi-word names like 'list_allowed_directories' adhere to the pattern, ensuring predictability.
Tool Count5/5
17 tools is a well-scoped set for a file operations server. Each tool serves a distinct file-related operation without being excessive, covering a broad range of needs from reading/writing to searching and shell execution.
Completeness4/5
The tool set is comprehensive, covering file CRUD, directory management, search, metadata, and shell execution. Minor gaps exist, such as lacking permission modification or symlink support, but these are non-essential for most workflows.
Average 4.2/5 across 17 of 17 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on December 7, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT 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.
This repository includes a glama.json configuration file.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses execution as bash -c, captures stdout/stderr/exit codes, timeout auto-termination, security restrictions, and approval requirement. Warns about command substitution restrictions. No contradictions with annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is thorough but verbose, with some redundancy (e.g., the importance of description is already in parameter schema). Structured with sections, but could be more concise for a tool with high schema coverage.
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?
Covers execution model, security, timeout, working directory, and approval. However, does not explicitly describe the return format (stdout/stderr/exit code), which would be expected given no output schema. Slightly incomplete for a shell execution 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?
Schema coverage is 100%, so baseline is 3. The description adds context like workdir must be within allowed directories and timeout default, but this largely duplicates schema descriptions. No significant additional semantics beyond what schema provides.
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 executes shell commands on the host system with security controls, specifying the execution mechanism (bash -c on Unix/Mac, powershell on Windows). It distinguishes from sibling file/directory tools by being a general command execution tool.
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 clear security requirements (approved directories, working directory constraints, command substitution restrictions) and states that all commands require user approval. Does not explicitly state when not to use or mention alternatives, but sibling context makes it obvious.
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?
With no annotations, the description carries full burden. It discloses the constraint of allowed directories but does not mention other behavioral traits such as no side effects, permissions, or rate limits. Adequate but lacks richer 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?
Three sentences with no waste. First sentence states purpose, second provides details, third gives usage guidance and constraint. Front-loaded 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?
The description covers purpose, details of metadata, when to use, and the constraint. For a simple tool with one parameter and no output schema, it is largely complete, though it could mention return format.
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 one parameter 'path' with no description in schema (0% coverage). The description only says 'files or directories' without specifying format, absolute/relative, or examples, adding minimal value beyond the schema.
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 extracts comprehensive metadata and statistics for files or directories, distinguishing it from sibling tools like read_file (content) or list_directory (listing entries). It specifies the details included: size, timestamps, permissions, entry type.
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 indicates the tool is for inspecting file properties without accessing content, and notes it only works in allowed directories. It provides clear context but does not explicitly state when not to use or name alternatives, though siblings imply differentiation.
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?
Without annotations, the description discloses key behaviors: idempotent (won't error if exist), recursive parent creation, and directory restrictions. This covers safety and constraints adequately.
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: the first front-loads core functionality, the second adds idempotency and constraints. No extra words, every sentence adds value.
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 main functionality, idempotency, recursion, and allowed directories. It does not mention failure behavior or return value, but for a simple creation tool with no output schema, these are minor gaps.
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% (the 'paths' parameter has a detailed description). The tool description adds no further parameter details beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create single or multiple directories' with specific verb and resource. It distinguishes from sibling tools by mentioning 'recursive parent creation (like Unix 'mkdir -p')' and idempotency, which is unique among file operation tools.
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 (create directories recursively, idempotently) and includes a limitation ('Only works within allowed directories'), but does not explicitly state when not to use or provide alternatives among the 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?
No annotations provided, so description carries full burden. It discloses atomicity, safe failure on existing destination, and directory constraints. Missing details on symlinks or error handling for missing source, but substantial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, with purpose front-loaded. Every sentence adds value: purpose, cross-directory support, safe behavior, rename capability, and directory constraint. No wasted words.
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?
For a simple two-parameter tool without output schema, the description covers purpose, behavior, and constraints. Lacks details on recursive moves or cross-filesystem behavior, but these are reasonable gaps given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It implies source and destination are paths and adds constraints (must be within allowed directories). However, it does not explicitly describe each parameter's format or constraints, missing an opportunity for clarity.
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 clearly states verb 'relocate or rename' and resource 'files and directories'. It distinguishes from sibling tools (none do moving/renaming) and provides specific behaviors like cross-directory moves and same-directory renames.
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?
No explicit when-to-use or when-not-to-use compared to siblings like copy or file_operations. Context is implied but not detailed, making it adequate but not strong.
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?
No annotations are provided, so the description carries the full burden. It states that the directory and all subdirectories become accessible for all filesystem operations, which is a clear behavioral disclosure. It does not contradict any annotations (none exist).
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 concise with two clear sentences and a highlighted note about current state. It is front-loaded with the purpose. Could be slightly more efficient but is not verbose.
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?
For a simple tool with one parameter and no output schema, the description explains purpose, use case, effect, and current state. It does not cover edge cases like multiple registrations, but it is adequate for typical usage.
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% and the schema description for 'path' is straightforward. The description adds context about subdirectory accessibility but does not provide additional parameter-specific details beyond the schema.
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 verb 'register' and the resource 'directory for access'. It explains the effect on filesystem operations and distinguishes from sibling tools like file read/write which require prior registration. 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates this tool is used during conversation to grant access dynamically. It explicitly notes that currently accessible directories are none, implying the need to call this first. However, it does not mention when not to use it or alternatives like listing already registered directories.
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?
With no annotations, the description covers concurrency, format support, auto-detection, partial failure handling, and restricted directories. Missing explicit statement about overwrite behavior and return value details, but overall good.
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?
Well-structured with sections and bolded IMPORTANT note. Slightly verbose (e.g., redundant auto-detection statement), but overall efficient and front-loads key info.
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 no output schema, description covers format support, error handling, allowed directories, and multi-line content. Lacks explicit overwrite behavior and return fields, but sufficiently complete for agent use.
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 has 100% coverage with description on content field. Description adds nuance about multi-line content using actual newlines and auto-detection, but does not significantly expand beyond schema.
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?
Clearly states it writes multiple files concurrently, supports text, PDF, DOCX with HTML formatting, and auto-detects file type by extension. Distinguishes from sibling `write_file` which handles single files, and other file operations.
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 context for when to use this tool (multiple concurrent writes) and includes important constraints like allowed directories. Lacks explicit when-not or alternatives like `write_file`, but the intent is clear.
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?
No annotations are provided, so the description carries full burden. It discloses path validation, concurrent processing, recursive deletion, force option, and allowed-directory scope. However, it does not detail error handling or recovery, slightly reducing transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each adding distinct information: purpose, features, validation, concurrency, limits, and scope. It is front-loaded with the core action and contains no redundant words.
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?
For a simple deletion tool with 3 parameters and no output schema, the description covers purpose, constraints, and key behaviors. However, it lacks information on return values or partial failure handling, which would improve completeness.
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?
Schema coverage is 100%, baseline is 3. The description adds behavioral context beyond the schema by noting that all paths are validated and operations are concurrent, which enhances understanding of the parameters' effects.
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 deletes single or multiple files and directories. It specifies secure deletion, recursive support, and path validation, which distinguishes it from sibling tools like move_file or write_file.
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 includes constraints like maximum paths and allowed directories but does not explicitly compare to alternatives like move_file. Usage guidance is implied but not explicit about when to choose this tool over siblings.
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?
With no annotations, the description carries full burden. It discloses atomic operations with rollback, concurrent processing, cross-platform line ending preservation, and a maximum of 50 files per operation. It mentions dry-run preview mode and matching strategies. However, it could be more explicit that the tool writes to disk and is potentially destructive if oldText matches incorrectly.
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 long but well-organized with sections for modes, matching strategies, features, and best practices. It front-loads the core purpose. Each sentence adds information, though slight trimming of redundant phrases (e.g., 'per-file matching strategy control' in Features) could improve conciseness.
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 tool's complexity and no output schema, the description mentions 'detailed diff output with statistics' but does not specify the exact return structure. It covers modes, strategies, and best practices adequately, but lacks explicit error handling details beyond ambiguous matches. Overall, it is sufficient for an agent to use correctly, but gaps remain in output information.
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?
Schema coverage is 100%, baseline 3. The description adds significant value by explaining matching strategies, best practices for oldText/newText, and the purpose of instruction and expectedOccurrences fields. It also provides critical guidance on multi-line content representation.
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 applies precise modifications to text and code files, details single and multi-file editing modes, and outlines matching strategies. It clearly distinguishes from sibling tools like write_file (which overwrites entire files) and delete_files.
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?
Best practices are provided (e.g., include 3-5 lines of context, use dryRun, set expectedOccurrences). A critical note about multi-line content warnings against using \n. It implicitly advises against using this tool for complete file rewrites (use write_file). However, it does not explicitly 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses recursive search, glob patterns, absolute paths, and directory restrictions. Missing details like read-only nature, performance implications, or auth requirements, which would be valuable.
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 front-loaded with purpose, then details. No redundancy, every sentence provides useful information. Efficient and well-structured.
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?
For a file search tool, description covers key aspects: pattern syntax, recursion, return type (absolute paths), and directory constraints. No output schema needed; description sufficiently complete.
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?
Schema coverage is 100%, baseline 3. Description adds value by explaining pattern examples ('*.ext', '**/*.ext') and describing excludePatterns purpose, going beyond schema descriptions.
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?
Clearly states it performs recursive pattern-based searches for files and directories using glob-style patterns. Distinguishes from sibling tools like grep_files (content search) and listing tools by focusing on path patterns.
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 clear usage context: use when exact paths are unknown, with examples of simple and recursive patterns. No explicit when-not-to-use or alternative tool references, but the description adequately guides usage.
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?
With no annotations provided, the description covers key behaviors: concurrency, per-file modes, document file handling, maximum files, and directory restrictions. It does not detail error behavior or return format, but these are less critical for a read 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 concise at four sentences, front-loaded with the core purpose, and every sentence adds value without redundancy.
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's simplicity and lack of output schema, the description covers essential aspects: input, modes, constraints, and document support. It could mention error handling but is otherwise complete.
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 adds context about concurrency and document behavior but does not significantly enhance understanding beyond the schema's detailed parameter descriptions.
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's purpose: batch reading multiple files concurrently with per-file mode control. It explicitly distinguishes from the sibling 'read_file' tool by emphasizing concurrency and batch processing.
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 usage context (when to use for batch reads with concurrency) and constraints (under 50 files, allowed directories). However, it does not explicitly mention when not to use or name alternatives like 'read_file' for single files.
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?
Discloses security validation, concurrency, conflict resolution, and file limit. No annotations, so description carries full burden; could add atomicity or error handling details.
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 concise sentences front-loading purpose and key constraints with zero waste.
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?
Missing output description for a bulk operation; agents need to know what is returned (e.g., success/failure per file).
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?
Schema already describes parameters well; description adds context (bulk, concurrent, validated, limit). Over baseline of 3.
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 clearly states bulk file operations (move, copy, rename) on single or multiple files/concurrently, distinguishing it from single-file siblings like move_file.
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?
States context for bulk operations and performance limits, but lacks explicit when-not or alternative tool mentions.
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?
No annotations are provided, so the description carries full burden. It discloses that globally configured ignored folders are automatically filtered and that the tool replaces previous versions, but does not mention error handling or performance characteristics.
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 essential information: purpose, replacement status, format options, filtering behavior, and access restriction. No redundant or irrelevant 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 tool with 4 parameters, no annotations, and no output schema, the description covers purpose, formats, sort options, exclusion patterns, and access restrictions adequately. The missing output schema is acceptable since the tool returns directory listings.
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?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the format parameter variants (simple, detailed, tree, json) and clarifying that excludePatterns are applied in addition to global filters, which is not in the schema.
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 'List directory contents with flexible output formats' and specifies that it replaces three previous tools, making its purpose distinct from siblings like 'execute_shell' or 'file_operations'.
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 mentions 'Only works within allowed directories' but does not provide explicit when-to-use or when-not-to-use guidance relative to alternatives like 'glob_files' or 'get_file_info'.
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?
No annotations provided, so description carries full burden. It discloses that images are presented to the AI as if uploaded by the user, requires client vision support, and is restricted to allowed directories. No contradictory or omitted behaviors.
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 concise sentences, each providing essential information: purpose, behavior, format support, and constraints. No redundant or extraneous content. Information is front-loaded.
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 simple tool (one parameter, no output schema), the description covers purpose, usage, format, and requirements adequately. Could mention if images are stored temporarily, but not critical.
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?
Schema coverage is 100%, but description adds value: explains the 'path' parameter accepts single or multiple images, and advises providing an array for compatibility. This goes beyond the schema's basic description.
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 verb and resource: 'Attach an image file for AI vision analysis.' It explains the purpose (enable AI to see and describe visual content) and distinguishes from file operation siblings like delete_files, read_file, etc.
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 clear context: attaches images for AI vision, supports multiple images, lists supported formats, and notes prerequisites (MCP client vision capabilities, allowed directories). However, it does not explicitly mention when not to use or provide alternatives, but the sibling tools are sufficiently distinct.
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 reveals key behavioral traits: respects ignored folders, only searches allowed directories, supports various flags and output modes. Since no annotations exist, it carries full burden and does so well, though it could more explicitly state it is read-only (implied by search).
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 efficient paragraph that front-loads the core purpose, then lists capabilities, output modes, and constraints. Every sentence adds value without redundancy.
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 complexity (11 parameters, no output schema), the description is comprehensive: covers regex, flags, output modes, limitations (ignored folders, allowed directories), and mentions line numbers and context. No major gaps.
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?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining flags, output modes, and head_limit usage, including practical notes like 'use with read_file'.
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 'Search text patterns within file contents using regex', which is a specific verb+resource. It distinguishes from siblings like read_file and glob_files by focusing on pattern matching.
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?
It suggests using with read_file/read_multiple_files to retrieve actual content, providing context for complementary tools. However, it does not explicitly state when not to use grep_files or list specific alternatives beyond read_file.
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?
No annotations are provided, so the description carries full burden. It discloses modes, document file behavior, PDF metadata extraction, and allowed directory constraints. It could mention limitations for binary files or error scenarios.
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 well-structured with a clear flow: file types, modes, special behavior, and restrictions. Every sentence contributes essential information without redundancy.
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 no output schema, the description adequately explains return values (e.g., PDF metadata) and covers modes, file support, and directory limits. It lacks details on file size limits or encoding, but is sufficiently complete for a read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value beyond the schema: document files ignore mode, lines required for head/tail, 1-indexed and inclusive range, and path restrictions. This enriches the agent's 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 reads files with flexible modes, supports text and document formats, and lists specific modes. It distinguishes from siblings like read_multiple_files by focusing on single file reading with mode options.
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?
It provides clear guidance on when to use each mode (head, tail, range for text; document files always full) and mentions directory restrictions. However, it does not explicitly compare to alternative tools like grep_files or get_file_info.
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?
With no annotations, the description carries the full burden. It describes a read-only listing with no side effects, but could mention if there are any constraints like rate limits or whether the list is cached.
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?
Two sentences in first paragraph clearly state purpose and nuance; second paragraph adds current state. While efficient, the second paragraph slightly repeats the purpose.
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 simplicity (no parameters, no output schema), the description is fully complete: explains what it shows, includes subdirectory behavior, and provides usage guidance.
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?
No parameters, so baseline 4. The description adds no parameter info because none exist, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it displays all accessible directories, includes the nuance of subdirectory implicit accessibility, and distinguishes from sibling tools like list_directory and register_directory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (to determine filesystem scope before file access), notes the current state (no directories), and directs to register_directory as an alternative for adding directories.
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?
Discloses key behaviors: 'Overwrites without confirmation', only works in allowed directories, and how content is interpreted (HTML vs plain text). Also warns about multi-line encoding issues. No annotations present, so description fully covers behavioral traits.
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?
Well-structured with sections, but slightly lengthy. Front-loaded with purpose. Could be more concise by trimming the HTML tag list, but still efficient given the valuable info.
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?
Comprehensive for a write tool: covers formats, encoding, directory limitations, and multi-line handling. No output schema, but return behavior is implied. Appropriate given sibling tools and no nested objects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond the input schema: path context (allowed directories) and extensive content details (format support, HTML tags, multi-line instructions). Schema coverage is 50%, but the description compensates fully.
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?
Clearly states 'Create/replace files' and specifies supported formats (text, PDF, DOCX with HTML). Distinguishes from sibling tools like edit_file (for modifying) and read_file (for reading) by focusing on writing and specific formats.
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 on multi-line content formatting and allowed directories. Implies appropriate use for creating/replacing files, but does not explicitly state when not to use or mention alternatives like edit_file for editing.
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:

[![vulcan-file-ops MCP server](https://glama.ai/mcp/servers/n0zer0d4y/vulcan-file-ops/badges/card.svg)](https://glama.ai/mcp/servers/n0zer0d4y/vulcan-file-ops)

Score Badge

Copy to your README.md:

[![vulcan-file-ops MCP server](https://glama.ai/mcp/servers/n0zer0d4y/vulcan-file-ops/badges/score.svg)](https://glama.ai/mcp/servers/n0zer0d4y/vulcan-file-ops)

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/n0zer0d4y/vulcan-file-ops'

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