Which integrations are available for this server?

Produces Graphviz DOT output that can be piped into Backstage for architecture visualization and integration with Backstage's software catalog. Provides a GitHub Action that enforces architecture rules on pull requests, posts diagrams and violations as comments, and fails the build on error-level violations. Generates Mermaid flowchart diagrams from repository analysis, enabling visual architecture documentation that can be embedded in markdown and rendered on platforms like GitHub.

How do I use repo-cartographer?

1. Click on "Install 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., "@repo-cartographer Generate a Mermaid diagram of the architecture in this repo" 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.

repo-cartographer

by builditwithgk

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

repo-cartographer

Understand any codebase in 60 seconds. An MCP server that turns any repository into an architecture diagram.

TypeScript License Version MCP Architecture

Point your LLM at a folder and get back an architecture map: languages, frameworks, entry points, modules, and an import graph — rendered as a Mermaid diagram you can drop into a PR, a doc, or an onboarding guide.

It is model-agnostic. It speaks the Model Context Protocol over stdio, so it works with Claude Code, Claude Desktop, Cursor, Cline, Copilot, or the OpenAI Agents SDK — no Claude-specific dependency.

Why it's different

The server extracts hard facts. The model does the reasoning.

repo-cartographer never tries to "understand" your code semantically. It parses deterministic facts — file tree, import edges, manifests, framework detection, entry points — and hands your LLM structured JSON plus a draft diagram. Your model turns those facts into the final narrative and a refined diagram.

That split keeps the server small, fast, testable, and portable — and it means the diagram is grounded in what's actually in the repo, not hallucinated.

Related MCP server: Code-Oracle

Example output

Running generate_diagram against this repo produces (a draft the model then refines):

flowchart TD
    n0["src · 2 files"]
    n1["src/lib · library code · 9 files"]
    n2["src/resources · resource handlers · 1 file"]
    n3["src/tools · tool implementations · 4 files"]
    n0 --> n1
    n0 --> n2
    n0 --> n3
    n1 --> n0
    n3 --> n0
    n3 --> n1

A self-contained, shareable HTML render is committed under examples/ (both a high-level and a file-level detail view).

Install & run

Requires Node.js 18+.

# Run directly (no install)
npx -y repo-cartographer

# …or from source
git clone https://github.com/builditwithgk/repo-cartographer
cd repo-cartographer
npm install
npm run build
node dist/index.js

The server communicates over stdio; AI clients launch it that way. You can also use it directly from a terminal — see below.

Command line (no AI needed)

The same binary is dual-mode: with no arguments it's the MCP server; with a subcommand it's a plain CLI for humans and CI.

# Draw a diagram — path in, architecture.html out
npx -y repo-cartographer map ./my-project
npx -y repo-cartographer map ./my-project --level detail -o docs/architecture
npx -y repo-cartographer map ./my-project --format dot   # Graphviz DOT instead of Mermaid

# Enforce architecture rules (exits 1 on an error-level violation — use it in CI)
npx -y repo-cartographer check ./my-project --config .cartographer.yml

Zip-friendly: if you point it at an extracted "Download ZIP" folder (repo-main/ wrapper and all), it detects the wrapper and maps the real repo root — noted in the output, never silent.

Two output notations, one strategy: Mermaid because that's where people read it (GitHub renders it natively in PR comments and READMEs), DOT because that's what their tools eat (pipe it into Graphviz, Backstage, or anything else: dot -Tsvg architecture.dot). Both come with the same shareable HTML page and role-colored modules. When the repo has a .cartographer.yml, its diagram: section supplies the defaults for --level, --format and -o; explicit flags always win.

check reads a rules file and flags forbidden cross-boundary imports and dependency cycles — deterministically, no LLM involved, so it's safe to gate a merge:

# .cartographer.yml
rules:
  forbidden:
    - from: "src/ui/**"
      to:   "src/db/**"
      reason: "UI must go through the service layer, not the DB directly."
  cycles: error        # error | warn | off

