How do I use codecity-mcp?

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., "@codecity-mcp Show me the structure and complexity hotspots of ~/code/my-project" 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.

codecity-mcp

by bsana1

Overview Schema Related Servers Score Discussions

TypeScript

Local

codecity-mcp

An MCP server that analyzes a local codebase and exposes its structure, per-file summaries, dependency graph, and complexity hotspots as tools Claude (or any MCP client) can call.

This is the data layer for a larger project: a 3D "code city" - a navigable visualization where a codebase becomes a walkable city (files as buildings, folders as districts, imports as roads) with Claude acting as a guide that explains what you're looking at and helps you actually build a mental model of the codebase, not just stare at a pretty render of it. This repo is the first, standalone piece: it's useful on its own, with or without the 3D viewer, to anyone pointing Claude at an unfamiliar codebase.

Tools

Tool	What it does
`get_repo_structure`	Returns the folder/file tree of a repo, plus totals (file count, size). Start here to get oriented.
`get_file_summary`	Structural summary of one file: line count, function/class count, its imports, and a short excerpt.
`get_dependency_graph`	Resolves relative imports between files into a graph (internal edges) plus a list of external package names.
`get_complexity_hotspots`	Ranks files by a simple size/complexity heuristic, so you know where to look first.

Related MCP server: forensic-deepdive

Design notes

Zero analysis dependencies. Repo scanning, .gitignore handling, and JS/TS structural analysis (function/class/import counts) are hand-rolled with no parser or ignore-matching library. This is a deliberate tradeoff: regex/heuristic-based analysis instead of a full AST walk, in exchange for a small, auditable dependency footprint (just the MCP SDK and zod). The complexity score is explicitly a heuristic, not real cyclomatic complexity - documented in src/complexity.ts.
JS/TS-aware today, extensible later. Non-JS/TS files still get scanned and line-counted; structural analysis (functions, classes, imports) currently only applies to .ts/.tsx/.js/.jsx/.mjs/.cjs. Adding another language means adding another analyzer, not touching the MCP layer.
Tested without the SDK installed. test/smoke.ts exercises the scanner/analyzer/graph/complexity logic directly (no MCP SDK or zod import), so the core logic is verified independently of the protocol layer. It runs the tool on its own source as a sanity check.

Setup

npm install
npm run build

Running it

Standalone smoke test (no MCP client needed)

npm test

Runs the analysis logic (scanner, analyzer, dependency graph, complexity ranking) directly, with no MCP SDK involved - points it at this repo's own source and prints what it finds. Useful to sanity-check the core logic in isolation before wiring up a client.

With the MCP Inspector

npm run inspect

Opens a browser UI to call each tool manually and see raw responses.

With Claude Desktop or Claude Code

Add to your MCP client config (e.g. claude_desktop_config.json):

{
  "mcpServers": {
    "codecity": {
      "command": "node",
      "args": ["/absolute/path/to/codecity-mcp/build/index.js"]
    }
  }
}

Restart the client, then ask it something like: "Use codecity to show me the structure of ~/code/some-project, and tell me which files are the most complex."

Roadmap

Orchestrator layer: a small agent loop that decides what to explain next based on what's already been explored, and quizzes the user to check understanding (not just recall) - the piece that turns this from a static analysis tool into a capability-building guide.
3D city renderer (BabylonJS + React) that consumes get_repo_structure and get_dependency_graph to render the actual city.
Language support beyond JS/TS.

License

MIT

Available Tools

4 tools

get_complexity_hotspotsA

Ranks files by a simple size/complexity heuristic (function count, class count, lines of code) so you know which parts of a codebase are worth looking at first.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max entries to return (default 10)
`repoPath`	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?

With no annotations, the description carries the burden of behavioral disclosure. It honestly describes the heuristic and purpose but does not mention if the operation is read-only, how files are traversed, or any potential error modes. It also omits return format, though that is partially covered by the purpose.

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, front-loaded sentence that states the purpose and heuristic without extraneous words. Every part contributes to understanding.

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

