ROS 2 Workspace Inspector MCP

by doer0312

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct aspect of ROS 2 workspace inspection: workspace-level scanning, package-level metadata, dependencies, interfaces, launch files, robot descriptions, and a cross-cutting diagnosis. No two tools overlap in purpose; even the diagnosis tool explicitly reuses the others but provides a different aggregated output.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (scan_workspace, inspect_package, analyze_dependencies, inspect_interfaces, analyze_launch_file, inspect_robot_description, diagnose_workspace). The verbs vary semantically but the structural consistency and clear object nouns make prediction easy.
Tool Count5/5
Seven tools is an appropriate scope for a static analysis inspector, covering the key artifacts without fragmentation. Each tool has a clearly separate responsibility, and none feel redundant or extraneous.
Completeness5/5
The surface covers the major static analysis needs of a ROS 2 workspace: packages, dependencies, interfaces, launch files, and robot descriptions, plus a diagnostic aggregator. For a read-only inspection tool, there are no obvious missing operations that would cause dead ends.
Average 4.5/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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 explicitly discloses what the tool does NOT do: 'does not run rosdep, query the network, or install anything', and adds 'deterministic' to imply reproducible, side-effect-free behavior. This is valuable beyond the schema.
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, each serving a distinct purpose: the primary function, the scoping behavior, and explicit non-behaviors. There is no redundancy or filler, and it is front-loaded with the main action.
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 an output schema exists and the tool has only two optional parameters, the description covers the core functionality, scoping options, and important constraints. Minor gaps remain around selector interaction and the exact nature of the graph output, but overall it is complete for typical use.
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 lists two optional string parameters with no descriptions. The description assigns meaning by stating 'with package_name or relative_path it analyzes that package scope', but it does not explain value formats, precedence, or what happens if both are supplied. This is a moderate improvement over the bare schema.
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 starts with a specific verb 'Parse' and a resource 'package.xml dependency declarations', and states the clear output of a 'deterministic workspace graph'. This distinguishes it from sibling tools like scan_workspace or inspect_package, which focus on different aspects.
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 clearly explains scoping: without a selector, it analyzes the workspace; with package_name or relative_path, it analyzes that package scope. This provides explicit usage context, though it doesn't explicitly name alternate tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 successfully discloses that the tool is read-only ('without... file changes'), performs local validation, and classifies type references without requiring external tooling. This addresses key safety aspects, though it does not detail error behavior or output specifics (which might be covered by the output schema).
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 with no redundant information. The main action and scope are front-loaded in the first sentence, and the second sentence efficiently adds the no-side-effects guarantee.
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 tool's moderate complexity and the existence of an output schema, the description covers the essential context: input selection methods, optional filtering, and the side-effect-free nature of the analysis. It lacks some details about when to prefer relative_path over package_name, and the meaning of 'classifies type references' is not elaborated, but overall it is sufficiently complete for an agent to understand the tool's role.
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 provides only parameter names and types with 0% description coverage. The description compensates by explaining that package_name or relative_path are alternative selectors and interface_name is an optional filter, which adds meaning beyond the schema. However, it does not provide detailed semantics for each parameter, such as mutual exclusivity, path formats, or exact matching behavior, leaving some gaps.
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 action ('Statically parse') and the resource ('.msg, .srv, and .action files') within a single package, selected by name or relative path. This explicitly distinguishes it from siblings like inspect_package by focusing on interface definitions and by noting the lack of builds or imports.
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 clearly conveys when to use this tool: for static, side-effect-free parsing and validation of interface files, as it explicitly notes operating 'without ROS generators, imports, builds, or file changes'. However, it does not name sibling tools as alternatives or provide exclusionary phrasing like 'use inspect_package for broader package analysis'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It explicitly states the operation is static and does not import, build, run, or modify code, which is strong transparency. It goes beyond the schema by clarifying the non-destructive nature and the type of metadata returned.
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?
Single sentence with no fluff. It front-loads the verb and resource, then efficiently packs selection method, return content, and safety constraints. Every phrase earns its place.
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?
The description covers purpose, selection, return types, and safety, which is sufficient for a read-only inspection tool. It doesn't mention error cases or what happens if both parameters are provided, but the output schema exists and the tool's scope is narrow, so completeness is high.
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?
Schema coverage is 0% and parameters have no descriptions, but the description names both parameters and explains that either package_name or relative_path selects the package. This adds meaningful semantic context beyond the raw schema, though it doesn't address precedence or exclusivity.
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 inspects a single package, selected by either package_name or relative_path. It distinguishes itself from sibling tools by focusing on static inspection of one package rather than scanning, dependency analysis, or diagnostics.
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 need package metadata without executing code, but it does not explicitly name alternatives or provide when-to-use vs. when-not-to-use guidance. The context of sibling tools helps, but the description itself lacks direct exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It explicitly states 'statically analyze,' 'never executes launch actions or commands,' and reveals parsing methods (AST, safe loading), giving strong transparency about safety and internal behavior.
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 and front-loaded with the action and resource. Every clause adds value (returns, parsing method, non-execution), with no wasted words 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?
The description covers what the tool does, its input (workspace-relative path, supported file types), what it returns, and its safety behavior. An output schema handles return details, so the description is complete for the tool's complexity.
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 schema has 0% coverage, so the description must compensate. It adds meaningful context by clarifying 'relative_path' is 'workspace-relative' and applies to Python, XML, or YAML launch files. It doesn't detail path formatting, but for a single string parameter it provides sufficient semantic grounding.
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 and resource: 'Statically analyze one workspace-relative Python, XML, or YAML ROS 2 launch file.' It also lists what it returns (nodes, includes, arguments, environment changes, processes), clearly distinguishing it from siblings that scan workspaces or inspect packages.
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 clearly implies the tool is for analyzing a single launch file, and the qualifier 'statically' signals a safe, non-executing analysis. However, it does not explicitly name alternatives or state when not to use it, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description explicitly states the tool is read-only, bounded, does not build/execute/modify files, and provides compact severity summaries and deduplicated issues. This is excellent behavioral disclosure covering safety and output behavior.
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?
A single sentence packs key attributes (bounded, read-only, reuses analyzers, output type, non-mutating) without redundancy. It is well-front-loaded and every clause earns its place.
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?
Given zero parameters and an output schema, the description thoroughly covers what the tool does, its safety profile, and its return value. It is complete enough for an agent to select and invoke the tool correctly.
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?
No parameters exist, so the description isn't required to explain them. The baseline for zero-parameter tools is 4, and the description adds no parameter-specific meaning because there are none to explain.
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 verb 'diagnose' clearly targets the workspace, and the description distinguishes it from individual analyzer tools by noting it reuses them and returns aggregated, deduplicated results. This makes the tool's purpose specific and differentiated from its siblings.
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 implies a combined, high-level diagnosis across multiple analyzers, but doesn't explicitly name alternative tools or state exclusions like 'for a single package, use inspect_package'. Clear context is provided, but no explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It clearly notes 'It never runs xacro or ROS' and explains the differing outputs for URDF and Xacro ('explicitly unexpanded'), providing critical behavioral context beyond basic function.
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 main action is front-loaded, and every clause adds value (static nature, file type, return summary, no execution).
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 single-parameter inspection tool with an output schema, the description adequately covers scope, behavior, and return expectations. It explains what is returned for both URDF and Xacro, and confirms no side effects, making it complete for the intended use.
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?
Schema coverage is 0%, but the description adds meaning to 'relative_path' by specifying it is workspace-relative and for a single URDF/Xacro file. This helps an agent understand the path's context, though it lacks examples or further format constraints.
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 explicitly states 'Statically inspect one workspace-relative URDF or Xacro file' with a specific verb, resource, and scope. It clearly distinguishes from sibling tools (scan_workspace, inspect_package, etc.) by focusing on a single robot description file.
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 gives clear context that this is for a single file (not workspace-wide) and is static. However, it does not explicitly name alternatives or state when not to use it, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly discloses the read-only nature, that it does not build/run/modify the workspace, and the limits of its analysis scope. This gives the agent a complete safety and behavior picture.
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 action and scope, then a clear delimitation of non-goals. No filler words 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?
Given no parameters and an existing output schema, the description fully covers the purpose, scope, safety, and limitations. It is complete for a read-only scan tool in the context of its siblings.
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 tool has zero parameters, so baseline is 4. The description adds context about what the tool operates on (workspace, packages, package.xml), but there are no parameter semantics to clarify further.
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 ('Scan') with a clear resource ('configured ROS 2 workspace') and scope ('packages and basic package.xml metadata'). It immediately distinguishes itself from siblings by explicitly listing what it does not do (dependency, launch, interface, robot-description 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?
Provides clear exclusions ('does not perform full dependency, launch, interface, or robot-description analysis') which imply when to use alternative sibling tools. It also states 'read-only' as a usage context. However, it does not explicitly name the alternative tools, so slightly shy of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ros2-workspace-mcp MCP server](https://glama.ai/mcp/servers/doer0312/ros2-workspace-mcp/badges/card.svg)](https://glama.ai/mcp/servers/doer0312/ros2-workspace-mcp)

Score Badge

Copy to your README.md:

[![ros2-workspace-mcp MCP server](https://glama.ai/mcp/servers/doer0312/ros2-workspace-mcp/badges/score.svg)](https://glama.ai/mcp/servers/doer0312/ros2-workspace-mcp)

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/doer0312/ros2-workspace-mcp'

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