Loading ToolBench
Python implementation of Anthropic's Code Execution with MCP enhanced with Skills system (99.6% token reduction), multi-transport support (stdio/SSE/HTTP), and optional container sandboxing
This MCP server has significant definition quality gaps. Only 4 tools are exposed, all with minimal documentation. Tools are directly visible in multi_tool_pipeline.py and morph_apply.py, but lack depth in descriptions and parameter documentation. The server exposes git operations (3 read-only tools) and a file editing tool via Morph API. All tools have basic input schemas but descriptions are terse (under 100 chars each), and parameter descriptions are minimal. The git tools have only 1-2 parameters each with no constraints or validation guidance. The edit_file tool is more complex but still lacks documentation of output schema and error cases. No evidence of output schema documentation for any tool.
Get git branch information
Get git commit log
Get git repository status
Apply code edits using Morph Fast Apply API
Tool descriptions are critically brief (8-45 chars), providing minimal context for LLM selection. git__git_status is 28 chars ('Get git repository status'), git__git_branch is 28 chars ('Get git branch information'). The rubric baseline for tool descriptions is 194 chars average; these fall at p10 level or below.
Parameter descriptions are sparse or missing meaningful context. git__git_branch has a parameter 'branch_type' described only as 'Type of branch info (current, all, etc.)', no enum constraint, no explanation of valid values, no guidance on what each type returns. morph__edit_file's 'instruction' parameter lacks examples or format guidance.
No output schemas documented for any tool. LLMs cannot infer what fields to expect from git__git_status, git__git_log, git__git_branch, or morph__edit_file responses. This violates the pattern requirement: 'Document the output schema. LLMs need to know what fields to expect so they can plan downstream tool calls and extract the right data.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 56 | - | v1 |
No error handling documentation. Tools provide no guidance on failure modes (e.g., invalid repo path, permission denied, malformed code edit). The rubric requires: 'Error responses must tell the LLM what to do next'. None of these tools show recovery hints or error classification (retryable vs user-fixable vs fatal).
morph__edit_file accepts a 'dryRun' boolean parameter but no description explains the consequences of each mode or what a dry-run response looks like. The tool modifies state (WRITE risk) but lacks a confirmation/rollback pattern.
git__git_branch has an under-constrained parameter 'branch_type'. The description says '(current, all, etc.)' using example values instead of an enum. The rubric states: 'Replace "e.g. red, blue, green" with an enum constraint. Formal constraints are machine-parseable and prevent the LLM from treating examples as the only valid options.'
No validation guidance for parameter ranges or formats. git__git_log's 'max_count' parameter has no min/max bounds, LLMs could pass 0, negative numbers, or absurdly large values (1 million commits). The rubric requires: 'Specify minimum and maximum for numeric parameters (e.g. page_size 1 - 100, days 1 - 365).'
morph__edit_file's 'code_edit' parameter description mentions markers ('// ... existing code ...') but provides no schema or format validation. The tool likely expects a specific diff format, this must be documented with examples or a regex pattern in the description.