Completeness4/5

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

For a simple tool with no output schema, the description conveys the core behavior (ranking files) and the criteria used. It could be more explicit about the return format (e.g., a list of file paths with scores), but the given information is largely sufficient for a basic understanding.

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

Parameters3/5

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

Schema coverage is 100%: both repoPath and limit have descriptive schemas. The description adds no parameter-specific meaning beyond the heuristic context, so the baseline of 3 applies without extra credit.

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 ranks files using a size/complexity heuristic (function count, class count, lines of code). This specific verb-resource pairing distinguishes it from siblings like get_repo_structure and get_dependency_graph.

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 phrase 'so you know which parts of a codebase are worth looking at first' implies use for prioritizing code review, but it does not explicitly state when to use this tool versus alternatives or mention exclusions. Sibling tools are not referenced.

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

get_dependency_graphA

Builds a dependency graph of the repository by resolving relative imports between files. Returns edges (from -> to) for internal files and a separate list of external package names.

ParametersJSON Schema

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

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description fully discloses key behavior: it resolves relative imports only (ignoring other import types), and it returns internal edges and external package names separately. This gives the agent a good mental model, though it omits potential limitations like error handling or performance.

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

Conciseness5/5

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

The description is two concise sentences that front-load the action and resource, include necessary output details, and contain no superfluous words.

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 one-parameter, no-output-schema tool, the description explains the behavior, input (via schema), and output structure. It sufficiently covers internal vs external dependency classification but does not address edge cases like invalid paths or unresolved imports.

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

Parameters3/5

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

The schema already provides a clear description for the only parameter, repoPath, covering 100% of parameters. The tool description adds no extra parameter semantics, so the baseline of 3 is appropriate.

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

Purpose5/5

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

The description clearly states that the tool builds a dependency graph by resolving relative imports, which is a specific and unambiguous action. It distinguishes itself from sibling tools like get_repo_structure and get_file_summary by focusing on import relationships and return structure.

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 usage context is implied from the description (use when you need dependency insights), but there is no explicit when-to-use or when-not-to-use guidance, nor any mention of alternative tools. This leaves the agent to infer the appropriate context.

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

get_file_summaryA

Returns a structural summary of a single file: line count, function/class count, its imports, and a short excerpt - without needing to read the whole file.

ParametersJSON Schema

Name	Required	Description	Default
`filePath`	Yes	Path to the file, relative to repoPath
`repoPath`	Yes	Absolute or relative path to the repository root

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the burden of behavior. It discloses what the tool returns and assures efficiency by not reading the whole file. It doesn't mention potential side effects or limitations (e.g., file size limits), but for a read-only summary tool, this is reasonably transparent.

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

Conciseness5/5

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

The description is a single, well-structured sentence that front-loads the action and result. Every word adds value, and it avoids redundant phrasing.

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

Completeness4/5

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

For a simple tool with two well-described parameters and no output schema, the description covers the key return elements and the practical benefit. It could mention edge cases or how the excerpt is selected, but the provided details are sufficient for an agent to understand and invoke the 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 fully describes both parameters with 100% coverage, including the distinction between repoPath and filePath. The description adds no additional parameter detail beyond what the schema provides, so the baseline of 3 is appropriate.

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

Purpose5/5

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

The description clearly states the tool returns a structural summary of a single file, enumerating specific contents (line count, function/class count, imports, excerpt). This distinguishes it from sibling tools like get_repo_structure (whole repository) and get_dependency_graph (relationships).

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 phrase 'without needing to read the whole file' gives a clear usage context: use this for a quick overview rather than fetching entire file contents. However, it doesn't explicitly state when not to use it or mention alternatives, though the sibling tool names provide implicit contrast.

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

get_repo_structureA

