Loading ToolBench
Safe MCP server for Plastic SCM and Unity Version Control (cm 10.0.16.6656+, UVCS 11.x) source-control workspaces.
UVCS MCP demonstrates solid definition quality with 35 well-named tools following verb_noun conventions (uvcs_doctor, uvcs_branch_create_prepare, etc.). All tools have descriptions (avg ~80 chars, within baseline 34-392 range). Input schemas are present and properly typed with JSON Schema. However, descriptions are consistently terse (often 1-2 sentences) and lack LLM-optimized guidance on WHEN to use each tool vs. alternatives. Parameter descriptions are minimal, many lack format/constraint details. Output schemas are not documented in the tool definitions. Error handling is present (toolFailure with hints) but recovery guidance is sparse. Prepare/confirm pattern is well-implemented for write operations, reducing accidental mutations.
Confirm adding files or directories to the workspace.
Prepare to add files or directories to the workspace.
Confirm creating a branch.
Prepare to create a branch.
Return current branch information.
Analyze branch safety: merge base, conflicts, and cleanup candidates. Read-only.
Analyze changesets over an optional date, branch, owner, or comment filter. Read-only.
Confirm checking in pending changes.
Output schemas not documented. Tool definitions lack return type documentation, forcing LLMs to guess what fields are available for downstream tool chaining. This violates pattern:tool and pattern:response-shaper.
Descriptions are terse and lack LLM-optimized guidance. Most descriptions are 1-2 sentences (avg ~80 chars) without explaining WHEN to use each tool vs. similar alternatives (e.g., uvcs_workspace_status vs uvcs_pending_changes). Baseline for A+ tools is 50-200 chars with clear selection criteria.
Parameter descriptions lack format/constraint details. Many parameters (e.g., 'filePath', 'branch', 'query') have minimal descriptions without specifying expected format, valid patterns, or examples. LLMs cannot infer constraints from names alone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Prepare to check in pending changes.
Return cm diff output for a file inside the workspace.
Check cm, workspace, and UVCS MCP configuration.
Find branches matching a query. Read-only.
Find changesets matching a query. Read-only.
Confirm creating a label.
Prepare to create a label.
List workspace/server locks visible to cm.
Confirm merging a branch into the current workspace.
Prepare to merge a branch into the current workspace.
Preview a branch name or checkin message from workspace style rules.
Return full pending changes from cm status.
Show the effective workspace identity, safety profile, allowlists, write limits, and mass-work guidance.
Plan a major, minor, or patch release branch, label, and comments from workspace style rules. Read-only.
Show safety policy and branch/checkin/release naming setup in one place.
Confirm creation of .uvcs-mcp/style.json with branch naming, checkin message, and release conventions.
Prepare to create .uvcs-mcp/style.json with branch naming, checkin message, and release conventions.
Return workspace naming and release style rules.
Check whether workspace naming/checkin/release style rules exist. If missing, guide the model to ask the user to create them before branch work.
Confirm switching the workspace to a branch or changeset.
Prepare to switch the workspace to a branch or changeset.
Confirm undoing pending changes.
Prepare to undo pending changes.
Detect common Unity asset/.meta mismatches in the workspace.
Confirm workspace update.
Prepare to update the workspace.
Return concise workspace status.
Prepare/confirm pattern lacks clear error recovery guidance. While the pattern is well-implemented, error hints in tool-result.js are generic. Specific errors (e.g., WORKSPACE_CHANGED_SINCE_PREPARE) need richer context about what changed and how to recover.
No pagination or result-limiting guidance in tool descriptions. Tools like uvcs_find_branches and uvcs_changeset_analytics accept maxResults but descriptions don't explain why pagination matters or what happens if results exceed limits.