frameshot
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FRAMESHOT_BROWSER_PATH | No | Custom Chromium executable path |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| render_fileA | Render a component file with full dependency resolution. Uses your project's Vite config to resolve imports, path aliases, CSS modules, and node_modules. Falls back to CDN-based rendering if Vite is unavailable. Auto-detects framework from file extension. |
| render_componentA | Instantly render a React/Vue/HTML component and return screenshots across browser engines. Zero setup needed — just pass your code. Tailwind CSS is built-in. Use this to visually verify UI code without starting a dev server. |
| render_responsiveA | Render a component at mobile, tablet, and desktop sizes in one call. Returns 3 screenshots for responsive verification. |
| render_themeA | Render a component in both light and dark mode side-by-side. Returns 2 labeled screenshots for quick theme verification. |
| render_variantsA | Render multiple variants of a component (different props/states) in one call. Returns a screenshot for each variant. Use this to verify buttons in all states, theme variations, etc. |
| render_gridA | Render multiple code snippets in a grid layout and return a single combined image. Use this to compare components side-by-side (e.g. design system overview, theme comparison). |
| render_matrixB | Render a component across multiple viewports AND themes in one call. Returns a grid of screenshots (viewports x themes) for comprehensive responsive + theme verification. |
| capture_animationB | Capture multiple frames of a CSS animation or transition over time. Returns sequential screenshots to verify animation behavior, timing, and smoothness. |
| render_interactionA | Render a component, simulate user interactions (click, hover, focus, type), then screenshot the result. Use this to verify hover states, dropdowns, modals, form inputs. |
| screenshot_urlA | Take a screenshot of a URL (e.g. localhost:3000) across multiple browser engines in parallel. Supports waiting for specific elements and retry with exponential backoff for dev servers that may be slow to start. |
| diff_componentA | Visual regression test: render before/after code and return a pixel diff image with percentage changed. Use this during refactoring to catch unintended visual changes. |
| diff_referenceA | Compare rendered component output against a reference image (e.g. from Figma export or previous snapshot). Returns pixel diff percentage and pass/fail status. Use this for design QA — verify your component matches the design. |
| audit_a11yA | Run an accessibility audit (axe-core) on a rendered component. Returns WCAG violations with impact level, description, and affected HTML nodes. Use this to catch a11y issues before shipping. |
| perf_auditA | Analyze component performance: DOM element count, tree depth, render time, script/stylesheet count. Use this to catch bloated components before they ship. |
| snapshot_saveA | Render a component and save the screenshot as a named snapshot. Use this to establish a baseline before making changes. Later use snapshot_check to detect visual regressions. |
| snapshot_checkA | Render a component and compare against a previously saved snapshot. Returns pixel diff and pass/fail. Use this after making changes to verify no visual regression. |
| snapshot_listA | List all saved snapshots with their names and timestamps. |
| render_catalogA | Scan a directory for component files (.jsx/.tsx/.vue/.svelte/.html) and render a screenshot of each. Returns a visual catalog — like Storybook but zero-config. Use this to quickly audit all components in a folder. |
| watch_startA | Start watching component files for changes. On every save, the component is automatically rendered and you will receive a notification — call watch_get_latest(id) to retrieve the rendered screenshot. Use this to create a live feedback loop while editing UI — the AI sees each change without you needing to call render_file manually. |
| watch_stopA | Stop a running file watcher started with watch_start. |
| watch_listA | List all currently active file watch sessions. |
| watch_get_latestA | Get the latest rendered screenshot from a watch session. Call this after receiving a watch notification to see the current state of the component. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 22 tools
Most tools have distinct responsibilities (render vs diff vs snapshot vs watch), and the render_* variants are separated by output type. However, render_component and render_file overlap as ways to render component code, and render_grid/render_matrix could be confused when comparing multiple views.
Tools overwhelmingly follow a predictable verb_noun pattern (render_, snapshot_, watch_, diff_). The main deviation is perf_audit, which reverses the verb_noun order used by audit_a11y, but the pattern remains readable.
22 tools is on the heavy side. While each tool has a plausible purpose, many render_* variants (responsive, theme, variants, grid, matrix) could be consolidated into a single parameterized render tool.
The surface covers the full visual QA loop: render, interact, compare, snapshot, audit, and watch. Minor gaps exist—there is no snapshot deletion or management beyond listing, and no way to control browser engines—but these do not create dead ends.