Skip to main content
Glama
Sign In
chromaphore-mcp

chromaphore-mcp

Official
by nodriver-project
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Save a screenshot

screenshot

Saves a PNG of the current page view or full page to a file and returns its path, enabling automated capture or archival without displaying the image.

Instructions

Saves a PNG of the view (or the whole page) to a file and answers with its path; shows you nothing.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "screenshot"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathNoWhere to save it (default: screenshots/ under the working folder).
full_pageNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it does well on the two biggest footguns: it declares the tool writes to the filesystem and explicitly warns that no image content is returned ('shows you nothing'), preventing a costly misuse. It omits other mutation-relevant behavior such as whether an existing file at the path is overwritten, whether the directory is auto-created, and whether the call requires the page to be open first.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence, front-loaded with what is produced and where it goes, closing with the highest-value caveat. No filler, no restatement of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 2-parameter, no-annotation, no-output-schema tool, the description covers the key unknowns by naming the return value (the path) and the fact that no image is returned. Remaining gaps are modest but real: the default for 'full_page' and file-overwrite behavior are unstated, and both matter for a write-to-disk operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%: 'path' is documented in the schema, but 'full_page' has no description there. The description compensates by mapping 'or the whole page' directly onto that flag, giving the otherwise-documented-nothing boolean a clear meaning. It does not state the default for 'full_page' or how 'path' interacts with the working-folder default, which keeps it from a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete verb and artifact: it saves a PNG of the view or the whole page and returns its path. The scoping parenthetical 'or the whole page' tells the agent the capture extent is variable. It stops short of naming the sibling 'view' as the alternative, though 'shows you nothing' implicitly carves out that distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The trailing clause 'shows you nothing' implicitly signals when this is the wrong choice versus a viewing tool, and the phrase 'to a file' signals the save-to-disk use case. However, no sibling is named and there is no explicit statement of when to prefer this over 'view' or 'observe'. Usage is inferable but never stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools