Loading ToolBench
MCP server that lets Claude hand browser tasks to TypeSafe's Jev: typed decisions in ~100 ms instead of one LLM round trip per click.
Single tool 'browse' has a well-structured schema with all four parameters typed and described. Description is comprehensive (500+ chars) and includes usage guidance, limitations, and error recovery instructions. Tool naming is clear (verb_noun pattern). No critical gaps, but several medium-priority improvements needed for production readiness.
Do a multi-step task on a live website in one call: search, fill forms, filter, navigate to a page. Faster than step-by-step browser tools: Jev picks one click/type/select per step in ~100 ms. Pass `values` with every exact string to type (["Zurich", "London", "20 September 2026"]): Jev picks which one goes in each field, no text model needed. A field that fits none of them ends the run with "error". Without `values`, a configured text model infers field values from the goal. Keep goals concrete and single-site, and say when to stop ("stop when the results are visible"). Status "done" is Jev's claim, not proof: check page_text. On "blocked", "looping" (same page reached 3 times), "timeout" or "error", `elements` lists the controls on the page so you can take over. Runs in a background tab of the user's Chrome, with their logged-in profile.
Output schema not formally documented. Description mentions 'status', 'elapsed_ms', 'url', 'title', 'page_text', 'steps', 'error', 'elements' but no JSON Schema definition provided. LLMs cannot reliably extract or chain on undocumented fields.
Parameter descriptions lack format constraints. 'url' and 'goal' have no guidance on expected format, length, or examples. 'max_seconds' has no min/max bounds stated (default 60 is present but range is missing).
Tool description is 500+ characters, exceeds LLM-optimized baseline of 50-200 chars. Verbose prose about limitations and recovery steps should be moved to a separate 'usage_notes' or 'limitations' field, leaving the description concise for tool selection.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Error handling is narrative, not structured. Description says 'On blocked, looping, timeout or error, elements lists controls' but does not specify error response format, error codes, or recovery guidance as structured fields. Per pattern:recovery-guide, errors should tell LLM what to do next.
No tool annotations present. Tool modifies state (interacts with live website, may trigger side effects) but lacks destructiveHint or idempotentHint annotations. Per current spec (2026-07-28), tool annotations help agents reason about safety and retry logic.