Loading ToolBench
Local HTTP-based MCP server for the wkdomains macOS application, providing tools for managing human requests, browser navigation, screen recording, and viewport capture.
Server has 5 tools with complete schemas and descriptions. Naming follows verb_noun convention (get_, wait_for_, reply_to_, update_, get_). Descriptions are adequate (80-180 chars, within baseline 34-392 range). However, parameter descriptions are minimal or absent in several tools, and output schemas are not documented. Error handling exists but lacks recovery guidance. No tool annotations (readOnlyHint/destructiveHint). Tools are well-composed for a request-response workflow but lack pagination and result limits documentation.
Return the current browser URL and host.
Return pending requests created by the human in wkdomains, including the current URL, derived domain, llms.txt URL, and required user-agent.
Send a terminal reply for a pending human request.
Send a short progress update for a pending human request without completing it. Use this before longer API calls or investigations so the wkdomains terminal does not look stuck.
Long-poll for a pending request created by the human in wkdomains. Returns immediately if a request is already pending; otherwise waits until one appears or the timeout expires.
Output schemas not documented. Tools return structured data (requests array, timedOut flag, ok boolean) but LLMs cannot see the expected response structure. This forces LLMs to infer field names and types, increasing hallucination risk.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). reply_to_human_request and update_human_request_status are write operations but lack destructiveHint annotation. get_* tools should have readOnlyHint. This prevents agents from understanding operation safety.
Error messages lack recovery guidance. Code returns '-32602' with 'Provide requestId and summary' but does not suggest what to do next (e.g., 'Call get_human_requests() to list pending request IDs'). Errors should guide the LLM toward resolution.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
wait_for_human_request timeout parameter lacks explicit bounds in description. Code enforces 1000-120000 ms, but description only mentions 'Defaults to 30000 and is capped at 120000', minimum bound is not stated. LLMs may pass invalid values.
No confirmation or dry-run pattern for destructive operations. reply_to_human_request completes a request irreversibly but offers no preview or confirmation step. Agents cannot verify intent before committing.