Loading ToolBench
mkinf run API v1 - MCP server for running tools in sandboxed environments
This server exposes 4 tools via HTTP endpoints, but exhibits significant definition quality gaps. Tool naming follows some verb conventions (listTools, runAction, sseStream, handleSseMessages), but descriptions are present yet shallow. Parameter schemas are declared with types and basic descriptions, but lack critical constraints, validation rules, and error recovery guidance. The server accepts arbitrary environment variables and parameters without documented constraints, and error handling is minimal. This is a typical community-grade server with working schemas but insufficient LLM-optimization and safety documentation.
Handle incoming POST messages for an established SSE stream session
List available tools from a hosted MCP repository by connecting to a sandbox environment and querying the tool list
Execute a tool action in a sandboxed environment by name with provided arguments
Establish a Server-Sent Events stream connection to a sandbox for bidirectional MCP communication
Missing output schema documentation for all tools. The source code shows parameter input schemas but nowhere in the provided code do we see documented return types, response structures, or field mappings that LLMs need to plan downstream calls.
No parameter constraints or validation rules documented. The 'env' parameter accepts arbitrary objects with no description of allowed keys, format, or constraints. The 'timeout' parameter lacks min/max bounds (e.g., is 600s a hard cap?). The 'action' parameter in runAction accepts any string with no enum of valid actions.
Error handling is minimal and non-actionable. The runController shows generic 500 errors ('Server error') with no guidance on retryability, recovery steps, or what the LLM should do next.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 28 | - | v1 |
Tool descriptions are generic and lack WHEN/WHY context. E.g., 'Execute a tool action in a sandboxed environment' doesn't explain when to use runAction vs sseStream, what the difference is, or what prerequisites exist.
Parameter 'action' in runAction lacks specificity. It's a free-form string with no enum, no description of valid values, no link to listTools output. An LLM has no way to know what actions are valid without calling listTools first.
SSE session management via 'sessionId' parameter in handleSseMessages is undocumented. Where does the sessionId come from? How is it created? What's its lifetime? LLMs cannot reason about session flow without this context.
No specification of idempotency for destructive operations. runAction accepts arbitrary args and can execute state-changing tools. The description says nothing about whether retrying with the same args is safe, or if it risks duplicate side effects (double-charging, duplicate records).
Response pagination not documented. If listTools or runAction return large datasets, there's no mention of limits, pagination cursors, or how to fetch additional results.
Tool naming inconsistency: 'handleSseMessages' uses underscore_case while others use camelCase. Additionally, 'handle' is a generic verb that doesn't convey the action clearly, could be 'sendSseMessage' or 'postSseMessage'.