Adopting on an existing codebase? Record today's violations as an accepted baseline, so only new ones fail the build:

npx -y repo-cartographer check . --update-baseline   # writes .cartographer-baseline.json

Commit that file; later runs auto-detect it and pass unless a PR introduces a new violation.

Architecture governance in CI (GitHub Action)

A composite action (action.yml) runs check on every PR — failing the build on an error-level violation and posting a sticky comment with the diagram and any violations:

# .github/workflows/architecture.yml
on: pull_request
permissions: { contents: read, pull-requests: write }
jobs:
  architecture:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: builditwithgk/repo-cartographer@v1
        with: { path: ., config: .cartographer.yml }

This repo dogfoods it in .github/workflows/architecture.yml. Full design + phases: docs/github-action.md.

Use it with Claude Code

claude mcp add repo-cartographer -- npx -y repo-cartographer

Then ask: "Use repo-cartographer to map ./my-project and draw me an architecture diagram."

Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "repo-cartographer": {
      "command": "npx",
      "args": ["-y", "repo-cartographer"]
    }
  }
}

Use it with the OpenAI Agents SDK

Same server, a different model — the whole point of MCP:

import asyncio
from agents import Agent, Runner
from agents.mcp import MCPServerStdio

async def main():
    async with MCPServerStdio(
        params={"command": "npx", "args": ["-y", "repo-cartographer"]},
    ) as cartographer:
        agent = Agent(
            name="Cartographer",
            instructions=(
                "Use the repo tools to gather facts, then refine the draft "
                "Mermaid diagram into a clean architecture map."
            ),
            mcp_servers=[cartographer],
        )
        result = await Runner.run(agent, "Map ./my-project and explain its architecture.")
        print(result.final_output)

asyncio.run(main())

Tools & resources

Tool	What it returns
`map_repo(path, level?, format?, outPath?)`	The one-shot flow. Point it at a folder and get a downloadable architecture diagram (`architecture.html` + `.mermaid`/`.dot`) plus a facts summary and the draft source inline — in a single call.
`scan_repo(path)`	Languages, frameworks, entry points, top-level modules (with role guesses), and a manifest summary — as JSON facts.
`build_import_graph(path)`	Intra-repo import/require edges for JS/TS + Python. Nodes are files, auto-collapsed to module level for large repos.
`generate_diagram(path, level?, format?)`	A draft diagram. `level` = `"high"` (modules, default) or `"detail"` (files grouped by module); `format` = `"mermaid"` (default) or `"dot"` (Graphviz).
`render_diagram(source, outPath, format?)`	Writes a self-contained, styled `.html` (renders via CDN: Mermaid, or Viz for DOT) plus the raw `.mermaid`/`.dot` file.

Resource
`about://author`	Who built this and how to reach them (Markdown).

Most of the time you just want map_repo — "path in, diagram out." Reach for the four granular tools only when you want to compose the steps yourself (e.g. let the model refine the diagram source between generate_diagram and render_diagram).

How it stays fast on big repos

Languages: JavaScript/TypeScript and Python (v1).
Skips node_modules, .git, dist, build, venv, __pycache__, vendor, and other build/dependency/cache directories (plus all hidden dirs).
Caps the number of files scanned and bytes read per file; collapses the import graph to directory level past a threshold. Anything capped is reported in the output — never dropped silently.
No network calls at scan time. (The rendered HTML pulls Mermaid from a CDN only when you open it in a browser.)
Deterministic: output is sorted and stable, so diagrams don't churn between runs.

Development

npm run dev        # run from source with tsx
npm run build      # type-check + emit to dist/
npm test           # unit tests (node:test, no build step needed)
npm run typecheck  # type-check src/ and test/ together, no emit

Tests cover the deterministic core — import resolution (JS/TS + Python), module collapsing, cycle detection, rule globs, baseline diffing, Mermaid rendering and the check end-to-end path. They run against src/ via tsx, so there is no build step and no test framework dependency.

Author

Built by Gopi K Aitham (builditwithgk) — see about://author, or scaleup-solutions.in. Available for freelance and contract work on AI, agent, and MCP tooling.

