Loading ToolBench
Seiro MCP is an MCP server focused on spatial computing development. Today it provides tools to safely run visionOS project builds from Codex CLI, supporting autonomous AI-assisted coding workflows.
Seiro MCP has 5 tools with explicit registration in tool_registry.rs. All tools have names and descriptions present. However, descriptions are terse (30-50 chars), input schemas are minimal with limited parameter documentation, and critical context is missing. Parameter descriptions are sparse or absent for most tools. No output schemas are documented. Error handling exists but provides limited actionable guidance. The server targets a narrow domain (visionOS builds) which explains the specialized naming, but tool descriptions lack the specificity needed for LLM selection, they do not clearly state WHEN to use each tool vs alternatives, what prerequisites exist, or what the output structure looks like.
Build a visionOS project and return artifact metadata
Fetch metadata for the latest visionOS build artifacts
Inspect detailed diagnostics for a failed visionOS build job
Inspect available Xcode schemes for a project path
Inspect Xcode SDK detection context using sandbox probe settings
Validate allowed paths, SDKs, DevToolsSecurity, and related requirements
Output schemas not documented. No visible response field documentation for any tool. LLMs cannot plan downstream calls or extract chaining IDs (e.g., job_id from build output). Violates pattern:tool and mxe:response-field-naming.
Parameter descriptions are minimal (1-5 words) with no format constraints, enums, or ranges. 'Path to the visionOS project' does not explain absolute vs relative, required prefix, or symlink handling. Violates pattern:tool-description and review:param-validation-rules.
Generic action verbs in tool names. 'inspect_xcode_sdks' and 'inspect_xcode_schemes' use imprecise 'inspect' instead of 'get_' or 'list_'. LLMs cannot infer whether these return structured lists or text summaries. Violates pattern:tool naming.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 16 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Tool descriptions lack WHEN to use guidance. 'build_visionos_app' does not explain prerequisites (must validate_sandbox_policy first?), what 'artifact metadata' means, or when to call fetch_build_output. LLMs cannot determine tool selection priority. Violates pattern:tool-description.
Complex object parameters without nested documentation. 'inspect_xcode_sdks' accepts 'probe_settings' (object type) with no guidance on required/optional nested fields, field types, or valid values. LLM will hallucinate nested structure. Violates pattern:constrained-input.
Opaque identifiers (job_id) with no guidance. 'fetch_build_output' requires job_id but does not explain format, where to obtain it, or whether LLM should call build_visionos_app first. Violates mxe:natural-identifiers.
Irreversible tool without confirmation pattern. build_visionos_app is marked IRREVERSIBLE (will execute Xcode build) but has no dry-run, approval, or confirmation step. Agents can accidentally trigger expensive builds. Violates pattern:confirmation-request.
Error messages not actionable. VisionOsBuildError and other error types are mapped to ErrorData but source shows no recovery guidance (e.g., 'validation failed, check allowed_paths format'). LLMs cannot self-correct. Violates pattern:recovery-guide.
No pagination or result limits documented. If inspect_xcode_schemes returns hundreds of schemes, response will be enormous and degrade LLM reasoning. No limit or pagination parameters visible. Violates mxe:enforce-result-limits.