Skip to main content
Glama
shinerio

CodeGraph Multi-Repo MCP

by shinerio
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

CodeGraph Multi-Repo MCP

一个独立的 Python MCP 服务，用于把本地多个仓库的 CodeGraph 能力暴露给支持 MCP 的 AI 编程助手，例如 Codex、Claude Code 等。

它可以在两种模式下运行：

  • stdio：适合本机 Codex / Claude Code 直接拉起进程使用。

  • streamable-http：适合部署到服务端，通过 HTTP endpoint 共享给团队或多个客户端使用。

环境要求

  • Python 3.11+

  • uv，用于通过 uvx 启动

  • 本机或服务端可执行的 codegraph CLI，并且在 PATH 中

  • 要查询的仓库已经完成 CodeGraph 索引

检查 CodeGraph 是否可用：

codegraph --help

Related MCP server: codegraph

快速开始

先创建默认配置目录：

mkdir -p ~/.config/codegraph-multi-repo-mcp

仓库配置会影响 ask_multi_repo 和 trace_across_repos 的自动路由效果，尤其是 description、language、tags、aliases、components。这些字段不只是展示信息，建议让 AI agent 根据仓库内容生成和维护，而不是完全手写。

首次生成配置时，可以把下面这段提示词发给本机 AI 编程助手，例如 Codex 或 Claude Code。使用前把 {{REPOSITORY_SCAN_ROOTS}} 替换为实际扫描根目录的绝对路径列表，每行一个路径；每个扫描根目录下面可以包含多个仓库。

请帮我为 codegraph-multi-repo-mcp 生成仓库配置文件。

要求：
1. 把我提供的路径当作扫描根目录列表，支持多个根目录；不要假设每个根目录本身就是唯一仓库。
2. 对每个扫描根目录递归查找 `.codegraph` 目录；每个 `.codegraph` 的父目录就是一个要配置的仓库根目录。
3. 只配置带有 `.codegraph` 的仓库根目录；没有 `.codegraph` 的目录不要加入配置，也不要提醒我补配置或初始化，避免扫描和分析过多无关文件。
4. 递归扫描时跳过 node_modules、target、build、dist、.venv、venv、.idea、.gradle、.mvn、.git 等依赖、构建或工具目录。
5. 确认每个仓库根目录路径存在，并按真实路径去重。
6. 为每个仓库生成稳定、简短、唯一的 name。
7. 根据 README、包名、目录结构、主要源码、配置文件推断 description、language、tags、aliases、components；只分析已发现的 `.codegraph` 仓库根目录。
8. description 写清楚仓库的业务职责和主要能力，方便自然语言问题路由。
9. language 写主要编程语言，例如 java、python、typescript；不要把语言重复写进 tags。
10. tags 使用业务域、系统类型、关键模块等短词，不放编程语言。
11. aliases 使用团队可能会说出的简称、历史名称、服务名、模块名或产品名。
12. components 描述仓库内重要可发布组件、服务或模块，优先使用构建系统里的正式组件名。
13. 对 Java/Maven 仓库，请检查 pom.xml、父子模块、groupId、artifactId；components 中为关键模块写入 name、groupId、artifactId，方便后续按 artifactId 或完整 groupId:artifactId 路由到正确仓库。
14. 写入 ~/.config/codegraph-multi-repo-mcp/repos.yaml；如果文件已存在，请保留已有有效配置，只更新变化的仓库并追加新仓库。
15. 生成后帮我检查 YAML 格式、重复 name、路径是否存在，并总结已配置的仓库数量和名称。

扫描根目录列表：
{{REPOSITORY_SCAN_ROOTS}}

配置格式如下：

settings:
  codegraph_binary: codegraph
  default_max_repos: 5
  default_max_files: 8
  per_repo_timeout_seconds: 20
  max_concurrency: 4

repos:
  - name: eda
    path: /path/to/eda
    description: EDA application repository
    language: java
    tags: [eda, workflow]
    aliases: [eda-platform]
    components:
      - name: eda-platform
        groupId: com.example.eda
        artifactId: eda-platform

