Loading ToolBench
Expose a secure local coding workspace through an MCP server. Provides file/process tools and unrestricted root shell access on Android devices.
Critical gaps across all dimensions. Tool definitions lack proper JSON Schema input validation, parameters are documented in descriptions but not formally typed. Most descriptions are generic and under 50 chars, violating the 10 - 1024 char baseline. No output schemas documented. Error handling is absent. Tool names mix concerns (e.g., 'tools/call' is a meta-operation, not a domain tool). OAuth tools expose security anti-patterns. The server appears to be a meta-MCP-server (dispatching to other tools) rather than a domain-specific tool provider, which is a fundamental architectural mismatch for this evaluation.
OAuth authorization endpoint for user consent flow
Check MCP server health status and service information
Initialize MCP session with protocol version negotiation (legacy protocol only)
Register an OAuth client for accessing protected resources
Discover MCP server capabilities and supported protocol versions
OAuth token endpoint for exchanging authorization code for access token
Call a specific MCP tool with provided arguments
List all available MCP tools
No input schemas visible in source code. Tools declare parameters in descriptions only (e.g., 'tools/call' has 'name' and 'arguments' but no JSON Schema type definitions, constraints, or enums).
Descriptions are generic and under 50 chars (e.g., 'Check MCP server health status and service information' is 56 chars but lacks WHEN to call, WHAT it returns, or prerequisites).
OAuth tools (register, authorize, token) expose security anti-patterns: 'client_name' and 'redirect_uris' as parameters invite credential leakage into logs. OAuth flows should be server-side only; client credentials must never be tool parameters.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 35 | <=2025-11-25 | v2 |
No output schemas documented. Callers cannot know what fields to expect from 'health', 'server/discover', 'tools/list', or 'token'. LLMs cannot plan downstream calls or extract required data without documented return types.
No error handling guidance. Tools lack recovery hints (e.g., 'If authorization fails, try register() first'). No categorization of errors as retryable, user-fixable, or fatal. Agents cannot self-correct.