Loading ToolBench
Manage browsers via REST and MCP. Provides headless browser control, web page capture (markdown/text/html/pdf/screenshot), and browser item management through an MCP server interface.
The server defines 2 tools with mostly complete schemas and descriptions. Both tools have proper input parameter schemas with types and descriptions. However, there are significant gaps in output schema documentation, error handling guidance, and composition patterns. The 'capture' tool has an exceptionally detailed description (600+ chars) that exceeds best practices for token efficiency. The 'read-resource' tool is minimal but functional. Both tools lack explicit error recovery guidance and output schema documentation. Tool composition is weak, neither tool documents what downstream tools can consume their outputs. Overall Definition Quality averages 58/100 across both tools (read-resource: 52, capture: 64).
Fetch or capture a web page via headless Firefox. Five formats: 'markdown' (default, reader-mode extraction), 'text', 'html', 'pdf', and 'screenshot-png'. For markdown/text/html: all three base formats are always rendered; non-selected formats are returned as resource_link URIs that can be read via read-resource. A TOC of `#id` anchors is included as the first content block when no selector is supplied (or when a selector misses) — pass one of those ids as `selector` to trim the returned markdown to that section only. When a selector matches, the TOC is returned as a resource_link (`capture://<url>#toc`) instead of inline so it doesn't dwarf the section. Results are cached per URL for the lifetime of the MCP session; pass `refresh: true` to force a re-fetch. Use instead of the built-in WebFetch when you need complete, unsummarized content or when the page requires JavaScript to render. For pdf/screenshot-png: renders the page and returns the bytes inline as base64 (an image content block for screenshot-png, a base64 blob resource for pdf) — not cached, a fresh capture every call. `full-page` (screenshot-png only) captures the full scrollable page instead of just the viewport. `landscape`, `no-headers`, `background`, `paper-width`, `paper-height`, and the four `margin-*` flags (inches) are pdf-only page-setup options; unset values use the browser default (typically US Letter, ~0.4" margins, headers on, no background).
Read a chrest resource by URI (e.g. chrest://items, chrest://items/1)
Output schemas not documented. Neither tool explicitly documents what fields are returned, their types, or whether results are paginated. LLMs cannot plan downstream tool calls without knowing the response structure.
'capture' tool description is 600+ characters, exceeding best practice of 10-1024 chars (optimal 50-200). Verbose descriptions waste tokens and bury key details. Should be condensed and moved to parameter descriptions.
Error handling guidance is absent. No explicit error recovery instructions (e.g., 'Try search_* first if resource not found'). LLMs receive no guidance on retryability or corrective actions.
'read-resource' tool description (51 chars) is minimal and lacks context about what formats are supported or when to use it vs 'capture'. Description should clarify the relationship between these two tools.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | <=2025-11-25 | v2 |
No pagination metadata. 'capture' tool can return large results (full HTML, full markdown with TOCs). No indication of whether results are truncated, paginated, or if there's a size limit. Large untruncated results can exhaust context windows.
No tool chaining support. Neither tool returns IDs or references needed by downstream tools. E.g., 'capture' returns resource_link URIs, but it's unclear if 'read-resource' accepts those URIs directly or requires reformatting.