后续要更新已有仓库配置或添加新仓库，也建议继续让 AI agent 修改同一个文件。给它新增仓库路径，并要求它保留已有 name 稳定、只在职责变化时更新 description，把主要编程语言写进 language，把新出现的业务域和系统模块补进 tags，把常用叫法补进 aliases，把可发布组件补进 components。

本地 stdio 模式启动：

uvx --from git+https://github.com/shinerio/codegraph-multi-repo-mcp.git codegraph-multi-repo-mcp

可共享的 streamable HTTP 模式启动：

uvx --from git+https://github.com/shinerio/codegraph-multi-repo-mcp.git \
  codegraph-multi-repo-mcp \
  --transport streamable-http \
  --host 0.0.0.0 \
  --port 8000 \
  --path /mcp

默认 HTTP endpoint：

http://localhost:8000/mcp

也可以使用专门的 HTTP 启动命令：

uvx --from git+https://github.com/shinerio/codegraph-multi-repo-mcp.git codegraph-multi-repo-mcp-http

codegraph-multi-repo-mcp-http 默认监听 0.0.0.0:8000，并在 /mcp 路径提供 MCP 服务。

MCP 客户端配置

本机使用建议选择 stdio。部署到共享服务器时，建议选择 streamable HTTP。

Codex

本地 stdio 配置，写入 ~/.codex/config.toml：

[mcp_servers.codegraph-multi-repo]
command = "uvx"
args = ["--from", "git+https://github.com/shinerio/codegraph-multi-repo-mcp.git", "codegraph-multi-repo-mcp"]
startup_timeout_sec = 20
tool_timeout_sec = 120

如果你的仓库配置文件不在默认位置，可以显式传入：

[mcp_servers.codegraph-multi-repo.env]
CODEGRAPH_MULTI_REPO_CONFIG = "/absolute/path/to/repos.yaml"

远程 streamable HTTP 配置：

[mcp_servers.codegraph-multi-repo]
url = "https://your-server.example.com/mcp"
tool_timeout_sec = 120

Claude Code

本地 stdio 配置：

claude mcp add --transport stdio --scope user \
  codegraph-multi-repo \
  -- uvx --from git+https://github.com/shinerio/codegraph-multi-repo-mcp.git codegraph-multi-repo-mcp

如果你的仓库配置文件不在默认位置：

claude mcp add --transport stdio --scope user \
  --env CODEGRAPH_MULTI_REPO_CONFIG=/absolute/path/to/repos.yaml \
  codegraph-multi-repo \
  -- uvx --from git+https://github.com/shinerio/codegraph-multi-repo-mcp.git codegraph-multi-repo-mcp

远程 streamable HTTP 配置：

claude mcp add --transport http --scope user \
  codegraph-multi-repo \
  https://your-server.example.com/mcp

通用 MCP JSON

本地 stdio：

{
  "mcpServers": {
    "codegraph-multi-repo": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/shinerio/codegraph-multi-repo-mcp.git",
        "codegraph-multi-repo-mcp"
      ]
    }
  }
}

streamable HTTP：

{
  "mcpServers": {
    "codegraph-multi-repo": {
      "url": "https://your-server.example.com/mcp"
    }
  }
}

服务端部署

在服务端准备环境：

  1. 安装 Python 3.11+、uv 和 codegraph CLI。

  2. Clone 或挂载你希望暴露给 MCP 的代码仓库。

  3. 在这些仓库中建立 CodeGraph 索引。

  4. 创建 ~/.config/codegraph-multi-repo-mcp/repos.yaml，里面的仓库路径必须是服务端本地路径。

  5. 启动 streamable HTTP 服务：

uvx --from git+https://github.com/shinerio/codegraph-multi-repo-mcp.git \
  codegraph-multi-repo-mcp-http

如果要修改监听地址、端口或路径：

uvx --from git+https://github.com/shinerio/codegraph-multi-repo-mcp.git \
  codegraph-multi-repo-mcp \
  --transport streamable-http \
  --host 0.0.0.0 \
  --port 8000 \
  --path /mcp

以常驻进程运行

