Loading ToolBench
MCP server for webpage screenshot capture and DOM extraction
The server has two well-named tools with documented input schemas and reasonable descriptions, but falls short of production-grade quality in several dimensions. Both tools follow verb-noun naming conventions and have structured input schemas with parameter descriptions. However, output schemas are not explicitly documented, error handling lacks recovery guidance, and parameter descriptions could be more actionable. The tool descriptions are adequate (100-150 chars) but lack information about when to use each tool vs. the other, prerequisites, or failure modes. Parameter validation constraints are mostly absent (no enums, min/max bounds, or format specifications beyond basic type declarations). The tools themselves appear sound in concept but the definitions need refinement to guide LLM decision-making effectively.
Capture webpage screenshot with optional interactions.
Extract HTML/text/DOM structure. Use for text analysis or selector discovery.
Output schemas not documented. Neither tool defines what the response payload contains, field types, or structure. LLMs cannot plan downstream operations without knowing what data is returned.
Parameter descriptions lack actionable constraints. 'steps' param in captureScreenshot has no specification of step object structure, required fields per step type, or valid values for 'device'. 'selector' in extractDom lacks format guidance (CSS selector syntax).
Error handling lacks recovery guidance. No indication of what errors these tools might return, which are retryable, or what the LLM should do when element selectors fail. For example, 'ELEMENT_NOT_FOUND' is mentioned in MCP_INSTRUCTIONS but not formally documented as a possible error response.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Tool descriptions do not clarify when to use each tool or why. 'captureScreenshot' description does not explain that it's for visual snapshots with interaction, while 'extractDom' is for text/DOM extraction. An LLM might choose incorrectly without explicit guidance on the distinction.
No pagination or result limiting documented. Tools may return large responses (full DOM trees, large screenshots as base64) without specified limits or pagination support. This risks context window exhaustion and token waste.
Parameter 'headers' in captureScreenshot accepts arbitrary objects with no validation or constraint documentation. This is a security risk, arbitrary headers could be exploited for injection attacks. Constraint description is missing.