Loading ToolBench
MCP server that exposes build error capture and status tools for AI coding assistants. Drains pending build output captured by devtap from local or remote stores.
devtap exposes 2 tools with clear, action-verb naming (get_build_errors, get_build_status). Both have good descriptions (81-165 chars, within production baseline of 34-392 chars). However, input schemas are completely empty, both tools define `InputSchema{Type: "object", Properties: map[string]Property{}}` with no parameters documented. This violates a hard scoring rule: tools with no documented parameters in their schemas cannot score above 50 for schema quality. Output schemas are not documented in the source, and there is no structured output definition visible, only plain text responses sent as ContentBlock{Type: "text", Text: ...}. Error handling exists but is minimal (generic error messages, no recovery guidance). No tool annotations (readOnlyHint, idempotentHint, etc.) despite both tools being read-only operations. The server is otherwise well-structured and uses JSON-RPC correctly, but definition quality is hampered by absent schema detail and missing output documentation.
Get pending build errors and output captured by devtap. Call this at the start of each task and before writing or editing code to check for build failures that need fixing. A separate terminal may have captured new build errors or user messages at any time. If build succeeded, acknowledge briefly without repeating the output. If build failed, present the error output verbatim — do not summarize or reinterpret error content.
Get a summary of pending build output counts for the current session.
Output schemas not documented. The source shows plain text responses (ContentBlock{Type: "text", Text: ...}) but no formal output schema is declared. LLMs cannot parse structured return data or plan downstream tool calls without documented return types.
No tool annotations. Both tools are read-only (Risk: READ_ONLY in the spec), but the tool definitions lack readOnlyHint or idempotentHint. This forces the LLM to infer tool semantics instead of reading explicit annotations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 39 | 2026-07-28+ | v2 |
Error handling lacks recovery guidance. Error responses are generic (e.g., 'Error draining messages: %v'). Per pattern:recovery-guide, errors should suggest what to do next (e.g., 'Session not found. Try calling get_build_status() to verify the session ID.').
No parameter descriptions. Although both tools have empty parameter sets, if any parameters were added in future revisions, they would lack descriptions. The rubric requires 'Every parameter needs a description explaining what it controls.'