License

MIT

Available Tools

5 tools

build_import_graphBuild import graphA

Extract intra-repo import/require relationships for JavaScript/TypeScript and Python. Nodes are files (auto-collapsed to module/directory level for large repos); edges are directed import relationships. Returns JSON.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Absolute or relative path to the repository root

TDQS

A3.8/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 full burden of behavioral disclosure. It reveals that nodes are auto-collapsed for large repos, edges are directed, and the result is JSON. These details go beyond a trivial statement and help the agent anticipate output structure. However, it does not mention whether the tool is read-only, performance implications, or side effects, but the nature of the task strongly implies a non-destructive analysis.

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 impressively concise, using two sentences to cover the core action, supported languages, node/edge behavior, auto-collapse rule, and return type. Every sentence adds value with no redundancy or fluff, and the main verb 'Extract' is front-loaded.

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 lack of an output schema, the description adequately explains the return value (JSON), node/edge representation, and the autoregressive collapsing behavior for large repos. It also specifies supported languages, which is a critical constraint. It could go further by describing an example output structure or handling of unsupported languages, but overall it is complete enough for a one-parameter tool.

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 input schema covers the single parameter (path) with a clear description of 'Absolute or relative path to the repository root' (100% coverage). The tool description does not add extra parameter semantics, so the baseline of 3 is appropriate since the schema already provides sufficient meaning.

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: extract intra-repo import/require relationships for JavaScript/TypeScript and Python. It specifies the resource (repo), the exact type of relationships (directed imports), and the output (JSON). It distinguishes itself from sibling tools like map_repo or generate_diagram by focusing on import graph extraction rather than generic mapping or visualization.

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?

The description provides no explicit guidance on when to use this tool versus alternatives like map_repo, scan_repo, or generate_diagram. It implies usage for import analysis but doesn't explain exclusions or mention that for diagram generation one should use generate_diagram. An agent is left to infer the use case, which is a clear gap.

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

generate_diagramGenerate diagramA

Combine scan + import facts into a DRAFT diagram string — Mermaid flowchart (default) or Graphviz DOT. level 'high' (default) shows modules/directories; 'detail' shows files grouped by module. This is a draft the calling model is expected to refine.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Absolute or relative path to the repository root
`level`	No	Diagram granularity (default 'high')
`format`	No	Diagram notation: 'mermaid' (default; renders on GitHub) or 'dot' (Graphviz interop)

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the transparency burden. It adds behavioral context beyond the schema by noting the output is a 'draft the calling model is expected to refine,' implying the result is not final and may need iteration. It also explains the level parameter's effect on granularity, which is not in the schema. It does not mention side effects, but generating a string implies a read-only operation.

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 three sentences, with the first sentence front-loading the core action and output. Every sentence adds value: purpose, level semantics, and the draft-refinement caveat. There is no redundancy or filler, making it concise and well-structured.

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 tool with no output schema and no annotations, the description covers the essential aspects: purpose, parameter semantics, output nature (draft diagram string), and context (combines scan/import facts). It could explicitly note prerequisites (e.g., that scan_repo and build_import_graph should be run first), but the phrasing 'combine scan + import facts' implies this dependency. Overall, it is sufficiently complete for an agent to understand invocation and result.

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

Parameters4/5

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

The input schema has 100% parameter coverage, providing descriptions for path, level, and format. The description adds value beyond the schema by elaborating on the level values: 'high' shows modules/directories and 'detail' shows files grouped by module. It also confirms the default formats inline, though these are already in the schema. The level semantics are the key addition.

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 opens with a specific verb phrase 'Combine scan + import facts into a DRAFT diagram string,' clearly defining the tool's purpose and output. It distinguishes itself from siblings like render_diagram by explicitly labeling the output as a draft for refinement, and names the supported formats (Mermaid/DOT), making the tool's role unambiguous.

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

Usage Guidelines4/5

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

