What can you do with this server?

Repomind-MCP provides a local, private, and efficient suite of tools for AI coding assistants to understand codebase structure, dependencies, and impact of changes, without loading entire file contents into context. * Workspace Scanning: Use repomind_scan_workspace to recursively scan a workspace, producing a file tree, source file listing, and statistics (counts, sizes by type), while automatically ignoring noise like node_modules, .git, and dist. * Dependency Analysis: repomind_get_dependencies parses imports in JavaScript, TypeScript, and Python files to build a directed dependency graph showing direct and transitive relationships for a file or directory. * Architecture Diagrams: repomind_generate_diagram creates a Mermaid diagram of the dependency graph, optionally scoped to specific files or directories and grouped by parent folder into subgraphs. * Impact Analysis: repomind_impact_analysis performs reverse-dependency BFS from a target file to identify all files that depend on it (directly or indirectly), revealing the blast radius of a change with configurable traversal depth. * Raw Graph Access: Exposes a resource repomind://workspace/graph for direct JSON inspection of the full dependency graph. * Prompt Templates: Provides pre-built prompts architecture-review and blast-radius-check that incorporate live project data for structured code reviews.

How do I use RepoMind-MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@RepoMind-MCP analyze dependencies of src/main.ts" 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.

RepoMind-MCP

by doridoor

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

RepoMind-MCP

npm version License: MIT

A local Model Context Protocol server that gives AI coding assistants a map of your codebase — file structure, import graph, and "what breaks if I change this file" — without dumping the whole repo into the model's context.

It runs entirely on your machine over stdio. No network calls, no uploading code anywhere.

Quick Start

