Skip to main content
Glama
Sign In
agentsvc-mcp

agentsvc-mcp

by jakobautomation
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

screenshot

Capture any URL as a PNG image with full JavaScript rendering for SPAs and dynamic content. Returns base64 PNG.

Instructions

Screenshot API — Capture any URL as a PNG screenshot. Returns image_base64 (base64 PNG; decode to get raw bytes). Full JS rendering via Playwright, works on SPAs and dynamic content. Params: url (required), width px (default 1280), height px (default 800), full_page boolean, wait_ms. Cost: $0.009 USDC per call. Latency p99: 2800ms.

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": {
      "url": "<url>"
    },
    "name": "screenshot"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesThe URL to capture
widthNoViewport width in pixels
heightNoViewport height in pixels
wait_msNoWait time after page load in ms
full_pageNoCapture full page height

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the return payload format (image_base64, base64-encoded PNG requiring decode), the rendering engine and its capability envelope, per-call cost ($0.009 USDC), and p99 latency. It omits failure modes, rate limits, and any auth/payment prerequisites implied by the per-call cost.

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?

Five compact sentences, front-loaded with purpose, then return contract, capability, params, and operational cost/latency. No filler and no repetition; each sentence adds a distinct fact an agent needs.

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?

No output schema exists, and the description compensates by explaining exactly what comes back and how to decode it. Combined with the 100%-covered schema, cost, and latency, an agent has everything needed to invoke and interpret this tool without further exploration.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter is already documented in the schema, including defaults. The description's param list restates url/width/height/full_page/wait_ms with essentially the same meaning and adds no format or interaction detail (e.g. how wait_ms interacts with full_page). Baseline 3 is correct here.

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?

States a specific verb and resource ('Capture any URL as a PNG screenshot') with an unambiguous output artifact. An agent can distinguish this from near siblings like html_to_pdf, webpage_reader, or chart_render purely from the description.

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?

Gives a clear condition for selecting it: 'Full JS rendering via Playwright, works on SPAs and dynamic content', which tells the agent this is the right tool for rendered pages rather than static fetches. However, it never names an explicit alternative or states when NOT to use it (e.g. static text extraction should go to webpage_reader).

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