How do I use Repository Analyzer MCP Server?

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., "@Repository Analyzer MCP Server analyze the repository structure" 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.

Repository Analyzer MCP Server

by DocNR

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Repository Analyzer MCP Server

A Model Context Protocol (MCP) server that provides tools for analyzing code repositories, with a special focus on Nostr-related projects.

Features

Analyze code structure, components, dependencies, and recent changes
Search through repository code with pattern matching
View git history for the entire repository or specific files
Access file content and directory listings
Special tools for analyzing NDK (Nostr Development Kit) repositories
Analyze Nostr Protocol implementations and NIPs (Nostr Implementation Possibilities)

Related MCP server: Git Analytics MCP Server

Installation

Clone this repository
Install dependencies:

npm install

Build the project:

npm run build

Usage

Setting the Repository Path

The MCP server handles file paths in the following ways:

Default Access Behavior

Default access: By default, the server will access the current working directory (cwd) if no path is specified.
Configure specific directories: To specify what directories Claude can access, set the DEFAULT_REPO_PATH environment variable in the Claude config.
Per-command overrides: Users can override the default path with the repoPath parameter in their commands, like:
```
analyze-code --focus=structure --repoPath=/another/directory
```
Client permissions: Remember that Claude for Desktop will ask for permission before executing tools that access your filesystem.

Analyzing Multiple Repositories

You can analyze multiple repositories without restarting the server by specifying the repository path directly in your commands:

# Analyze structure of a specific repository
analyze-repo --focus=overview --repoType=generic --repoPath=/path/to/specific/repo

# Analyze code in a different repository
analyze-code --focus=structure --path=src/index.js --repoPath=/path/to/another/repo

# Search for patterns in yet another repository
search-code --query="addEventListener" --filePattern="*.js" --repoPath=/path/to/third/repo

All analysis tools (analyze-repo, analyze-code, search-code, git-history, analyze-ndk, analyze-ndk-files, and analyze-nostr-protocol) accept a repoPath parameter which overrides the default path.

Connecting to Claude Desktop

To connect this MCP server to Claude Desktop:

Edit your Claude Desktop config file:

# On macOS
nano ~/Library/Application\ Support/Claude/claude_desktop_config.json
# On Windows
# Edit %AppData%\Claude\claude_desktop_config.json

Add the server configuration:

{
  "mcpServers": {
    "repo-analyzer": {
      "command": "node",
      "args": [
        "/absolute/path/to/repo-analyzer-mcp/dist/index.js"
      ],
      "transport": "stdio",
      "env": {
        "NODE_ENV": "production",
        "DEFAULT_REPO_PATH": "/path/to/default/repository"
      }
    }
  }
}

Replace /absolute/path/to/repo-analyzer-mcp with the actual full path to where you installed this tool, and /path/to/default/repository with the path to the repository you want to analyze by default.

Save the file and restart Claude Desktop.

Troubleshooting

If Claude Desktop fails to start or the MCP servers don't appear:

Check your configuration file for JSON syntax errors
Ensure all paths are absolute (full) paths and are correct
Make sure there are no trailing commas after the last entry in each object
Check Claude Desktop logs for errors: ~/Library/Logs/Claude/mcp*.log
For additional debugging, you can add "DEBUG": "mcp:*" to the env section of your configuration
Restart Claude Desktop

Available Tools

analyze-code

Analyzes code files with different focus options:

structure: Examines the file structure, including line counts, functions, classes, etc.
components: Identifies React components, hooks usage, etc.
dependencies: Lists imports and dependencies
changes: Shows recent git history and changes to the file

Example:

Analyze the code structure of src/index.ts

search-code

Searches the repository for specific patterns, with optional file pattern filtering.

Example:

Search the code for "addEventListener" in .js files

git-history

Retrieves git commit history for the repository or a specific file.

Example:

Show me the git history for README.md, limit to 5 commits

analyze-ndk

Analyzes Nostr Development Kit (NDK) repositories with focus on:

implementation: Core implementation details
migrations: Version changes and migration guides
all: Both implementation and migrations

Example with explicit repository path:

Analyze NDK implementation at /path/to/ndk-repo

analyze-ndk-files

Explores the NDK file structure with focus on:

overview: General overview of the repository
components: Component architecture
api: API structure and design
architecture: Overall architecture and patterns
all: Comprehensive analysis

Example with explicit repository path:

Analyze NDK files with focus on components at /path/to/ndk-repo

analyze-nostr-protocol

Analyzes Nostr protocol repositories with focus on:

events: Event types and structures defined in NIPs
implementations: Implementation details across different languages

Example with explicit repository path:

Analyze Nostr Protocol events at /path/to/nips-repo with focus on social context

analyze-repo

Provides a general repository analysis with various focus options:

overview: High-level repository information
components: Component structure and organization
api: API definitions and structure
architecture: Overall architectural patterns
implementation: Implementation details
all: Comprehensive analysis of all aspects

Example:

Analyze the repo with focus on architecture

Resources

The server also provides access to:

file://{filePath}: Read file contents from the repository
dir://{dirPath}: List directory contents from the repository

Example:

Show me the content of the package.json file

Directory Structure for Specialized Analysis

For the specialized analysis tools to work correctly, repositories should follow certain structures:

NDK Repository Structure

The analyzer looks for one of these structures:

A repository with a root package.json that has the name @nostr-dev-kit/ndk
A repository with an ndk directory containing a package.json with the name @nostr-dev-kit/ndk

