Allows Claude to inspect, analyze, and grade local Git repositories, including language stats, TODO tracking, git history, large-file detection, repo health scoring, and tech stack fingerprinting.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DevInsight MCP Check the health of this repository."
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.
A lightweight Model Context Protocol (MCP) server that gives Claude the ability to inspect, analyze, and grade local Git repositories.
Built with Anthropic's official Python MCP SDK, DevInsight demonstrates all three MCP primitives — Tools, Resources, and Prompts — through practical developer workflows: language stats, TODO tracking, git history, large-file detection, an overall repo health score, and technology-stack fingerprinting.
A live session driving the DevInsight tools against this very repository — repo stats, TODO scan, and large-file detection.
Related MCP server: MCP Git Explorer
📊 Repository statistics — languages, file counts, line counts
📝 Scan projects for TODO, FIXME, HACK, and XXX
📜 Summarize recent Git commits (author, date, message, +/- lines)
📁 Detect oversized source files that are due for a refactor
🩺 Score overall repository health (README/LICENSE/tests/git, TODO density, file size) with concrete recommendations
🧰 Fingerprint a project's tech stack — languages, frameworks, databases, package managers, CI/CD, deployment
🌳 Browse repositories through an MCP Resource
🤖 Review and prioritize TODOs using an MCP Prompt
Scanning automatically skips noise: .git, .github, node_modules, virtualenvs, build/cache directories, lock files, and binary assets — see Repository Scanning below.
Developers spend a surprising amount of time manually inspecting repositories:
searching for TODOs
checking Git history
counting files
finding oversized modules
judging whether a project is in good shape before diving in
DevInsight exposes these tasks as MCP tools so Claude can perform them for you, directly in conversation.
Instead of manually searching your project, you can simply ask:
"Summarize the last 10 commits."
"Find every TODO and tell me which ones are most important."
"Which files are becoming too large?"
"How healthy is this repo, and what should I fix first?"
"What's the tech stack of this project?"
git clone https://github.com/AzamHosseinian/devinsight-mcp.git
cd devinsight-mcppython3 -m venv .venv
source .venv/bin/activateWindows:
.venv\Scripts\activatepip install -r requirements.txtThe easiest way to test the server standalone is with the official MCP Inspector:
mcp dev server.pyThe Inspector lets you invoke every Tool, inspect Resources, test Prompts, and debug raw responses — all in the browser, no client app required.
Add DevInsight to your claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"devinsight": {
"command": "/absolute/path/to/devinsight-mcp/.venv/bin/python3",
"args": [
"/absolute/path/to/devinsight-mcp/server.py"
]
}
}
}Using the virtual environment's Python interpreter (rather than a bare python) ensures Claude Desktop finds the mcp package regardless of what's active in your shell.
Fully quit and reopen Claude Desktop afterwards — it only reads this file on startup. Then try:
Use
repo_statson ~/projects/my-app
or
Review all TODOs in this repository.
Primitive | Name | Purpose |
Tool |
| Language and line-count breakdown |
Tool |
| Find TODO / FIXME / HACK / XXX comments |
Tool |
| Summarize recent Git activity |
Tool |
| Detect files exceeding a configurable size |
Tool |
| Overall 0-100 health score with recommendations |
Tool |
| Detect languages, frameworks, databases, package managers, CI/CD, deployment |
Resource |
| Render the repository tree |
Prompt |
| Ask Claude to prioritize TODOs |
repo_stats(path="~/projects/my-app")
→ { "total_files": 142, "total_lines": 18734,
"by_extension": { ".ts": {...}, ".tsx": {...}, ... } }
find_todos(path=".", max_results=50)
→ [ { "file": "src/api.ts", "line_number": 42,
"tag": "TODO", "text": "handle retry backoff" }, ... ]
git_log_summary(path=".", count=5)
→ { "commits": [ { "hash": "a1b2c3d4", "author": "...",
"date": "2026-07-10", "message": "...",
"insertions": 12, "deletions": 3 }, ... ] }
find_large_files(path=".", threshold_lines=300)
→ [ { "file": "src/legacy/parser.py", "lines": 812 }, ... ]
repo_health(path=".")
→ { "score": 78,
"checks": { "has_git": true, "has_readme": true,
"has_license": true, "has_tests": false },
"recommendations": [ "Add a test suite ..." ] }
tech_stack(path=".")
→ { "languages": ["Python"], "frameworks": ["FastAPI"],
"databases": ["PostgreSQL"], "package_managers": ["pip"],
"ci_cd": ["GitHub Actions"], "deployment": ["Docker"] }Statistics tools (repo_stats, find_todos, find_large_files, repo_health) walk the repo while pruning directories as they go — ignored subtrees are never descended into.
Ignored directories: .git, .github, node_modules, venv, .venv, env, __pycache__, dist, build, .next, .nuxt, .svelte-kit, .idea, .vscode, target, coverage, htmlcov, .pytest_cache, .mypy_cache, .cache
Excluded from statistics: lock files (package-lock.json, pnpm-lock.yaml, yarn.lock, poetry.lock, Cargo.lock, Gemfile.lock, composer.lock, uv.lock, bun.lockb) and binary assets (.png, .jpg, .jpeg, .gif, .pdf, .zip, .exe, .dll) — these are real project content, but noise in line/size stats.
tech_stack looks at these same files directly, since a lock file's mere presence is a useful package-manager signal.
Claude Desktop
│
▼
DevInsight MCP Server
│
┌───────────────┼───────────────┐
▼ ▼ ▼
Git Repository File System Git Historydevinsight-mcp/
├── server.py
├── requirements.txt
├── pyproject.toml
├── README.md
├── docs/
│ ├── demo.gif
│ ├── demo.tape
│ └── demo_cli.py
└── .gitignoreRepository statistics
TODO scanner
Git history summaries
Large file detection
Repository tree resource
TODO review prompt
Overall repo health score
Tech stack detection
Lint summary tool
GitHub Issues integration
Dependency vulnerability analysis
Pull request insights
Python
Anthropic MCP Python SDK
Git
Claude Desktop
Model Context Protocol (MCP)
Contributions, suggestions, and feedback are welcome.
If you'd like to improve DevInsight, feel free to open an issue or submit a pull request.
MIT — see LICENSE.
Flag source files that are unusually large — often a signal they're due for a refactor or split.
Args: path: Filesystem path to the repo root. threshold_lines: Minimum line count to be flagged (default 300). top_n: Max number of files to return, largest first (default 10).
Returns: List of {file, lines} dicts, sorted largest first.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | . | |
| top_n | No | ||
| threshold_lines | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the tool scans files, counts lines, and returns the largest files over a threshold. It does not mention non-destructive nature (e.g., read-only), but the behavior is well-described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It leads with the purpose, then lists parameters and return format. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with an output schema implied by the description, the description is nearly complete. It might benefit from specifying whether directory scanning is recursive or not, but overall provides sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes an Args section that explains each parameter (path, threshold_lines, top_n) with default values and purpose. This adds meaningful context beyond the schema's titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Flag source files that are unusually large — often a signal they're due for a refactor or split.' It uses a specific verb ('flag') and resource ('source files'), and distinguishes from sibling tools which focus on other aspects like todos, git logs, or repo stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when files are candidates for refactoring) but does not explicitly state when not to use or suggest alternatives. However, it effectively communicates the context of use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a repo for TODO / FIXME / HACK / XXX comments.
Args: path: Filesystem path to the repo root. max_results: Cap on how many matches to return (default 100).
Returns: List of {file, line_number, tag, text} dicts, one per match found.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | . | |
| max_results | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It discloses basic behavior (scan, return list of matches) and parameters, but omits details like recursion depth, file type filtering, or performance implications. It is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—only 5 lines including Args/Returns. Every sentence adds information. The structure with Args and Returns clearly separates parameter and outcome details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return format, but it does anyway. It covers basic usage and returns. However, it does not specify whether all file types are searched or if hidden files are included, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must explain parameters. It does so for both 'path' (Filesystem path to the repo root) and 'max_results' (cap on matches, default 100). This adds value beyond type/default, though explanations are brief.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans a repo for TODO/FIXME/HACK/XXX comments. The verb 'scan' and specific resource 'repo' are unambiguous. Sibling tools like find_large_files and git_log_summary handle different tasks, so differentiation is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when wanting to find code comments, but it does not explicitly state when to use this tool versus alternatives. No mention of when not to use or which sibling tool might be appropriate for other tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize the most recent git commits in a repo: author, date, message, and how many lines were added/removed.
Args: path: Filesystem path to the repo root (must be a git repo). count: How many recent commits to include (default 10).
Returns: Dict with a list of commits, or an error if this isn't a git repo.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | . | |
| count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden. It discloses that the tool returns a dict with commits or an error for non-git repos, and mentions the output includes line additions/removals. It does not discuss performance implications or edge cases, but the behavior is adequately transparent for a simple read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-sentence summary of functionality, followed by parameter explanations and return type. Every sentence is essential and well-structured, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and absence of output schema, the description covers the key aspects: what it does, what it returns, and a basic failure mode. It does not detail the exact structure of the returned dict, but this is implied by the summary. Overall, it is sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% coverage. It explains that 'path' is the filesystem path to a git repo root and 'count' is the number of recent commits, including default behavior. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool summarizes recent git commits with specific fields (author, date, message, lines added/removed). It is well-distinguished from siblings such as find_large_files, repo_stats, and tech_stack, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the tool is for summarizing recent commits and includes a prerequisite (the path must be a git repo). However, it does not explicitly mention when not to use it or suggest alternatives among siblings, which would strengthen guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Give a repository an overall health score with supporting evidence.
Checks for a README, a LICENSE, a test suite, and Git version control, plus TODO density and oversized files, then rolls it all into a single 0-100 score with concrete recommendations.
Args: path: Filesystem path to the repo root. large_file_threshold: Line count above which a file counts as "large".
Returns: Dict with score, component checks, counts, largest_files, and a list of recommendations for the lowest-scoring areas.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | . | |
| large_file_threshold | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It transparently lists what it checks and the output structure (score, component checks, recommendations). However, it does not explicitly state that the tool is read-only or non-destructive, which is implied but not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient: two paragraphs for purpose and a brief Args section. It front-loads the goal and key checks. Could be slightly more structured (e.g., bullet points), but overall no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers return values (dict with score, component checks, counts, largest_files, recommendations). It explains all checks and parameters. Minor omission: no example score range or clarification on 'concrete recommendations'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description's 'Args' section adds critical meaning beyond the schema. It explains 'path' as filesystem path to repo root and 'large_file_threshold' as line count threshold for large files. This is helpful, though could specify expected format (e.g., absolute vs relative).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Give') and clearly states it produces an overall health score with supporting evidence. It lists explicit checks (README, LICENSE, test suite, Git, TODO density, oversized files) and differentiates from siblings like find_large_files or find_todos, which focus on single aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining a repository health score but does not explicitly state when to use this tool versus alternatives like find_large_files or git_log_summary. No when-not-to guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a language and size breakdown for a local repository.
Args: path: Filesystem path to the repo root (default: current directory).
Returns: Dict with total_files, total_lines, and a per-extension breakdown (files + lines), sorted by line count descending.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | . |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It transparently describes the return structure (total_files, total_lines, per-extension breakdown) and sorting. It's a read operation with no destructive behavior. Could mention potential performance impact for large repos, but overall clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences covering purpose, arguments, and returns. Front-loaded with purpose. No redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter and no output schema, the description fully covers input, behavior, and output. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, path, is explained: 'Filesystem path to the repo root (default: current directory).' This adds meaning beyond the schema (which only specifies type and default). With 0% schema description coverage, the description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a language and size breakdown for a local repository. It specifies the verb 'Get' and the resource 'local repository', and is distinct from sibling tools like find_large_files or tech_stack.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The context implies it's for initial repo analysis, but lacks explicit when/when-not or comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect a project's technology stack from its manifest and config files.
Looks for common manifests (pyproject.toml, requirements.txt, package.json, Dockerfile, docker-compose.yml, GitHub Actions workflows, Cargo.toml, go.mod, composer.json, build.gradle, and more), and inspects package.json / requirements.txt contents for known frameworks and databases.
Args: path: Filesystem path to the repo root.
Returns: Dict with sorted lists for languages, frameworks, databases, package_managers, ci_cd, and deployment, plus the manifest files that were found.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | . |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It describes scanning files and inspecting contents, but does not disclose if modifications occur (it is read-only), error handling, or side effects. The return dict is listed, but behavioral details like path validation are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loads the main purpose, and includes Args and Returns sections. Every sentence adds value, though it could be slightly more succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and no output schema, the description fully explains the input and details the return dict (languages, frameworks, databases, etc.). This is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description explains the 'path' parameter as 'Filesystem path to the repo root', adding meaning beyond the schema. This compensates for the schema gap, though no other parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: detect a project's technology stack from manifests and config files. It lists specific files and inspection details, distinguishing it from siblings which deal with file size, todos, git logs, health, and stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for tech stack detection, but no explicit guidance on when to use vs alternatives or when not to use. Sibling tools have distinct purposes, so no direct competition, but no 'when-not' or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0find_large_filesfind_todosgit_log_summaryrepo_healthrepo_statstech_stackEach tool targets a distinct aspect of repository analysis—large files, TODOs, git log, health, stats, and tech stack. There is no functional overlap between tools.
All names use snake_case and are descriptive, but there is a mix: two start with 'find_' (verb) while the rest start with nouns like 'git_log_', 'repo_', 'tech_'. This is a minor inconsistency.
Six tools form a well-scoped set for a repository insights server. Each tool provides a distinct, valuable capability without being excessive or insufficient.
The set covers core areas: file analysis, TODOs, git history, overall health, stats, and tech stack. Missing features like complexity or dependency analysis are not critical gaps given the tool count.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Generate SBOMs, scan vulnerabilities, and analyze dependencies from local projects or Git repos.
Screens public GitHub repos and PRs to generate risk maps, findings, and merge-readiness signals.
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AzalHoseinian/devinsight-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