Returns the folder/file tree of a local repository, plus totals (file count, lines of code). Use this first to get oriented before drilling into individual files.

ParametersJSON Schema

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

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations provided, the description carries the behavioral disclosure burden. It states the output (tree plus totals) but does not mention side effects, read-only nature, recursive behavior, or performance implications. Adequate for a simple read operation, but leaves some ambiguity.

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 primary function and followed by a usage recommendation. Every word earns its place; no fluff or redundancy.

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 low-complexity tool with a single parameter and no output schema, the description fully covers what the tool does and when to use it. The mention of 'plus totals' clarifies the return content, making it complete for an orientation utility.

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

Parameters3/5

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

Schema coverage is 100% for the single parameter repoPath, and the description adds no additional nuance beyond what the schema already provides. Baseline of 3 applies because the schema fully documents the parameter.

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 returns a folder/file tree plus aggregate totals (file count, lines of code). It distinguishes itself from sibling tools by positioning it as an orientation tool before deeper analysis.

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?

Explicitly advises to 'Use this first to get oriented before drilling into individual files,' giving a clear usage context. Does not name sibling alternatives explicitly, but the guidance implies when it is appropriate relative to deeper analysis tools.

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. Dates show when Glama detected each change.

4 tool updatesv0.1.0Aug 9, 2026
- First observedget_complexity_hotspots
- First observedget_dependency_graph
- First observedget_file_summary
- First observedget_repo_structure

Install Server

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

TDQS

A4.2/5.0

Disambiguation5/5

Each tool addresses a distinct aspect of codebase analysis: structure, file summaries, dependency graph, and complexity hotspots. There is no overlap in their purposes, making selection unambiguous.

Naming Consistency5/5

All tool names follow a consistent get_<noun> pattern, with clear resource names (repo_structure, file_summary, dependency_graph, complexity_hotspots). The naming is uniform and predictable.

Tool Count5/5

With 4 tools, the set is well-scoped for a code analysis server. Each tool covers a core need and none are redundant, making the count appropriate.

Completeness4/5

The server covers the main exploration workflows: orienting via structure, inspecting files via summaries, understanding dependencies, and identifying complex areas. Missing full file content retrieval is a minor gap since summaries include excerpts.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

gentlyOAuth
is.gently
Ask a codebase what calls what: search, blast radius, paths between symbols, and diffs.
Code Analysis Developer Tools
1
searchcode A
com.searchcode
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Search Code Analysis Version Control
62
Cortex C
io.cortex.mcp
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
Developer Tools Monitoring Observability
312
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

code-index
Developer Tools Code Analysis
achreftlili
A
license
Not graded
quality
D
maintenance
A local, SQLite-backed code index for Claude Code, exposed over MCP, enabling targeted code retrieval without external APIs.
Updated 4 months ago (2026-05-14 20:11 UTC)
1
MIT
forensic-deepdive
Code Analysis Developer Tools
Dhevenddra
A
license
Not graded
quality
B
maintenance
Analyzes codebases to produce a persistent code knowledge graph and an MCP server with 9 tools for AI coding agents.
Updated 21 days ago (2026-08-16 14:13 UTC)
2
Apache 2.0
throughline
Code Analysis Developer Tools Search
devznsh
A
license
Not graded
quality
B
maintenance
An MCP server that indexes local code repositories, extracting symbols and call graphs to give Claude precise, structural answers with real file paths and line numbers. Runs entirely locally with no network requests, for privacy-focused code understanding.
Updated a month ago (2026-08-02 19:07 UTC)
646
MIT
spider-map
Code Analysis Software Architecture Developer Tools
rofid-c
F
license
Not graded
quality
B
maintenance
MCP server that analyzes codebases to provide dependency graphs, impact analysis, and file insights across 15+ programming languages, enabling AI assistants to understand project structure and navigate code efficiently.
Updated 5 days ago (2026-09-01 05:08 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bsana1/codecity-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server