Project Explorer MCP Server

by MausRundung

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.0.0
Disambiguation5/5
Each tool targets a distinct operation: outdated package checking, file deletion, project exploration, directory listing, file renaming, and file search. There is no overlap in functionality.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with lowercase underscores (e.g., check_outdated, delete_file, explore_project). No deviations or mixed conventions.
Tool Count5/5
With 6 tools covering file exploration, operations, search, and npm package checking, the set is well-scoped for a project explorer server. Neither too many nor too few.
Completeness4/5
The tool surface covers key exploration and file management tasks, but missing obvious operations like reading file contents or creating files/directories. Minor gap given the explorer focus.
Average 4.2/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- Last stable release on August 12, 2026
- 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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: it always excludes build directories (node_modules, .git, dist), parses imports for JS/TS/TSX/JSX, and extracts declarations for common languages. No annotations exist, so the description carries the full burden. It does not mention error handling, performance implications, or authentication needs, but for a read-only exploration tool, the provided transparency is strong.
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, consisting of four sentences that each add distinct information. It is front-loaded with the primary action ('Lists all files...') and then expands on parsing and exclusions. No filler words or redundant statements. It could be slightly tighter by merging the parsing sentences, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (parsing multiple languages, dependency analysis) with 4 optional parameters and no output schema. The description omits the return format entirely—it does not specify whether the output is a list of file objects with size, imports, dependencies, or a summary. Without an output schema, the description should at least hint at the structure of the results. This is a significant gap that reduces the agent's ability to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all 4 parameters have descriptions). The description adds value by clarifying that build directories are always excluded and that the tool lists files with sizes, but it does not elaborate on the 'subDirectory' parameter or the 'includeHidden' impact beyond the schema. The description supplements the schema moderately but does not significantly enhance understanding beyond what the parameter descriptions already provide.
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 primary action: 'Lists all files in a directory with their sizes' and extends to parsing imports/exports for JS/TS/TSX/JSX, resolving dependency edges, and extracting similar declarations for other languages. This specific verb+resource combination distinguishes it from sibling tools like 'search_files' (searching) and 'list_allowed_directories' (listing directories only).
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 the tool is for exploring project structure and dependency analysis, but it does not explicitly state when to use it versus alternatives like 'search_files' or 'rename_file'. With five sibling tools, explicit guidance on exclusions (e.g., 'Use this when you need both file listing and dependency analysis, not just file search') would improve clarity.
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 provided, the description carries the full burden of behavioral disclosure. It notes the tool uses 'npm outdated' and requires npm, but does not disclose what happens if package.json is missing, if the directory is invalid, or any side effects (e.g., no modifications made). The behavioral impact is not fully detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three clear sentences: purpose, action, and prerequisite. Every sentence adds value without redundancy or fluff. It is well-structured for quick scanning by an AI agent.
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 moderate complexity (4 parameters, no output schema), the description provides sufficient high-level context to understand and invoke the tool correctly. It covers the core functionality and requirements, though a bit more detail on return values or error scenarios would push it to 5.
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 description coverage is 100%, so parameters are well-documented in the schema itself. The description adds context by linking the tool's operation to the underlying npm command, which helps understand the 'raw' output option. However, it does not elaborate on parameter usage beyond the schema, so a 4 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 the tool checks for outdated npm packages using 'npm outdated' and analyzes dependencies for newer versions. It distinguishes itself from sibling tools like explore_project or list_allowed_directories by focusing specifically on npm dependency updates.
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 when-to-use context: for checking outdated npm packages in a project. It mentions a prerequisite (npm installed and accessible). However, it does not explicitly exclude alternatives when a user might want other dependency checks or provide guidance on when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses that the operation fails if destination exists, works across directories, and requires paths within allowed directories, providing good behavioral insight.
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?
Description is 5 sentences, front-loads the main action, and every sentence contributes value. No redundant or extraneous text.
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?
Covers purpose, constraints, and behavior. Lacks mention of return values (no output schema) but sufficient for a file rename tool. Sibling tools provide context.
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% with parameter descriptions. The description adds context such as the constraint 'Both source and destination must be within allowed directories' and failure condition, enhancing understanding 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 renames/moves files or directories, specifying it can move between directories and rename in one operation. It distinguishes from siblings like delete_file and search_files by focusing on renaming/moving.
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 usage for renaming or moving files/directories and mentions failure if destination exists and path constraints, but does not explicitly state when not to use or suggest alternative tools among 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 the full burden. It states the operation cannot be undone, recursive requirement for directories, force option for read-only files. Does not detail return values or error conditions, but covers key 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each informative: purpose, caution, recursive condition, scope. No filler words, efficient and well-structured.
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?
Does not describe return values (e.g., success confirmation) or error handling (path not found, permission denied). Given no output schema, this gap is notable for a destructive tool.
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?
Parameter schema coverage is 100% with descriptions. The tool description adds context like 'Use with extreme caution' for the entire action, and clarifies 'recursive must be explicitly set to true' and 'force deletion even if read-only', supplementing 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 'Delete a file or directory' with the verb 'Delete' and resource 'file or directory'. It distinguishes from siblings like rename_file and search_files by emphasizing irreversibility.
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 warnings about caution and irreversibility, explains when recursive is needed, and mentions scope restrictions ('Only works within allowed directories'). Does not explicitly name alternatives but implies checking list_allowed_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?
No annotations are provided, so the description carries the full burden. It transparently discloses the return value (list of allowed directories) and the interpretation of an empty result. The tool has no side effects or destructive behavior, and the description covers the essential behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, very concise, and front-loaded with the primary action. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description is complete. It clearly states what is returned and the meaning of the empty list, covering all necessary information for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema has 100% coverage (empty). The description adds no parameter information because none is needed. Per the rubric, zero parameters earns a baseline of 4, and the description does not need to compensate.
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 'Returns' and the resource 'list of directories that this MCP server is allowed to access.' It is specific and distinguishes from sibling tools (explore_project, search_files, etc.) which perform different 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 explains the meaning of an empty list (unrestricted access) but does not explicitly state when to use this tool versus alternatives. While the context makes it self-evident, there is no direct guidance on prerequisites or scenarios.
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 discloses key behaviors: executes searches in allowed directories, supports content preprocessing (exclude comments/string literals), and offers multiple output formats with sorting/grouping. It also notes the default path behavior. While it does not explicitly state read-only safety, the nature of a search tool implies no side effects, and the description covers most operational aspects. A minor gap is the lack of mention about performance or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and efficiently front-loads the key purpose in the first two sentences. The third sentence breaks into multiple clauses covering defaults, advanced options, and output flexibility. There is minor redundancy ('advanced... with comprehensive filtering' and then listing filters), but overall every sentence provides distinct information. Could be slightly tighter, but it remains clear and functionally complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 24 parameters and no output schema or annotations, the description provides a solid overview. It covers default behavior, supported filters, output formats, and special features like comment exclusion. It does not mention the 'allowed directories' concept or how to discover them (a sibling tool list_allowed_directories exists but is not referenced). Also, 'common patterns' is vague. However, the schema fills many details, and the description is sufficient for an agent to understand the tool's role and basic usage.
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 description coverage is 100%, so every parameter already has a description. The tool description adds value by contextualizing groups of parameters: it lists regex, file type, size, date filtering, and content preprocessing as groups, and explains that excludeComments/excludeStrings are for 'cleaner code searches'. It also clarifies the default search behavior when no pattern is specified – information not explicitly in the schema. This enhances understanding beyond what the schema alone 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 identifies the tool as an advanced file and code search tool with comprehensive filtering. It specifies the verb 'searches for patterns in files' and the resource 'files within allowed directories'. It also lists key capabilities like regex, file type filtering, size constraints, date filtering, and content preprocessing, making the purpose unmistakable. The sibling tools are all different in nature (project exploration, file operations), so no additional differentiation needed.
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 useful context for when to use the tool: for pattern-based file searches with many filtering options. It mentions the default behavior when called without arguments ('searches for common patterns in the current directory'), which helps the agent decide when simple invocation suffices. However, it does not explicitly state when not to use it or compare it to alternatives, though 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.

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:

[![mcp-explorer MCP server](https://glama.ai/mcp/servers/MausRundung/mcp-explorer/badges/card.svg)](https://glama.ai/mcp/servers/MausRundung/mcp-explorer)

Score Badge

Copy to your README.md:

[![mcp-explorer MCP server](https://glama.ai/mcp/servers/MausRundung/mcp-explorer/badges/score.svg)](https://glama.ai/mcp/servers/MausRundung/mcp-explorer)

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/MausRundung/mcp-explorer'

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