Loading ToolBench
Glint Render MCP server — give Claude, Cursor and other AI agents eyes on the web: screenshots, PDFs, OG images, monitoring and evidence from any URL.
OtterSnap has 8 tools with explicit registration and mostly complete schemas. Tool descriptions are substantial and actionable (all 50+ chars, median ~180 chars). All tools include detailed parameter descriptions. However, several critical gaps reduce the score: (1) workflow_create has a complex nested array schema with sparse type info on inner object properties, (2) no documented output schemas beyond implicit returns, (3) error handling is minimal, most tools lack recovery guidance, (4) no tool annotations (readOnlyHint/destructiveHint) despite clear safety implications, (5) render_pdf returns partial information ('bytes not inlined') but no documented metadata shape, (6) AI-driven tools (ai_extract, workflow_create) lack explicit guidance on LLM behavior or failure modes. Naming is consistent (verb_noun pattern) and parameter constraints are well-defined with enums and ranges. Most tools are read-only but lack annotations to signal this to clients.
Extract structured data from a web page using natural language. Give a URL, describe what you want (e.g. 'all product names and prices'), receive JSON. Powered by an LLM reading the rendered page.
Check remaining renders and quota for the configured OtterSnap key.
Turn a code snippet into a beautiful syntax-highlighted PNG (macOS-style window card). Great for sharing code on social media or docs.
Generate a branded 1200x630 Open Graph social card and return it visually.
Extract structured content from a web page: title, description, headings, links, images and the page body as clean Markdown — ready to feed to an LLM. This READS the page (use render_screenshot to SEE it).
Render a web page (or raw HTML) to a print-ready PDF file. Returns size info; PDF bytes are not inlined.
workflow_create uses a complex nested array schema (steps with inner object properties like 'action', 'url', 'prompt') but inner object properties lack explicit type definitions, only action has an enum, others are sparse. This invites invalid step configurations and runtime failures.
No tool annotations present. render_screenshot, render_pdf, create_og_image, extract_page, code_image, and check_usage are all read-only; workflow_create is destructive (creates a resource and may trigger network requests). Missing readOnlyHint and destructiveHint annotations prevent clients from optimizing execution plans and displaying appropriate confirmations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | 2026-07-28+ | v2 |
Render a web page to an image and return it visually — gives the calling agent eyes on any URL. Supports full-page captures, retina scale, dark mode, element selection and cookie-banner blocking.
Create a Glint workflow — an automation that runs steps (screenshot, extract, fetch, AI, email, webhook) on a trigger (schedule / page-change monitor / inbound webhook). 1 credit per run.
No documented output schemas for any tool. Responses are implicit (e.g., render_screenshot returns {content: [image + text]}, check_usage returns {content: [text]}). LLMs cannot reliably plan downstream operations without knowing the exact structure. Tools like extract_page return JSON with {title, description, headings, links, images, markdown, word_count} but this is documented only in code comments, not in a formal schema.
Error handling is minimal. Most tools have a single catch for fetch errors ('OtterSnap {status}: {detail}'). No guidance on recovery, retryability, or actionable steps. For example, if a URL is invalid, the agent gets 'OtterSnap 400: ...' with no hint to try a different URL or check the format. For ai_extract, if the LLM fails to extract data, there's no fallback guidance.
check_usage response structure is undocumented. The handler returns {content: [{type: 'text', text: '...'}]} but the underlying API response shape (j.plan, j.used, j.quota, j.remaining, j.period_reset_at) is inferred from code. No formal output schema means LLMs cannot reliably parse quota values for downstream decisions.
render_pdf explicitly states 'PDF bytes are not inlined' but response metadata (paper size, page count, landscape flag) is not documented. LLM cannot know if the response includes a URI, a file size, or metadata needed to display or store the result.
ai_extract tool description lacks clarity on LLM behavior, cost, and failure modes. What happens if the prompt is ambiguous? Does the LLM retry? Is there a cost per call? The description says 'Powered by an LLM reading the rendered page' but does not explain latency, reliability, or error recovery.
workflow_create references watchId for 'watch' trigger type but does not explain what a valid watchId looks like, where to find it, or how to discover available monitors. This forces the agent to guess or make extra API calls.