Loading ToolBench
MCP (Model Context Protocol) server that integrates with ChatGPT through Railway deployment with WebContainers, providing container management, file operations, terminal execution, and agent-to-agent communication
Disco MCP Server has 4 tools with basic but incomplete definitions. All tools have descriptions (10-80 chars, mostly too short) and input schemas with some typing, but lack depth in parameter documentation, output schema clarity, and error handling guidance. Tool names follow verb_noun convention appropriately. Schemas are present but terse. No tool annotations (readOnlyHint/destructiveHint) despite destructive operations. Composition is reasonable (separate create/read/execute tools), but descriptions lack context on when to use each tool vs alternatives, and no parameter descriptions detail constraints or expected formats.
Create a new development container with WebContainer support
Create or update a file in a development container
Execute a command in a development container
Read a file from a development container
Descriptions are too terse (10-80 chars). They state WHAT briefly but omit WHEN to use, expected return format, and dependencies between tools. 'Read a file from a development container' lacks context for LLM selection vs other tools.
Parameter descriptions are absent or minimal. 'containerId' lacks explanation of format, origin (returned from create_container?), or whether it is stable across sessions. 'path' in create_file/read_file does not clarify if it is absolute or relative, or what characters are forbidden. LLMs cannot infer these constraints.
No output schema documented. LLMs do not know what fields create_container returns (e.g., does it return containerId, status, ipAddress, lifecycle metadata?). Without documented output, agents cannot plan downstream tool calls or extract the right data. See 'D. SCHEMAS & OUTPUT' critical check.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 41 | 1.18.2+ | v1 |
create_container and execute_command are destructive (WRITE risk) but lack tool annotations (destructiveHint=true). LLMs need explicit signals that these operations modify state and may have irreversible consequences.
No error handling guidance in tool descriptions. execute_command and create_file do not explain what happens on permission denied, disk full, or invalid path. LLMs receive raw errors with no recovery hints, leading to confusion or infinite retry loops.
template parameter in create_container lists examples ('node', 'python', 'react') in description but does not declare them as an enum constraint. LLMs may hallucinate invalid template names. Should use JSON Schema enum: ["node", "python", "react", ...] to make valid choices machine-parseable.
workingDirectory parameter in execute_command defaults to '/' but lacks description explaining relative vs absolute paths, or security implications of allowing arbitrary paths. Description should clarify: 'Absolute path within container (defaults to /). Relative paths are not supported.'
encoding parameter in create_file defaults to 'utf-8' but lacks description of supported encodings, or what happens if an unsupported encoding is requested. No constraint list (enum) provided.