The description provides clear context for when to use the tool: after scan and import facts are available, to produce a draft diagram. It does not explicitly name alternatives or exclusions (e.g., 'use render_diagram for final output'), but the 'draft' framing and sibling names imply the appropriate workflow. This is clear context but lacks explicit when-not-to-use guidance.

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

map_repoMap repository (one-shot)A

Point at a folder and get a downloadable architecture diagram in one call: runs scan + import-graph + render internally and returns the HTML path, a facts summary, and the draft diagram source inline. By default writes architecture.html plus the raw source (.mermaid or .dot) into the repo; pass outPath to write elsewhere. Use the granular tools (scan_repo, build_import_graph, generate_diagram, render_diagram) only when you need to compose the steps yourself.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Absolute or relative path to the repository root
`level`	No	Diagram granularity (default 'high')
`format`	No	Diagram notation: 'mermaid' (default; renders on GitHub) or 'dot' (Graphviz interop)
`outPath`	No	Output base path (default: <repo>/architecture); .html and the raw source are written

TDQS

A4.7/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 full burden and does well: it discloses internal orchestration ('runs scan + import-graph + render internally'), side effects (writes architecture.html and raw source into the repo), configurable output location (outPath), and the return payload (HTML path, facts summary, draft diagram source). It lacks potential permission or idempotency details but gives substantial behavioral context.

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?

Two sentences with no fluff: the first states the primary action and return values, the second covers defaults and alternative tool usage. All information is front-loaded and purposeful.

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

Completeness5/5

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

For a medium-complexity orchestration tool with no output schema or annotations, the description covers what it does, what it returns, filesystem side effects, and how it relates to sibling tools. The description is complete enough for an agent to invoke it correctly and understand high-level consequences.

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

Parameters4/5

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

The input schema already has 100% coverage, so baseline is 3. The description adds value by explaining the default output ('architecture.html plus the raw source (.mermaid or .dot) into the repo') and clarifying the outPath behavior ('write elsewhere'). It also reinforces the format and level concepts, going beyond the schema's basic descriptors.

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 uses a specific verb 'Point at a folder and get a downloadable architecture diagram in one call' and clearly names the resource and outcome. It also explicitly distinguishes the tool from its granular siblings by positioning it as a one-shot orchestrator.

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

Usage Guidelines5/5

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

Exactly states when to use the tool ('Point at a folder and get...') and when not to ('Use the granular tools... only when you need to compose the steps yourself'). It names all alternative sibling tools, providing clear direction for tool selection.

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

render_diagramRender diagramA

Write a self-contained, shareable HTML page (renders via CDN: Mermaid, or Viz for Graphviz DOT) plus the raw source file (.mermaid or .dot). Returns the absolute paths written.

ParametersJSON Schema

Name	Required	Description
`format`	No	Notation of `source` (default 'mermaid')
`source`	Yes	Diagram source to render (Mermaid, or DOT when format is 'dot')
`outPath`	Yes	Output path (with or without extension); .html and the raw source siblings are written

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that the HTML uses CDN (Mermaid or Viz), that it writes a raw source sibling, and that it returns absolute paths. This covers file-writing side effects and dependency on internet/CDN, which is valuable. It stops short of mentioning error handling or directory creation, but the key behavioral traits are disclosed.

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, compact sentence with important information front-loaded ('Write a self-contained, shareable HTML page'). It avoids redundancy with the schema and earns its place by clarifying output artifacts and return value.

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 tool with 3 parameters, no annotations, and no output schema, the description covers the core purpose, output files, and return format. It does not explicitly differentiate from sibling tools or describe error behavior, but for its complexity it is sufficiently complete to guide an agent.

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%, so baseline of 3 applies. The description adds no extra parameter details beyond the schema; it repeats the raw source and path output. However, it reinforces the relationship between format and source, but does not compensate beyond what schema already provides.

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

Purpose5/5

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

