relayted API

Screenshot in real browsers

shot

Take screenshots of a public web page in real browser engines (default: newest Chrome, 1920x1080, light scheme). Returns the images inline (PNG) plus download links. Costs 65 Payloads (0.0065 EUR) per screenshot = browser version x viewport x colour scheme, 40 from the 13th screenshot of one job. Browser ids and viewport presets: GET https://api.relayted.de/v1/services/shots.

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": "shot"
  }
}

Input Schema

Name	Required	Description
`url`	No	Public http(s) address of the page.
`job_id`	No	Collect the result of an earlier shot job instead of starting a new one.
`schemes`	No	Colour schemes. Default ["light"].
`browsers`	No	Browser ids, e.g. ["chrome","firefox"]. Default ["chrome"] (newest version each).
`full_page`	No	Capture the whole page instead of the viewport. Default false.
`viewports`	No	Sizes "WIDTHxHEIGHT" or preset ids. Default ["1920x1080"].

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4/5.0

Behavior3/5

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

Adds substantial behavior beyond the annotations: the combinatorial cost model (browser x viewport x color scheme, discounted from the 13th screenshot of a job) and the return form (inline PNG plus download links). These are genuinely useful details that the annotations do not convey. However, the async job flow implied by job_id is not explained here, so an agent cannot tell from the description whether results arrive synchronously.

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?

Front-loads the capability and defaults, then cost, then the discovery endpoint — a sensible order. It is dense and largely earns its length, though the cost arithmetic is squeezed into one clause that takes a second read.

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, the description does the right thing by describing return values, and it covers pricing and enum-source discovery. The remaining gap is operational: job_id semantics (polling, expiry, or whether a job is asynchronous at all) are left to the schema string, which is thin for a billed, non-idempotent 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 100%, so the baseline is 3, but the description adds real meaning: it names the canonical browser ids source, identifies viewport entries as presets or WIDTHxHEIGHT, and — most importantly — explains that browsers, viewports and schemes multiply against each other to determine cost and output count.

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 ("Take screenshots of a public web page") and immediately pins the scope to "real browser engines" with concrete defaults (newest Chrome, 1920x1080, light scheme). This clearly distinguishes it from document-oriented siblings like pdf or markdown.

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 clear context for use (public pages, real browser rendering) and tells the agent where to look up valid browser ids and viewport presets. It does not explicitly say when to prefer this over siblings such as pdf, nor does it state failure/precondition handling for non-public URLs.

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

All relayted API tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?