Add this to your MCP client config (e.g. Claude Desktop's claude_desktop_config.json):

{
  "mcpServers": {
    "repomind-mcp": {
      "command": "npx",
      "args": ["-y", "repomind-mcp"]
    }
  }
}

Restart your client. The assistant can now call the tools below whenever it needs to understand your project's layout instead of guessing.

Related MCP server: mcp-server-ts-analysis

What it actually does

Ask your assistant something like "what would break if I change src/auth.ts?" or "give me an architecture diagram of this project" — it reaches for one of these tools instead of grepping blindly:

Tool	Answers the question...	Key argument
`repomind_scan_workspace`	"What's in this project?" — file tree, counts, sizes by type	`basePath`
`repomind_get_dependencies`	"What does this file import, directly and transitively?"	`targetPath`
`repomind_generate_diagram`	"Draw me the architecture" — Mermaid diagram grouped by folder	`scopePaths` (optional)
`repomind_impact_analysis`	"What breaks if I change this file?" — reverse dependency BFS	`targetPath`, `depth`

All paths are absolute and everything runs against your local filesystem — node_modules, .git, dist, and other build/binary noise is ignored automatically. Supports JavaScript, TypeScript, and Python import resolution.

Under the hood, a single in-memory dependency graph (keyed by file mtime, see src/cache.ts) backs all four tools, so repeated calls on an unchanged workspace are fast.

Also exposed

Resource repomind://workspace/graph — the full serialized dependency graph as JSON, for clients that want to inspect it directly rather than calling a tool.
Prompts architecture-review and blast-radius-check — pre-built prompt templates that pull in the live file tree / impact analysis so the assistant reviews your actual code, not a hypothetical one.

Local Development

Only needed if you're modifying RepoMind-MCP itself — most users just want the Quick Start above.

npm install
npm run build   # compiles src/ (TypeScript) -> dist/ (ESM)
npm start        # runs the server on stdio

Point your client at the compiled entry point instead of npx:

{
  "mcpServers": {
    "repomind-mcp": {
      "command": "node",
      "args": ["/absolute/path/to/RepoMind-MCP/dist/index.js"]
    }
  }
}

Testing

scratch/test-server.js spins up the built server and drives it through a handful of JSON-RPC tool calls end-to-end:

npm run build && node scratch/test-server.js

License

MIT

Available Tools

4 tools

repomind_generate_diagramB

Generates a beautiful visual Mermaid diagram representing the dependency graph of the files. Can group files by their parent directories into subgraphs.

ParametersJSON Schema

Name	Required	Description	Default
`scopePaths`	No	Optional absolute paths of files or directories to restrict the scope of the diagram. If omitted, maps the entire workspace.
`diagramType`	No	The type of diagram to generate. Currently supports 'mermaid'.	mermaid
`workspaceRoot`	No	Optional absolute path of the workspace root to resolve imports. Defaults to finding it from scopePaths or process.cwd().

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states the core action of generating a diagram and optionally grouping by directories. It does not disclose whether the tool is read-only, any required permissions, or how output is returned.

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, front-loaded with the main purpose, and avoids redundancy. The word 'beautiful' is non-essential but does not significantly detract.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the basic function and one key feature, but lacks clarity on return value format and the effect of optional parameters, though these are documented in the schema. Without annotations or output schema, it is minimally adequate but not comprehensive.

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?

The schema already documents all three parameters with descriptions, so the description adds no additional meaning. The mention of grouping by directories is a feature detail, not tied to specific parameter usage.

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 generates a Mermaid diagram of the dependency graph, which is distinct from sibling tools that scan, get dependencies, or analyze impact. The verb 'Generates' and resource 'Mermaid diagram' are specific and actionable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives; it does not mention that get_dependencies should be used for raw data or impact_analysis for impact assessment. Usage is only implied by the description's purpose.

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

repomind_get_dependenciesA

Analyzes imports in JavaScript, TypeScript, and Python files within a target path (file or directory) to build a directed dependency graph showing local module relationships.

ParametersJSON Schema

Name	Required	Description	Default
`targetPath`	Yes	The absolute path to the file or directory to analyze for dependencies.

TDQS

A4/5.0

Behavior4/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. It clearly indicates a read-only analysis operation (no side effects) and specifies supported languages and output type (directed dependency graph). It lacks details on scalability or edge cases, but for a simple analysis tool it is sufficiently transparent.

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 well-structured sentence that front-loads the core function and includes essential qualifiers (languages, file/directory, output type). Every word earns its place with no fluff or repetition.

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 (one parameter, no output schema), the description is largely complete: it specifies the input path, languages analyzed, and the output graph. It could mention return format or limitations, but these are less critical for a read-only analysis tool in the context of sibling tools.

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% for the single parameter targetPath, which already defines it as an absolute path to a file or directory. The description adds no new information about parameter semantics beyond what the schema states, so a baseline of 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 the tool analyzes imports in JavaScript, TypeScript, and Python files and builds a directed dependency graph. It uses specific verbs and resources, and it distinguishes itself from siblings by focusing on dependency graph construction rather than scanning, diagramming, or impact analysis.

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 should be used to analyze dependencies in a given path, but it does not explicitly state when to prefer this over sibling tools like repomind_scan_workspace or repomind_impact_analysis. There is no mention of exclusions or alternative usage context.

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

repomind_impact_analysisA

Calculates the downstream blast radius (reverse dependents) of modifying a target file or module, showing exactly which files depend on it directly or indirectly.

ParametersJSON Schema

Name	Required	Description	Default
`depth`	No	The maximum traversal depth for reverse lookup (defaults to 3).
`targetPath`	Yes	The absolute path to the target file to assess.

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It adds meaningful context by explaining the tool shows 'directly or indirectly' dependent files, hinting at recursive traversal. However, it does not detail the output format, performance implications, or how depth is handled beyond what the schema already states. This is minimal but non-contradictory.

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, focused sentence that clearly conveys the tool's purpose without any filler or repetition. Every part contributes meaning.

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 two-parameter schema and clear purpose, the description is complete enough for an agent to select and invoke the tool. It lacks an output schema, but the description implies a list of dependent files. It could be slightly more detailed about output format, but overall it is adequate.

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% with both targetPath and depth having descriptions. The description adds 'directly or indirectly' which maps to depth traversal but does not provide substantial additional semantics. Baseline 3 applies because the schema already explains parameters.

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 function: 'Calculates the downstream blast radius (reverse dependents) of modifying a target file or module, showing exactly which files depend on it directly or indirectly.' This uses a specific verb and resource, and distinguishes it from siblings like repomind_get_dependencies (forward dependencies) by emphasizing reverse dependents.

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 implies a clear use case: assessing the impact of modifying a file or module. It states the purpose ('if modifying a target file') but does not explicitly mention alternatives or exclusions. This is clear context without explicit when-not-to-use guidance, matching the 'clear context, no exclusions' level.

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

repomind_scan_workspaceA

Recursively scans a workspace directory, mapping its file structure, listing source files, and providing statistics, while ignoring binary/build folders (e.g. node_modules, .git, dist).

ParametersJSON Schema

Name	Required	Description	Default
`basePath`	Yes	The absolute path to the workspace root directory to scan.

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses that the scan is recursive, ignores binary/build folders (node_modules, .git, dist), and provides statistics. However, it does not explicitly state that the operation is read-only or mention any potential side effects, performance implications, or error conditions.

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, well-structured sentence that front-loads the main action ('Recursively scans'), then adds specific details about ignored folders and outputs. Every clause earns its place, with no superfluous information.

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 adequately covers the tool's behavior and output by mentioning file structure mapping, source file listing, and statistics. It could be more specific about the return format (e.g., JSON object), but the current level is sufficient for a straightforward scan.

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?

The only parameter, basePath, is fully described in the schema ('The absolute path to the workspace root directory to scan'). The description adds no extra meaning beyond repeating that it is the workspace root. Baseline 3 is appropriate given 100% schema coverage.

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 verb ('Recursively scans'), resource ('workspace directory'), and scope ('mapping its file structure, listing source files, and providing statistics'). It also distinguishes itself from siblings by specifying it ignores binary/build folders, which is unique among the listed 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 usage for scanning a workspace to understand its structure, but does not explicitly state when to use this tool versus alternatives like repomind_generate_diagram or repomind_impact_analysis. No exclusions or explicit 'use this when...' guidance is provided.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv2.0.1Aug 2, 2026
- First observedrepomind_generate_diagram
- First observedrepomind_get_dependencies
- First observedrepomind_impact_analysis
- First observedrepomind_scan_workspace

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored 2026-08-02 20:30 across 4 tools

Disambiguation5/5

Each tool targets a distinct phase of repository analysis: scanning structure, computing dependencies, generating diagrams, and calculating impact. No overlap or ambiguity exists between them.

Naming Consistency5/5

All tools follow the consistent pattern 'repomind_<verb>_<object>' with snake_case throughout. The verb-noun construction is uniform and predictable across the set.

Tool Count5/5

Four tools is an ideal size for a focused repository analysis server. Each tool earns its place and there is no bloat or redundancy.

Completeness5/5

The tool set forms a complete workflow: scan a workspace, extract dependencies, visualize them, and analyze impact. No obvious gaps exist for the stated purpose of repository analysis.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Meeba Brain A
io.github.meemoprasad
Repository knowledge graph MCP server for codebase understanding and debugging.
Code Analysis Developer Tools
51
neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320
Android Security Analyzer A
io.github.ako2345
MCP server for static security analysis of Android source code
Security Code Analysis Testing & QA Tools
422
Caplia AOAuth
io.github.Caplia-Tech
MCP server for VC pitch-deck scoring, thesis-fit matching, and deal-flow management.
Finance AI & Machine Learning
2

Related MCP Servers

Code-Oracle
Code Analysis Security Developer Tools
Sri-Lohith-Mulugu
F
license
Not graded
quality
D
maintenance
MCP server for automated architectural mapping, security vulnerability detection, ML asset tracking, and code metrics in local repositories.
Updated 5 months ago (2026-04-21 10:35 UTC)
-
mcp-server-ts-analysis
Developer Tools Code Analysis
akshay-nm
F
license
B
quality
C
maintenance
MCP server for TypeScript type resolution and dependency graph analysis using ts-morph and madge.
Updated 7 months ago (2026-03-01 07:58 UTC)
8
1
-
ast-impact-mapper-mcp
Code Analysis Testing & QA Tools Developer Tools
vola-trebla
A
license
A
quality
C
maintenance
MCP server that analyzes TypeScript/JavaScript codebases via AST parsing and dependency graph tracing to identify affected tests, detect dead code, circular dependencies, and trace import chains, enabling AI agents to run only relevant tests.
Updated 4 months ago (2026-05-21 12:59 UTC)
15
28 npm
MIT
repo-cartographer
Code Analysis Software Architecture
builditwithgk
A
license
A
quality
A
maintenance
An MCP server that maps any repository into architecture diagrams, providing tools for scanning code facts, building import graphs, and generating Mermaid/DOT diagrams, plus architecture rule enforcement for CI.
Updated a month ago (2026-08-05 15:32 UTC)
5
31 npm
1
MIT