Loading ToolBench
AI-native developer experience plugin providing operating model bootstrap, skills, and harness for team projects
This MCP server demonstrates severe gaps in definition quality across all dimensions. Tool definitions are inferred from shell scripts and Python files rather than registered with explicit MCP schemas. No input schemas are visible in the provided code. Descriptions are present but vague and lack actionable context for LLM decision-making. Parameter documentation is minimal or absent. Output structures are not documented. The server appears to be a plugin harness (join-the-team) wrapping existing skill scripts rather than a production-grade MCP implementation with properly structured tool metadata.
Install a safe, version-bound operating-model seed into a target repository without overwriting existing files
Read-only SRE checkup for one GCP project using deterministic probes, headless read-only inspection, and notifications
Keep a code-intelligence semantic graph coherent and fresh by rebuilding when tracked source files are newer than the graph
Read-only inspection of an existing repository to pre-fill an operating profile with inferred findings
Independent code review on a Gemini lane via git pre-commit hook or manual invocation, returning verdicts (PASS/CONCERNS/BLOCK)
Validate an operating model profile against the day-one activation minimum
Validate Agent Plugins 1.0.0 and Agent Skills specification conformance and drift detection
No explicit MCP tool registration visible. Tool definitions are inferred from skill script file paths and parameters embedded in documentation, not registered via MCP protocol with formal schemas. This violates the core MCP pattern of explicit tool metadata.
Input schemas are not present in source code. Parameters are documented only in prose within descriptions (e.g., 'manifest' is 'path to the manifest (default ./.cloud-checkup.yaml)'). No JSON Schema with type definitions, constraints, or enums.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 38 | 2026-07-28+ | v2 |
Descriptions lack actionable context. E.g., 'Validate an operating model profile against the day-one activation minimum' does not explain WHEN to call this tool, what 'day-one activation' means, or what happens on failure. Descriptions average ~40 chars when 50-200 is baseline.
Parameters lack individual descriptions. In cloud_checkup, 'skip_ai', 'no_notify', 'model', 'project', 'region' are documented only as inline comments, not as descriptions tied to each parameter in the schema. LLMs cannot infer what 'skip_ai' does from the name alone.
No output schemas documented. Tools like 'cloud_checkup' (which returns 'notifications' and 'probe results') and 'inspect_repo' (which infers findings) provide no documented return type or field structure. LLMs cannot plan downstream tool use without knowing what fields to expect.
No error handling guidance. Tools like 'validate_operating_model' and 'validate_plugin' will fail on invalid input, but there is no documented recovery path (e.g., 'If validation fails, run inspect_repo() to diagnose'). Bare error codes force LLM guessing.
Tool names lack clarity for LLM decision-making. 'context_graph_refresh' is vague, refresh from where? What triggers rebuilding? Compare to 'rebuild_context_graph_if_stale' which is self-documenting. 'bootstrap_operating_model' is clear but its interaction with 'validate_operating_model' is not documented.
Destructive tools (bootstrap_operating_model, context_graph_refresh) lack confirmation or dry-run pattern. 'bootstrap_operating_model' has a 'dry_run' flag, which is good, but 'context_graph_refresh' offers only a 'force' boolean with no safety mechanism. An LLM might force-rebuild without understanding the cost.
Parameter constraints not formalized. 'review_gate' accepts 'mode' with enum [block, async], and 'surface' in bootstrap_operating_model with enum [agents, claude, gemini, all], but no JSON Schema enum is visible. Free-form parameter acceptance elsewhere (e.g., 'model' in cloud_checkup defaults to 'claude-opus-5' with no enum).