上面的命令在前台运行，关闭终端或退出 SSH 后进程会结束。要让 streamable HTTP 服务长期可用，请用进程管理工具把它托管成后台常驻进程。

下面三种方式任选其一。

方式一：nohup（最简单，临时使用）

nohup uvx --from git+https://github.com/shinerio/codegraph-multi-repo-mcp.git \
  codegraph-multi-repo-mcp-http \
  > ~/.config/codegraph-multi-repo-mcp/server.log 2>&1 &

日志写到 server.log，停止时用 pkill -f codegraph-multi-repo-mcp-http。这种方式不会随系统重启自动拉起，适合临时验证。

方式二：macOS launchd（开机自启，推荐 macOS 用户）

创建 ~/Library/LaunchAgents/com.codegraph.multi-repo-mcp.plist：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.codegraph.multi-repo-mcp</string>
  <key>ProgramArguments</key>
  <array>
    <string>/Users/你的用户名/.local/bin/uvx</string>
    <string>--from</string>
    <string>git+https://github.com/shinerio/codegraph-multi-repo-mcp.git</string>
    <string>codegraph-multi-repo-mcp-http</string>
  </array>
  <key>EnvironmentVariables</key>
  <dict>
    <key>PATH</key>
    <string>/Users/你的用户名/.local/bin:/usr/local/bin:/usr/bin:/bin</string>
  </dict>
  <key>RunAtLoad</key>
  <true/>
  <key>KeepAlive</key>
  <true/>
  <key>StandardOutPath</key>
  <string>/Users/你的用户名/.config/codegraph-multi-repo-mcp/server.log</string>
  <key>StandardErrorPath</key>
  <string>/Users/你的用户名/.config/codegraph-multi-repo-mcp/server.err</string>
</dict>
</plist>

把 你的用户名 换成实际用户名（uvx 路径用 which uvx 确认，codegraph 也要在 PATH 里）。加载并启动：

launchctl load ~/Library/LaunchAgents/com.codegraph.multi-repo-mcp.plist
launchctl list | grep codegraph

停止或卸载：

launchctl unload ~/Library/LaunchAgents/com.codegraph.multi-repo-mcp.plist

方式三：Linux systemd（开机自启，推荐服务器部署）

创建 ~/.config/systemd/user/codegraph-multi-repo-mcp.service：

[Unit]
Description=CodeGraph Multi-Repo MCP (streamable HTTP)
After=network.target

[Service]
ExecStart=%h/.local/bin/uvx --from git+https://github.com/shinerio/codegraph-multi-repo-mcp.git codegraph-multi-repo-mcp-http
Restart=always
RestartSec=3
Environment=PATH=%h/.local/bin:/usr/local/bin:/usr/bin:/bin

[Install]
WantedBy=default.target

启用并启动：

systemctl --user daemon-reload
systemctl --user enable --now codegraph-multi-repo-mcp.service
systemctl --user status codegraph-multi-repo-mcp.service

查看日志用 journalctl --user -u codegraph-multi-repo-mcp.service -f。要让用户级服务在未登录时也运行，执行 loginctl enable-linger $USER。

在客户端完成配置

服务常驻起来之后，把它的 HTTP endpoint 注册到客户端即可。以 Claude Code 为例：

claude mcp add --transport http --scope user \
  codegraph-multi-repo \
  http://localhost:8000/mcp

部署在远程服务器时，把 URL 换成实际地址，例如 https://your-server.example.com/mcp。注册后用 claude mcp list 验证，看到 ✔ Connected 即表示连接成功。其他客户端的配置写法见上文「MCP 客户端配置」。

面向团队或公网部署时，建议在前面加反向代理或网关，启用 TLS 和认证。这个服务会暴露 repos.yaml 中列出的仓库的 CodeGraph 查询结果；除非这些仓库本来就可以公开访问，否则不要裸奔到公网。

本地开发

python -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"

Windows PowerShell：

python -m venv .venv
.venv\Scripts\Activate.ps1
pip install -e ".[dev]"

运行测试：

python -m pytest

