F
licenseNot graded
qualityF
maintenanceProvides a local code knowledge graph for Java projects, enabling querying of classes, methods, fields, calls, inheritance, and imports via MCP tools like query, context, impact, and cypher.
1
-
rosgraph-mcp
by kimurariku
Provides tools for exploring ROS2 workspace graph knowledge, including package dependencies, message/service/action definitions, and topic pub/sub relationships, all through static file analysis without requiring a running ROS2 environment.
Click on "Deploy 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., "@rosgraph-mcpWhat are the dependencies of the planning package?"
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.
rosgraph-mcp
ROS2ワークスペースの「グラフ的知識」（パッケージ依存、メッセージ/サービス/アクション定義とその使用箇所、トピックのpub/sub関係）を、素のLSPやSerenaのようなシンボル検索ツールでは扱えない粒度で提供するMCPサーバー + ローカルWebダッシュボード。
なぜ作ったか
Claude Codeにはclangd-lspプラグインのようなネイティブの宣言的LSP統合があり、シンボル定義/参照検索は既にそちらでカバーされている（~/.claude/plugins/参照）。このツールはそれを再実装せず、LSPが理解できないROS2固有のクロスファイル・クロスパッケージ概念（package.xmlの依存グラフ、.msg/.srv/.actionの定義とその使用箇所、トピックのpub/sub接続）だけに集中する。
外部ネットワーク通信はゼロ。すべて静的ファイル解析で完結し、ros2/colcon CLIやビルド・source済みの環境にも依存しない。
Related MCP server: ROS 2 Workspace Inspector MCP
セットアップ
uv sync使い方
# ワークスペースをスキャンしてキャッシュを構築
uv run rosgraph-mcp scan --workspace /path/to/ros2_ws
# MCPサーバーとして起動 (stdio)
uv run rosgraph-mcp serve
# ダッシュボードを起動 (http://127.0.0.1:8765)
uv run rosgraph-mcp dashboard --workspace /path/to/ros2_wsClaude Codeへの登録
このリポジトリのディレクトリ内で実行する:
claude mcp add --scope user rosgraph -- uv run --project "$(pwd)" rosgraph-mcp serve特定のワークスペースを既定にしたい場合は、--env ROSGRAPH_MCP_WORKSPACE=/path/to/ros2_wsを追加するか、各ツール呼び出し時にworkspace_rootを指定する。
提供するMCPツール（Phase 1時点）
ツール | 説明 |
| ワークスペース内のパッケージ一覧（グループ/サブグループ/名前でフィルタ可） |
| このワークスペースに実際に存在するグループ/サブグループの一覧 |
| 指定パッケージの依存関係（ |
| キャッシュを明示的に再構築 |
今後のフェーズで.msg/.srv定義検索、pub/subグラフツールを追加予定（詳細は設計書参照）。
グループ/サブグループの分類（どのROS2ワークスペースでも動く汎用ツール）
デフォルトでは特定プロジェクトの知識を一切前提にしない、汎用的な分類ルールのみを使う:
グループ =
src/<group>/...の最初のパスセグメントそのままサブグループ = その直下のディレクトリ名
これだけで大抵のROS2ワークスペースはそれなりに意味のある分類になるが、より細かい分類をしたいプロジェクトは、ワークスペースのルートに.rosgraph-mcp.tomlを置くことでカスタマイズできる（このリポジトリ自体にはプロジェクト固有の知識を一切持たせない）。
# <workspace_root>/.rosgraph-mcp.toml
[groups.core]
# src/launch/, src/launch_ros/, src/rclcpp/ を "core" という1つのグループにまとめる
aliases = ["launch", "launch_ros", "rclcpp"]
[groups.autoware]
# src/autoware/universe/planning/... のように、universe/core の直下にさらに
# カテゴリディレクトリがある場合、サブグループを "universe-planning" のように
# 1階層深く分類する
tier_dirs = ["universe", "core"]設定ファイルが無ければ完全に汎用的な既定ルールのみが使われる。list_groupsで実際にどう分類されたかをいつでも確認できる。
既知の制約
pub/sub検出（Phase 3以降）は正規表現ベースのヒューリスティックであり、完全なAST解析ではない。変数経由のトピック名、launchファイルでのリマップは検出できない場合がある。
.msg/.srv/.actionのネスト型解決は、呼び出し側がfind_message_definitionを再帰的に呼ぶ設計であり、パーサ自体は解決しない。
Available Tools
4 toolsget_package_dependenciesA
Get a package's dependencies (from package.xml) and, conversely, which
packages depend on it. depend_types filters to a subset of
depend/build_depend/exec_depend/test_depend/buildtool_depend (default: all).
transitive=True walks the full dependency closure instead of one hop.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| transitive | No | ||
| depend_types | No | ||
| package_name | Yes | ||
| workspace_root | No |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that dependencies come from package.xml, supports filtering by dependency types, and can traverse the full closure transitively. It doesn't mention return format or potential side effects, but the read-only nature is implied by 'get'.
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 sentences, with the main purpose front-loaded and parameter details following. Every sentence adds value with no filler.
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?
While the core functionality is covered, the tool has four parameters and no output schema. The description omits workspace_root, and the return format is not addressed. This leaves the agent with some uncertainty about how to invoke the tool fully and interpret results.
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 0%, so the description must compensate. It explains depend_types and transitive in detail, and package_name is obvious. However, workspace_root is not mentioned at all, leaving a parameter unexplained. This is a notable gap for a 3-param tool.
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 retrieves package dependencies and reverse dependents, using a specific verb and resource. It distinguishes from sibling tools like list_packages, which likely only lists packages without dependency 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 description provides clear context on what the tool does and how to control its behavior via depend_types and transitive. It doesn't explicitly mention when not to use it or alternative tools, but the context is sufficient for an agent to decide when this tool is relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_groupsA
List every group and, within each, the subgroups actually present in
this workspace. By default these are derived generically from the src/
directory layout (group = first path segment, subgroup = the next one);
a workspace can opt into richer classification via an optional
.rosgraph-mcp.toml at its root (see the README). Call this before using
subgroup filters on list_packages/the dashboard to see valid values.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_root | No |
TDQS
A4.1/5.0
Behavior4/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 the derivation logic (from src/ directory layout, configurable via .rosgraph-mcp.toml) and notes the config option. Missing details like return format or side effects, but for a read-only list operation this is acceptable.
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?
Three sentences, each earning its place: first states purpose, second explains derivation/default behavior, third provides usage guidance. No redundancy or filler.
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 no output schema and no annotations, the description covers the important aspects: what groups are, how they are derived, optional configuration, and when to use it. It does not describe return format, but for a list tool the purpose is clear enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description never explicitly explains the workspace_root parameter. It mentions 'this workspace' but does not connect it to the parameter, leaving the agent to infer that workspace_root specifies the workspace. The description adds little beyond the schema's property name and type.
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 ('List') and clearly names the resource ('groups and subgroups') and scope ('in this workspace'). It distinguishes itself from sibling tools like list_packages by focusing on group/subgroup structure.
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?
It gives explicit usage timing: 'Call this before using subgroup filters on list_packages/dashboard'. However, it does not mention when not to use it or explicitly compare against alternatives, so it lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_packagesA
List ROS2 packages in the workspace, optionally filtered by group (the
top-level src// directory a package lives under — this varies by
workspace, e.g. "vendor"/"description" for one repo, something else
entirely for another), a finer-grained subgroup within it, or a
case-insensitive substring of the package name. Call list_groups first
to see the actual group/subgroup values present in this workspace.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | ||
| subgroup | No | ||
| name_filter | No | ||
| workspace_root | No |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It adds meaningful behavioral context: group values vary by workspace, name_filter is case-insensitive, and list_groups should be called first. It doesn't explicitly state the output format or read-only nature, but 'List' implies read-only and the filtering semantics are well covered.
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?
Two sentences with a clear front-loaded purpose. The parenthetical example is informative but slightly wordy; overall it is concise and well-structured.
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 absence of output schema and annotations, the description needs to cover return values and all parameters. It provides strong filter guidance and a prerequisite, but omits workspace_root semantics and the shape of returned data, leaving notable gaps.
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 0%, so the description must compensate. It explains group, subgroup, and name_filter clearly, but does not mention workspace_root at all, leaving one of four parameters undefined.
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 'List ROS2 packages in the workspace' with a specific verb and resource. It distinguishes from siblings by focusing on packages rather than groups (list_groups) or dependencies (get_package_dependencies).
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 instructs to 'Call list_groups first to see the actual group/subgroup values', providing a clear prerequisite and context for using filters. It does not explicitly state when not to use this tool or name alternatives, but the directional guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rescan_workspaceA
Rebuild the package index cache for a workspace by re-scanning all
package.xml files under it. Call this after pulling new source or after
vcs import changes the set of packages — the index is not auto-refreshed
on every tool call for performance reasons.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_root | No |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the core behavior (re-scanning package.xml files, rebuilding the cache) and the performance rationale. It implies overwriting via 'rebuild' but does not detail failure modes or permissions. Still, the main side effect is clearly stated.
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 waste: first states action and scope, second gives the usage trigger and rationale. Information is front-loaded and every sentence earns its place.
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?
The description covers the purpose and trigger, but omits details about the optional `workspace_root` parameter and any return value or success/failure indication (no output schema exists). For a simple action, this is a noticeable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, `workspace_root`, has no description in the schema and is not mentioned in the tool description at all. With 0% schema coverage, the description should compensate but does not; the agent must infer meaning from the parameter name alone.
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 ('Rebuild') and resource ('package index cache'), and explicitly scopes to 'all package.xml files' under a workspace. This clearly distinguishes it from the sibling listing/query tools (list_packages, etc.).
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?
The description gives explicit when-to-use guidance: 'Call this after pulling new source or after `vcs import` changes the set of packages'. It also explains why (index is not auto-refreshed for performance), implying when it is not needed.
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.
4 tool updates
v0.1.0- First observed
get_package_dependencies - First observed
list_groups - First observed
list_packages - First observed
rescan_workspace
TDQS
A4.4/5.0
Scored across 4 tools
Disambiguation5/5
Each tool has a clearly distinct purpose: list_groups exposes the grouping hierarchy, list_packages lists packages with filters, get_package_dependencies analyzes dependency relationships, and rescan_workspace refreshes the cache. There is no overlap or ambiguity among them.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case: list_groups, list_packages, get_package_dependencies, rescan_workspace. The naming is predictable and uniform.
Tool Count5/5
With only 4 tools, the set is tightly scoped for a ROS2 workspace graph server. Each tool addresses a distinct need, and the count is appropriate for the server's purpose without feeling thin or bloated.
Completeness5/5
The tool surface covers the core workflows: discovering groups, listing packages, querying dependencies (forward and reverse), and refreshing the index after changes. There are no obvious dead ends or missing operations for the stated domain of package graph exploration.
Maintenance
ActivityStale
ResponsivenessNo issues
Related MCP Connectors
Repository knowledge graph MCP server for codebase understanding and debugging.
Hosted code graph over MCP: exact callers, dependencies, and cross-repo blast radius for AI agents.
Render, verify, describe, and safely edit Mermaid diagrams through MCP.
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
Related MCP Servers
- AlicenseAqualityCmaintenanceProvides static analysis of ROS 2 workspaces, enabling inspection of packages, dependencies, interfaces, launch files, and robot descriptions without running ROS 2.72Apache 2.0
- AlicenseNot gradedqualityAmaintenanceProvides a traversable knowledge graph of the NVIDIA NemoClaw stack, enabling deterministic queries over its architecture, dependencies, and policies via MCP.2MIT
- AlicenseNot gradedqualityBmaintenanceExposes code graphs across multi-program repositories via MCP, enabling humans and agents to query the fleet with evidence.MIT