Loading ToolBench
An MCP server for managing DevPod workspaces, providers, and environments
DevPod MCP Server exhibits significant definition quality gaps. While all 10 tools have names following verb_noun convention and descriptions are present, parameter documentation is severely lacking. Most tools accept only 1-2 parameters with minimal constraint information. Input schemas are visible but incomplete, parameters lack proper type definitions beyond basic strings and booleans, and critical constraints (enums for 'output' parameter, ranges, formats) are absent. Output schemas are entirely undocumented. Error handling provides no recovery guidance. The tool set lacks composition clarity, tools like workspace_ssh accept free-form command strings without validation hints, and response field naming is not documented for chaining downstream calls. Parameter descriptions are generic (e.g., 'The ID or name of the workspace') without format guidance or validation rules. No tool provides pagination, limits, or structured output documentation.
List all DevPod contexts
List all available DevPod providers and their versions
List all DevPod workspaces with their status and provider information
Get detailed information about a specific DevPod provider
Set the active DevPod provider
Delete a DevPod workspace
Execute a command in a DevPod workspace via SSH
Get the current status of a specific DevPod workspace
Stop a running DevPod workspace
Output schemas are entirely undocumented. Tools return 'json' or 'text' but no specification of what fields/structure the response contains. LLMs cannot plan downstream calls or extract specific data without knowing response shape.
Parameters lack enum constraints for known-value fields. 'output' parameter accepts 'json' or 'text' but is defined as free-form string type, should be enum with explicit allowed values. workspace_up 'provider' parameter also lacks enum constraint for known provider types.
workspace_ssh accepts 'command' as free-form string with no validation hints, length limits, or security guidance. This is a high-risk tool (WRITE risk) that could be abused for command injection. Parameter description should warn about shell escaping, supported shell environments, and timeout behavior.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Start a DevPod workspace
workspace_delete is DESTRUCTIVE but lacks confirmation/dry-run support and error recovery guidance. Parameter descriptions do not explain what 'force' flag actually does (skip confirmation? skip backups? both?). No tool documents what to do if deletion fails partway through.
Parameter descriptions lack format guidance and validation rules. 'workspace_id' is described as 'The ID or name of the workspace' but omits: Does it accept display names only? UUIDs? Both? What format? Max length? This forces LLMs to guess and retry on invalid input.
No tool documents response field naming or structure. If list_workspaces returns workspace records, what fields are included? 'id'? 'name'? 'status'? 'provider'? Without documented field names, agents cannot extract data or chain calls to other tools (e.g., passing workspace_id to workspace_status).
Error handling provides no recovery guidance. No tool describes what errors can occur, what they mean, or what the agent should do next. E.g., if workspace_up fails because provider is not installed, should the agent call provider_use? List available providers? Retry? No guidance.
No pagination, limits, or result capping documented. list_workspaces, list_providers, context_list could return hundreds of items. Without max_results, offset/page, or next_cursor, large result sets bloat context and degrade LLM reasoning.