工具列表

  • list_repos：列出已配置仓库以及索引是否存在。

  • refresh_repos：刷新仓库元信息，可选返回 codegraph status 输出。

  • explore_repo：针对单个仓库运行 codegraph explore。

  • ask_multi_repo：根据问题自动路由到候选仓库，并发运行 CodeGraph 探索。

  • trace_across_repos：跨仓库搜索符号、API、topic、DTO、表名等标识符。

说明

这个 MCP 服务不会直接生成最终的自然语言回答。它返回结构化证据和原始 CodeGraph 输出，由调用它的 AI agent 继续推理和组织答案。

License

MIT

Available Tools

5 tools
ask_multi_repoC

Route a question to multiple repositories and run CodeGraph exploration.

ParametersJSON Schema
NameRequiredDescriptionDefault
reposNo
questionYes
max_reposNo
max_files_per_repoNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.3/5.0
Behavior2/5

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

No annotations provided, so description carries full burden. Only mentions 'CodeGraph exploration' without explaining behavior (e.g., mutation, auth, rate limits). Very little transparency.

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

Conciseness2/5

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

Single sentence; overly brief for a tool with 4 parameters and multiple repos. Lacks structure; important details omitted.

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

Completeness1/5

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

Despite having an output schema, description does not explain return values. With 4 parameters and no schema descriptions, the description is woefully incomplete for reliable invocation.

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

Parameters1/5

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

Schema description coverage is 0%. Description does not explain any parameter. While names like 'repos' and 'max_repos' hint at usage, no addition meaning provided beyond schema.

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

Purpose4/5

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

Description clearly states the tool routes a question to multiple repositories and runs CodeGraph exploration. It distinguishes from sibling tools like explore_repo (single repo) and trace_across_repos (trace vs exploration). However, 'CodeGraph exploration' is not defined, so purpose is clear but not fully specific.

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?

No guidance on when to use this tool vs alternatives. The agent must infer from tool names. No mention of exclusions or prerequisites.

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

explore_repoC

Explore one configured repository with codegraph explore.

ParametersJSON Schema
NameRequiredDescriptionDefault
repoYes
queryYes
max_filesNo
timeout_secondsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.1/5.0
Behavior1/5

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

No annotations provided, so the description carries full burden. It only says 'Explore one configured repository with codegraph explore', giving no information about side effects, safety, permissions, rate limits, or what happens during exploration. For a tool that likely performs actions (running a command), this is critically insufficient.

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

Conciseness4/5

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

The description is a single sentence, concise and front-loaded with the core purpose. However, it is under-specified, missing essential details. It earns a 4 for efficiency but could improve by adding more context without becoming verbose.

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

Completeness2/5

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

Given the tool has 4 parameters, an output schema, and 4 sibling tools, the description is far too brief. It does not explain what the tool returns, how parameters affect behavior, or how it relates to siblings. The presence of an output schema does not compensate for the lack of description about the overall operation.

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

Parameters1/5

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

Schema description coverage is 0%, so the description must add meaning to parameters. It does not. Parameters like repo, query, max_files, timeout_seconds are only listed by name and title, with no explanation of their purpose, format, or behavior. The description does not reference any parameters.

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

Purpose3/5

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

Description states the tool explores one configured repository, but 'explore' is vague and doesn't specify if it's searching, browsing, or analyzing. The reference to 'codegraph explore' adds some context but doesn't clarify the exact function. Compared to sibling tools like ask_multi_repo, the distinction is implied but not explicit.

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?

No explicit guidance on when to use this tool versus siblings. The description implies it's for a single repository (contrast with ask_multi_repo), but does not state when to use or not use it. No prerequisites or alternatives mentioned.

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

list_reposA

List repositories configured for multi-repo CodeGraph exploration.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.7/5.0
Behavior2/5

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

No annotations are present, so the description bears full responsibility for behavioral transparency. It only states the action without mentioning side effects, permissions, pagination, or return format. A simple read operation 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.

Conciseness5/5

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

The description is a single, concise sentence that fronts the key information. Every word is meaningful and there is no redundancy.

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

Completeness3/5

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

