Allows browsing and searching source code from Bitbucket-hosted .NET repositories.
Allows browsing and searching source code from GitHub-hosted .NET repositories.
Allows browsing and searching source code from GitLab-hosted .NET repositories.
Provides on-demand access to internal .NET / C# source code from NuGet packages.
Indexes NuGet-style packages to expose their source code, making private packages searchable.
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., "@mcp-digger Find all implementations of IRepository interface"
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.
Code context for AI coding agents. Progressive, on-demand access to your internal .NET / NuGet package source — agents browse, search, and read private C# libraries autonomously, with zero workspace pollution.
⚠ Scope: .NET / C# only. mcp-digger indexes NuGet-style repos containing
.csprojpackages and.cssource files. It is not a general-purpose source indexer — other languages (TypeScript, Python, Java, Go, etc.) are out of scope.
Public NuGet packages have documentation ecosystems — API references, tutorials, community Q&A. Tools like context7 serve that well.
Internal .NET packages often have source code as their primary documentation. mcp-digger turns that source into structured, searchable, token-efficient context that any MCP-compatible agent can consume — bridging the documentation gap in private C# library ecosystems.
Without it:
🐢 Slow context gathering — git clone + find + grep + cat chains burn tokens on infrastructure before useful context is retrieved.
🔍 No semantic search — file system tools find text, not API surfaces. "Every type implementing this interface" means writing extraction scripts on demand.
💸 Token waste — agents read whole files when a single method signature would do.
🖱 Permission click fatigue — dozens of shell-command approvals per session.
🧹 Workspace noise — referenced repos pollute file search, git status, and the agent's context window.
With it:
✅ Correct code on the first try — real signatures, generic constraints, interface contracts, base class patterns.
⚡ Self-service context — point the agent at your NuGet repos once; it browses, searches, and reads autonomously.
🪙 Progressive disclosure — 200-token overview before 5,000 tokens of source. Most questions resolve at L1 or L2.
🧼 Zero workspace pollution — managed clones live outside your project tree.
🌐 Any Git host — GitHub, GitLab, Azure DevOps, Bitbucket, self-hosted — HTTPS or SSH.
Related MCP server: Carto MCP Server
Ten purpose-built tools, escalating from broad to deep. The agent picks the cheapest tool that answers its question.
┌─→ 📦 dig_package_overview ─┐
│ (docs, key types) │
🩺 dig_status → 📋 dig_list → 📖 dig_repo_overview ┤ ├─→ 🔎 dig_lookup → 📄 dig_file
(health) (discover) (README + summaries) │ │ (symbol → file) (full source)
├─→ 📁 dig_package_files ────┤
│ (file listing) │
└────────────────────────────┴─→ 📝 dig_signatures
(stripped API)
Operational: 🔄 dig_refresh (force cache invalidation, on demand)
Bootstrap: 🌱 dig_init (only when no config exists)Tier | Tool | What it does |
Health | 🩺 | Config summary, connectivity check per repo, index health stats |
Discovery | 📋 | Lists configured repos + their packages with one-line |
L1 Overview | 📖 | Repo |
L1 Overview | 📦 | Package docs, key interfaces, abstract classes, file count |
L1 Overview | 📁 |
|
L2 Search | 🔎 | Indexed symbol search — |
L2 Search | 📝 | Stripped C# public API surface filtered by keyword (no method bodies) |
L3 Source | 📄 | Full source of a single file (capped at 1 MB) |
Operational | 🔄 | Force-rebuild caches for one or all repos |
Bootstrap | 🌱 | Creates starter |
Search modes for dig_lookup:
Mode | Finds |
| Type/method declarations matching a name substring |
| Classes/structs implementing an interface or extending a base class |
| Files referencing a given type name (word-boundary, case-sensitive) |
npm install -g mcp-digger
# or run directly
npx mcp-diggerRequires Node.js 20+, git on PATH, and a .NET / C# source repo (NuGet packages with .csproj + .cs sources).
Create .digger/config.json in your workspace root:
{
"repos": [
{
"name": "my-libraries",
"url": "https://github.com/org/shared-libs.git",
"packageFilter": "MyCompany.*",
"auth": {
"strategy": "pat",
"PAT-EnvVarName": "GIT_PAT"
}
}
]
}Don't have a config yet? Start the server, then call dig_init to scaffold one.
Add to .claude/settings.json or project settings:
{
"mcpServers": {
"digger": {
"command": "npx",
"args": ["-y", "mcp-digger"]
}
}
}Add to ~/.codex/config.toml (or .codex/config.toml for project-scoped):
[mcp_servers.mcp-digger]
command = "npx"
args = ["-y", "mcp-digger"]Add to claude_desktop_config.json:
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"digger": {
"command": "npx",
"args": ["-y", "mcp-digger"]
}
}
}Add to .vscode/mcp.json (workspace) or your user mcp.json:
{
"servers": {
"digger": {
"type": "stdio",
"command": "npx",
"args": ["-y", "mcp-digger"]
}
}
}Add to .cursor/mcp.json (project) or ~/.cursor/mcp.json (global):
{
"mcpServers": {
"digger": {
"command": "npx",
"args": ["-y", "mcp-digger"]
}
}
}Once connected, ask your agent to call dig_status — it reports config validation, per-repo connectivity, and index health.
A repos[] entry has three ways to declare packages:
Option | Behavior |
| Explicit list — these packages plus any local sibling project they pull in via |
| Wildcard — narrows to packages matching the prefix, found via |
(omit both) | Auto-discover all non-test |
sourceRoot defaults to "src" — set it to whichever directory holds your package folders. The walk is recursive, so nested layouts like src/Group/Foo/Foo.csproj are picked up.
By default, managed clones use the repo's default branch. Pin to a specific one:
{
"repos": [
{
"name": "my-libraries",
"url": "https://github.com/org/shared-libs.git",
"branch": "develop"
}
]
}The branch is used for both initial clone and subsequent fetches. Only applies to managed clones — for local repos, you control the checked-out branch yourself.
Skip managed cloning when the repo is already on disk. The local path is read-only — mcp-digger never fetches or modifies it.
{
"localRepos": {
"my-libraries": "C:/repos/shared-libs"
},
"repos": [
{
"name": "my-libraries",
"sourceRoot": "src"
}
]
}Strategy | Behavior |
| Try unauthenticated, fall back to PAT if set |
| Always use PAT (fatal if not set) |
| Never authenticate |
PATs can be inline ("PAT": "...") or via environment variable indirection ("PAT-EnvVarName": "MY_TOKEN"). The .env file in your workspace root is loaded automatically — values containing # should be quoted.
Variable | Default | Purpose |
|
| Override config file path |
|
| Override managed clone directory |
|
| Override cache directory |
Secrets (PAT values) belong in .env or the real environment — never as env vars in this table.
Symptom | First call | Then |
Connection / auth issues |
| Reports auth attempts, exact error, actionable hints |
"No matches" but you expect some |
| Force-rebuilds index, picks up new extraction logic |
Server starts but no tools visible |
| If unconfigured, only |
Need a config from scratch |
| Scaffolds |
Enable debug logging in your config:
{ "debug": true, "repos": [...] }Logs go to .digger/debug.log (capped at 5 MB, auto-truncated). Critical errors and crash output land in .digger/error.log.
Tried mcp-digger on your codebase? Share what worked, what broke, what's missing in GitHub Discussions. Bug reports go in Issues.
MIT License — see LICENSE.
Bootstrap mcp-digger by creating a starter config file. Only available when no config exists. After running, edit the generated template with your repository details, then restart the MCP server to activate all tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare idempotentHint=true and destructiveHint=false. Description adds that the tool is only available when no config exists, which clarifies the idempotency constraint—running it multiple times may cause errors. This goes beyond annotations by specifying availability condition and required restart.
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?
Two short sentences with no wasted words. The description is front-loaded with the main action and then provides usage constraints and follow-up steps. Every sentence adds value.
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 tool with no output schema and no parameters, the description covers the init process, availability condition, and required post-step. It does not mention error cases or output (e.g., what file is created), but given the simplicity, it is nearly complete.
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 tool has no parameters, and schema coverage is 100%. Baseline for 0 parameters is 4, and the description appropriately focuses on what the tool does without needing param details.
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?
Description clearly states the tool bootstraps mcp-digger by creating a starter config file. It specifies the action (create) and the resource (starter config file). The sibling tool 'dig_status' likely checks status, so this distinguishes initialization from status checking.
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?
Explicitly states 'Only available when no config exists', setting clear usage condition. Also provides post-run instructions (edit template, restart server). Could mention that dig_status is for checking status but not necessary for a one-time setup tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Health-check tool — validates mcp-digger configuration and tests git connectivity for all configured repositories. Call this to verify setup is correct, diagnose auth or network issues, or confirm repos are reachable before digging into source.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive. The description adds minor context about what is being tested (auth, network), but does not go beyond what annotations imply. No contradictions.
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?
Two sentences, front-loaded with the main purpose, and no unnecessary information. Every sentence adds value.
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 parameters and no output schema, the description covers all necessary context: purpose, usage scenarios, and limitations. Complete for a simple health-check tool.
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?
No parameters exist, so the description cannot add parameter semantics. The baseline for zero parameters is 4, and the description is sufficient.
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: a health-check that validates configuration and tests git connectivity. It distinguishes from the sibling 'dig_init' by focusing on verification and diagnosis before actual digging.
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?
Explicitly says to call for verifying setup, diagnosing auth/network issues, or confirming repos are reachable. Implicitly suggests use before other tools, but does not explicitly state when not to use or mention alternatives.
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.1.3dig_initdig_statusThe two tools have clearly distinct purposes: dig_init creates a starter config, while dig_status validates connectivity and configuration. There is no overlap.
Both tools consistently use the 'dig_' prefix and verb_noun pattern (init, status) in snake_case, making the naming predictable.
With only two tools, the server feels thin for a tool named 'digger' that presumably should provide git analysis capabilities. The description hints at more tools after configuration, but currently only init and status are defined.
The server lacks core digging functionality (e.g., analyzing commits, blame, changes). It only covers initialization and health-check, leaving a major gap in the expected tool surface.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Package intelligence for AI agents across npm, PyPI, crates.io and deps.dev. No API keys.
Package intelligence for AI agents across npm, PyPI, crates.io and deps.dev. No API keys.
Your team's shipping standards, org map and delivery metrics, inside your coding agent.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/janeksm/mcp-digger'
If you have feedback or need assistance with the MCP directory API, please join our Discord server