fullpageshot-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FULLPAGESHOT_OUT | No | Where screenshots are saved. | temp dir |
| FULLPAGESHOT_CHROME | No | Path to the browser binary. | auto-detected |
| FULLPAGESHOT_HEADLESS | No | Set to `0` to show a visible window. | 1 |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| open_urlB | Open a website in a controlled Chromium browser. Runs headless (background) by default; set headless=false for a visible window. |
| screenshotA | Capture a full-page screenshot (default) of the current page or of a URL. Saves a PNG/JPEG/WebP to disk and returns the image so it can be read. |
| read_screenshotA | Read a previously saved screenshot file back as image content. |
| close_browserA | Shut down the controlled browser and clean up its temporary profile. |
| browser_statusA | Report whether the browser is running, whether it is headless, its version, and the screenshot output directory. |
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 5 tools
Each tool targets a distinct action on the controlled browser: open, capture, read file, close, and report status. The only mild overlap is that screenshot can accept a URL directly, which slightly blurs the line with open_url, but otherwise the boundaries are clear.
Most tools follow a verb_noun pattern (open_url, read_screenshot, close_browser) which is consistent and readable. screenshot and browser_status deviate (noun-only), but the set is still predictable.
Five tools is a snug, well-scoped set for a headless-browser screenshot server, covering the core lifecycle without bloat. It sits at the lower end but each tool earns its place.
The browser lifecycle is well covered: open, capture, read back, close, and status. Minor gaps like page interaction (click, scroll, navigate) exist, but for a screenshot-focused purpose the surface is essentially complete.