softglaze-browser-mcp

Overview Schema Source Related Servers Discussions Admin

Screenshot the page

page_screenshot

Read-onlyIdempotent

Capture a JPEG screenshot of the active browser tab—visible area or full page—without altering page content; approval is requested once per profile.

Instructions

Takes a JPEG screenshot of the main tab (the visible area, or the full page). Changes nothing. Asks once per profile.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "profileId": "<profileId>"
    },
    "name": "page_screenshot"
  }
}

Input Schema

Name	Required	Description	Default
`fullPage`	No
`profileId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 10, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so 'Changes nothing' adds nothing. Two genuine additions exist: the JPEG output format and 'Asks once per profile', which warns of a permission prompt — but 'asks' is never explained, leaving the agent unsure what is being requested.

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

Conciseness4/5

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

Three short sentences, front-loaded with the action and capped by two scoping facts. 'Changes nothing' is largely redundant against the annotations, but nothing else wastes space.

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

Completeness3/5

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

With no output schema and a trivially small parameter set, the definition is nearly adequate, but it leaves the profileId semantic and the permission-prompt behavior under-explained. An agent cannot tell from the description whether the screenshot is tied to a running session or what 'asks once' implies for retries.

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

Parameters2/5

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

Schema description coverage is 0% for both parameters, so the description must carry the load. It only obliquely gestures at fullPage via 'visible area, or the full page' without naming the flag or defaulting behavior, and profileId is never explained beyond the vague 'per profile'.

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?

A concrete verb plus resource: 'Takes a JPEG screenshot of the main tab', with the output format named. It does not differentiate itself from the near-sibling page_snapshot, so an agent must still guess which of the two it wants.

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 visible area, or the full page' implies the choice the caller faces, but the guidance is oblique and never states when to prefer this tool over page_snapshot or page_extract_text. No exclusions or prerequisites are given.

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