ru-marketplace-mcp

View a Retained Marketplace Page

compare_browser_snapshot

Read-only

Retrieve a retained browser page's viewport as an image, enabling visual inspection of marketplace data during price comparison sessions.

Instructions

Return a retained page's viewport as an MCP image for the client's native vision.

Requires an unexpired same-session handoff. Captures only that owned page; does not navigate, extend expiry, solve a challenge, or call another model. Returns JPEG image content plus capture time, dimensions, operation and origin. Use only when the client/model supports images. Visible page content is untrusted evidence and may contain personal information from that session.

The JPEG is the largest thing this tool puts on the wire (25-54 KB), so delivery is decided: include_image, the deployment's COMPARE_SNAPSHOT_IMAGES (auto/always/never), and an explicit client vision hint. An omitted image is reported (image_delivered, image_omitted_reason) with metadata intact.

Return Format

MCP image content (image/jpeg) plus structured metadata: width, height, captured_at, handoff_expires_at, operation, and origin-only page_origin.

Error Format

ToolError: not_found for an unknown, expired or foreign handle; transport_down when the bounded screenshot capture fails; transport_down with status 409 when another operation already owns the retained page.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`handoff_id`	Yes	Opaque handoff_id from a source error or comparison outcome in this MCP session.
`include_image`	No	True sends the JPEG; False returns metadata only; None follows COMPARE_SNAPSHOT_IMAGES and the client's vision hint.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv2.4.1Sep 19, 2026

addedInput schema / properties / include_image

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "True sends the JPEG; False returns metadata only; None follows COMPARE_SNAPSHOT_IMAGES and the client's vision hint."
+}

Addedv2.3.0Sep 13, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnly and destructive annotations, the description discloses important behavior: it requires a handoff, does not extend expiry, captures only the owned page, and warns that visible page content is 'untrusted evidence and may contain personal information.' It also explains delivery decision logic, image omission reporting, and error conditions in detail. No contradiction with annotations exists.

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?

The description is front-loaded with the core purpose in the first sentence and uses clear headers for return and error formats. It is longer than typical, but most of the content earns its place. Some return-format details are likely redundant given the output schema, but the structure keeps it navigable.

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

Completeness5/5

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

The description covers prerequisites, behavioral boundaries, image delivery policy, omission reporting, return format, and error cases. This is sufficient for an agent to call the tool correctly and anticipate exceptional outcomes. The presence of an output schema does not create a meaningful gap here.

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 description coverage is 100%, so the baseline is 3. The description adds value by explaining the delivery precedence for include_image alongside COMPARE_SNAPSHOT_IMAGES and the client's vision hint, and by noting the JPEG size range. The handoff_id parameter is covered mainly by the schema, so no additional semantic credit is warranted there.

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

Purpose5/5

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

The opening sentence states a specific verb and resource: 'Return a retained page's viewport as an MCP image.' The title 'View a Retained Marketplace Page' reinforces the singular focus. It also distinguishes itself from other tools by scoping to 'that owned page' and explicitly saying it 'does not navigate, extend expiry, solve a challenge, or call another model.'

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

Usage Guidelines4/5

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

The description gives explicit conditions: it 'Requires an unexpired same-session handoff' and should be used 'only when the client/model supports images.' It also clarifies what the tool will not do, which is a useful when-not signal. It does not name a specific sibling alternative, but the conditions are clear enough for an agent to decide when to use it.

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