Given the tool's simplicity and the presence of an output schema, the description provides minimal context. It lacks information about scope (e.g., which repositories are listed) or prerequisites. It is adequate but not thorough.

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?

There are no parameters, so the input schema coverage is 100%. With zero parameters, the baseline is 4, and the description adds no further parameter semantics but also does not need to.

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 verb (List) and the resource (repositories configured for multi-repo CodeGraph exploration). It explicitly distinguishes the tool's purpose from sibling tools like explore_repo or ask_multi_repo, which involve different actions.

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 that the tool is used to list repositories, but it does not provide explicit guidance on when to use it versus alternatives. Sibling tool names suggest distinct purposes, but no contextual notes are given.

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

refresh_reposC

Refresh repository metadata and optionally include codegraph status output.

ParametersJSON Schema
NameRequiredDescriptionDefault
include_statusNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.9/5.0
Behavior2/5

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

Without annotations, the description carries full burden. It states the action ('refresh') but does not disclose side effects, permissions, rate limits, or whether it fetches from remote. Minimal 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.

Conciseness4/5

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

Single sentence, front-loaded with verb and resource. Concisely states the core function and optional behavior. Slightly informal but efficient.

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

Completeness3/5

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

Given a single parameter and an output schema (exists), the description is minimally adequate. It lacks details on what 'refresh' entails (e.g., local vs remote), but covers the optional parameter.

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?

With 0% schema coverage, the description adds value by explaining the optional parameter include_status ('optionally include codegraph status output'). However, it does not elaborate beyond the parameter's basic effect.

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

Purpose4/5

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

The description uses the specific verb 'Refresh' and resource 'repository metadata', clearly distinguishing it from sibling tools like list_repos or explore_repo. However, it could be more explicit about what 'metadata' includes.

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?

No guidance is provided on when to use this tool versus alternatives (e.g., list_repos for current state, explore_repo for details). The tool's purpose is implied but not contextualized.

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

trace_across_reposC

Trace an identifier such as a symbol, API route, topic, DTO, or table across repositories.

ParametersJSON Schema
NameRequiredDescriptionDefault
reposNo
max_reposNo
identifierYes
max_files_per_repoNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.6/5.0
Behavior2/5

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

With no annotations, the description carries full burden. It does not disclose behavior beyond the basic action, such as whether it searches all repos, permissions needed, or response format. The output schema exists but is unmentioned.

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

Conciseness4/5

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

The description is a single concise sentence that front-loads the purpose. It is efficient but could benefit from brief elaboration without verbosity.

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

Completeness2/5

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

Given the complexity (4 parameters, 1 required, no annotations), the description is incomplete. It does not explain parameter usage or provide enough context for effective invocation.

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

Parameters1/5

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

Schema description coverage is 0%, and the description adds no meaning for the parameters besides the identifier. The optional parameters repos, max_repos, and max_files_per_repo are not explained.

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

Purpose4/5

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

The description clearly states the tool traces an identifier across repositories, listing examples like symbol, API route, etc. It is specific but does not explicitly distinguish from sibling tools like ask_multi_repo.

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?

No guidance on when to use this tool versus siblings. There are no explicit when-not or alternatives, and the context is only implied from the name and description.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 5 tool updatesv0.1.0
    • First observedask_multi_repo
    • First observedexplore_repo
    • First observedlist_repos
    • First observedrefresh_repos
    • First observedtrace_across_repos
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: listing repos, exploring one repo, refreshing metadata, asking questions across repos, and tracing identifiers across repos. No overlapping functionality.

Naming Consistency5/5

All tool names follow the verb_noun pattern in snake_case (e.g., ask_multi_repo, explore_repo), maintaining perfect consistency across the set.

Tool Count5/5

With 5 tools, the server is well-scoped for multi-repo CodeGraph exploration. Each tool serves a necessary function without redundancy or overload.

Completeness4/5

The tools cover core operations: listing, exploring, querying, tracing, and refreshing. Minor gaps exist, such as lacking a tool to add/remove repositories or search within a single repo without full exploration, but these are not critical.

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

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/shinerio/codegraph-multi-repo-mcp'

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