Nostr Protocol Repository Structure

The analyzer looks for one of these structures:

A repository with a nips directory containing Markdown files for NIPs
A repository with a README mentioning "NIP" and "Nostr Implementation Possibilities"
A repository with a package.json that references "nostr" in its name, description, or keywords

Development

To run in development mode:

npm run dev

License

MIT

Available Tools

8 tools

analyze-codeD

ParametersJSON Schema

Name	Required	Description
`path`	No	Path to file within the repository
`focus`	Yes	Analysis focus area
`repoPath`	No	Repository path override

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

analyze-ndkD

ParametersJSON Schema

Name	Required	Description
`focus`	Yes	Analysis focus
`includeCode`	No	Include code snippets in the analysis
`repoPath`	No	Repository path override

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

analyze-ndk-filesD

ParametersJSON Schema

Name	Required	Description
`focus`	Yes	Analysis focus
`context`	No	Optional context filter
`includeCode`	No	Include code snippets in the analysis
`repoPath`	No	Repository path override

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

analyze-nostr-protocolD

ParametersJSON Schema

Name	Required	Description
`focus`	Yes	Analysis focus
`context`	No	Optional context filter
`includeCode`	No	Include code snippets in the analysis
`repoPath`	No	Repository path override

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

analyze-repoD

ParametersJSON Schema

Name	Required	Description
`repoType`	Yes	Type of repository to analyze
`focus`	Yes	Analysis focus
`context`	No	Optional context filter (e.g., 'workouts', 'social', 'profiles')
`includeCode`	No	Include code snippets in the analysis
`repoPath`	No	Repository path override

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

debug-pathD

ParametersJSON Schema

Name	Required	Description	Default
`repoPath`	No	Repository path to debug

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

git-historyD

ParametersJSON Schema

Name	Required	Description
`file`	No	File path to view history (empty for repo history)
`limit`	No	Number of commits to return
`repoPath`	No	Repository path override

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

search-codeD

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Search query pattern
`filePattern`	No	File pattern to filter search results
`repoPath`	No	Repository path override

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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.

8 tool updatesv1.0.0Jun 4, 2026
- First observedanalyze-code
- First observedanalyze-ndk
- First observedanalyze-ndk-files
- First observedanalyze-nostr-protocol
- First observedanalyze-repo
- First observeddebug-path
- First observedgit-history
- First observedsearch-code

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

D1.5/5.0

Scored 2026-06-04 07:50 across 8 tools

Disambiguation2/5

Multiple tools share the 'analyze-' prefix with no descriptions, making it impossible for an agent to distinguish between targets like code, ndk, repo, etc. Some tools like debug-path and git-history have unique names but lack descriptions, still causing ambiguity.

Naming Consistency2/5

The naming convention is mixed: most tools use 'analyze-<subject>' but three diverge with different verbs (debug, git, search). This inconsistency disrupts predictability.

Tool Count4/5

With 8 tools, the count is reasonable for a repository analysis server. It covers several analysis facets without being overwhelming.

Completeness2/5

The tool surface appears focused on analysis but lacks operations for managing results, listing analyses, or performing updates. Without descriptions, it's unclear if core workflows are supported.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

searchcode A
com.searchcode
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Search Code Analysis Version Control
72
SBOMApp - SBOM Generator & Vulnerability Scanner
io.github.mcpsbom
Generate SBOMs, scan vulnerabilities, and analyze dependencies from local projects or Git repos.
Developer Tools Security Testing & QA Tools
2
GitHub Repository IntelligenceOAuth
io.github.heisencodex-jpg
Repo intel for AI coding agents: overview, PRs, contributors, hot files, CI, deps. Remote MCP.
Version Control CI/CD & DevOps Code Analysis
2
XRay-VisionOAuth
com.emtailabs
AI-powered codebase analysis — call graphs, security, dead code, complexity. 150+ tools.
Code Analysis Developer Tools Autonomous Agents
2

Related MCP Servers

Gitingest MCP Server
Version Control Developer Tools Code Analysis
mattdepaolis
F
license
B
quality
D
maintenance
Enables analysis and querying of Git repository content (both public and private) through a unified tool that provides repository summaries, file structures, and full content optimized for LLM consumption.
Updated a year ago (2025-07-02 11:54 UTC)
1
-
Git Analytics MCP Server
Version Control Developer Tools Code Analysis
singhashish4000
F
license
B
quality
D
maintenance
Provides comprehensive Git repository insights including author statistics, branch health, and code churn analysis. It enables users to perform data-driven assessments of their codebase and track development patterns through the Model Context Protocol.
Updated a year ago (2025-06-15 15:51 UTC)
3
-
MCP Git Analysis Server
Version Control Developer Tools
Jaz-spec
F
license
Not graded
quality
D
maintenance
Analyzes local Git repositories to provide detailed insights into commit statistics, contributor activity, and frequently changed files. It allows users to query repository history and access structured activity data through the Model Context Protocol.
Updated a year ago (2025-10-09 15:46 UTC)
-
DevInsight MCP
Version Control Developer Tools Code Analysis
AzalHoseinian
A
license
A
quality
B
maintenance
Enables Claude to inspect, analyze, and grade local Git repositories with tools for stats, TODO scanning, git history, large file detection, health scores, and tech stack fingerprinting.
Updated 2 months ago (2026-07-14 16:11 UTC)
6
MIT