monity.ai

View a check screenshot

view_check_screenshot

Read-only

Returns the actual screenshot image from a check, so you can SEE the monitored page rather than infer it from a diff percentage. view: 'current' (the page as of this check), 'previous' (the page before it), or 'diff' (the two composited with changes highlighted). Pass checkId 'latest' to see the current state of a monitor without looking up a check id first. Use this to answer 'what does the page look like now?', to judge whether a reported change actually matters, and to work out the right CSS selector for an action or extractor by looking at the layout. These images are for you to look at; to show a change to the user, use get_check, and link a check by its checkUrl.

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": {
      "uuid": "<uuid>"
    },
    "name": "view_check_screenshot"
  }
}

Input Schema

Name	Required	Description
`uuid`	Yes	Monitor uuid (from list_monitors)
`view`	No	Which image: 'current' (default), 'previous', or 'diff' with changes highlighted
`checkId`	No	Check id (from get_check_history), or 'latest' for the most recent completed check. Defaults to 'latest'.
`maxWidth`	No	Longest width to scale to, default 1200, max 4000
`maxHeight`	No	Height bound, default 3000, max 4000. Full-page captures are very tall, so this is what usually decides the scale.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already cover read-only and non-destructive safety, so the description's contribution is the non-obvious behavioral fact that the image is returned for the agent to inspect, not for the end user — hence the handoff to get_check and the checkUrl note. It also documents the 'latest' shortcut as a behavioral convenience. It doesn't mention any cost, rate limits, or image-size caveats beyond what the schema carries, which keeps it short of a 5.

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-loaded with the payoff (you can SEE the page), then enumerates view values, then use cases, then the user-facing alternative. Every sentence is doing work, though the closing clause about linking checkUrl feels like a tacked-on aside rather than part of the tool's contract.

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?

There is no output schema, so the description must carry the return semantics — and it does, explaining what each of the three images depicts. For a five-parameter, single-purpose read tool with full annotation cover, an agent has everything needed to call it and interpret the result.

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 elaborates each view value ('the page as of this check', 'the page before it', 'the two composited with changes highlighted') and frames checkId 'latest' as a way to skip an id lookup. maxWidth/maxHeight get no prose in the description, but the schema already explains them fully, including which one usually governs scale.

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: 'Returns the actual screenshot image from a check', and immediately contrasts it with the alternative mode of knowing the page ('rather than infer it from a diff percentage'). The last sentence also separates it from get_check, so an agent can pick between them without opening either schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use cases: answering 'what does the page look like now?', judging whether a reported change matters, and choosing a CSS selector for actions/extractors. It also names the alternative and the condition that selects it ('to show a change to the user, use get_check').

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

All monity.ai 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?