The description clearly states the tool writes a self-contained HTML page and a raw source file. It uses the specific verb 'Write' and identifies the resources (HTML, .mermaid/.dot), which distinguishes it from sibling tools like generate_diagram that likely create diagram source rather than rendering it to shareable HTML.

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: when you have Mermaid/DOT source and want a shareable HTML page. However, it does not explicitly state when to use this tool versus alternatives like generate_diagram, nor does it provide exclusions or prerequisites. The context is present but not overtly comparative.

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

scan_repoScan repositoryA

Deterministically extract facts from a local repo: programming languages, frameworks/libraries, entry points, top-level modules (with role guesses), and a manifest summary. Returns JSON facts only — no interpretation.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Absolute or relative path to the repository root

TDQS

A3.8/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 full burden. It discloses determinism, output format (JSON facts only), and the scope of extraction, but does not explicitly mention side effects or read-only nature. This provides moderate transparency.

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?

Two sentences, front-loaded with the action and output, no redundant phrases. Every sentence 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 single-parameter schema and lack of output schema, the description provides a reasonable overview of what will be returned, listing the categories of facts. It is sufficient for an agent to anticipate the tool's behavior, though exact JSON structure isn't specified.

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 description does not add information about the 'path' parameter beyond the schema's description. With 100% schema coverage, the baseline applies; the description neither clarifies nor contradicts 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's function with specific verbs ('extract facts') and lists the exact resource types covered. It distinguishes from siblings by emphasizing determinism and 'no interpretation', which differentiates it from map_repo or diagram 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 when a factual inventory of a repository is needed, but does not explicitly state when to avoid this tool or name alternative tools. The 'no interpretation' clause gives a subtle hint but no explicit exclusions.

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.

5 tool updatesv1.0.0Jul 31, 2026
- First observedbuild_import_graph
- First observedgenerate_diagram
- First observedmap_repo
- First observedrender_diagram
- First observedscan_repo

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Scored 2026-07-31 20:55 across 5 tools

Disambiguation5/5

Each tool has a distinct role: scan_repo extracts facts, build_import_graph extracts import relationships, generate_diagram produces a draft string, render_diagram writes HTML files, and map_repo is a clearly labeled convenience wrapper that explicitly says when to use the granular tools. No two tools have overlapping purposes.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case: scan, build, generate, render, and map as verbs; repo, import_graph, and diagram as nouns. The naming scheme is uniform and predictable.

Tool Count5/5

Five tools perfectly cover the repository mapping workflow. The high-level convenience tool plus four granular tools avoid bloat while providing flexibility. This is well within the ideal 3-15 range.

Completeness5/5

The tool set covers the full pipeline from repository scanning to dependency graph extraction to diagram generation and rendering. The convenience tool ties everything together, and there are no missing critical operations for the stated purpose.

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
Agentic Mermaid A
io.github.adewale
Render, verify, describe, and safely edit Mermaid diagrams through MCP.
Data Visualization Software Architecture
9210
mcpcheck B
io.github.joeyough
Scan any MCP server for tool-poisoning, security, auth & license. Trust score before install.
Penetration Testing Security
21

Related MCP Servers

vaults-diagram-tools
Data Visualization Software Architecture
Malnati
A
license
Not graded
quality
C
maintenance
MCP server for rendering Mermaid diagrams and generating source-code diagrams, with tools to render text/files and produce dependency/class diagrams.
Updated a month ago (2026-07-27 00:18 UTC)
96
MIT
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)
-
RepoMind-MCP
Code Analysis Developer Tools Software Architecture
doridoor
F
license
A
quality
B
maintenance
MCP server for repository mapping, dependency analysis, and architecture diagram generation for JavaScript, TypeScript, and Python projects.
Updated a month ago (2026-08-08 12:54 UTC)
4
19
-
Knossos MCP
Software Architecture Code Analysis
AraneaDev
A
license
Not graded
quality
A
maintenance
Local-first MCP server that scans a repository once and answers architecture questions from an evidence-backed graph, enabling dependency analysis, impact analysis, and codebase exploration without re-reading the source tree.
Updated 2 hours ago (2026-09-10 13:58 UTC)
3
MIT