Pixel-perfect webpage screenshots rendered in a real browser, full-page or viewport, via one POST.
Scored across 2 tools
The two tools have clearly distinct purposes: one creates a session and the other captures a screenshot. No overlap or ambiguity between them.
Naming is inconsistent: 'screenshot' is a bare noun while 'session_create' follows a verb_noun pattern. This mixed convention could confuse agents about expected action formats.
With only 2 tools, the surface is minimal but not absurdly thin for a focused screenshot service. However, it lacks the richness expected even for a simple API.
The domain appears to be screenshot capture with session management, but there is no session deletion, list, or other lifecycle operations. This creates dead ends where a session cannot be cleaned up programmatically.
V1 Screenshot
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| encode | No | ||
| fullPage | No | ||
| sessionId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses nothing: no mention of browser launching, network side effects, session requirements, output format, latency, or failure modes. For a tool that likely performs a side-effectful browser operation, this is a critical gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three words is not conciseness; it is under-specification. The text front-loads a version identifier rather than functional information, offering no useful content that earns its place. There is no structure conveying purpose, usage, or behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no annotations, no output schema, and 0% schema description coverage, this description is completely inadequate. An agent has no way to know valid parameter values, whether parameters are optional in practice, what the return value looks like, or what side effects occur. The description does not meet the minimum information needed to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds zero meaning to any of the 4 parameters. It does not clarify what 'encode' accepts, what 'fullPage' controls, whether 'url' is the target page, or how 'sessionId' relates to session_create. The parameter names are weakly self-explanatory at best, but the description must compensate for the 0% coverage and does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'V1 Screenshot' is essentially a tautology that restates the tool name and adds a version label. It conveys that the tool relates to screenshots, but never states the action explicitly (e.g., capture, save, return) or the resource it operates on. An agent cannot determine the tool's full scope from this text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, when not to use it, or prerequisites. The only sibling, session_create, hints that sessionId may be involved, but the description never explains the relationship. No context is provided for an agent to decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
V1 Session Create
| Name | Required | Description | Default |
|---|---|---|---|
| ttl_minutes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It discloses nothing about side effects, session persistence, TTL enforcement, state changes, or lifecycle implications of creating a session.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three words long, but this is under-specification rather than concise effectiveness. No sentence earns its place because no substantive information is conveyed at all.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one meaningful parameter, no output schema, and no annotations, the description must explain what a session is, how TTL minutes behave, and how the result is used later. It does none of this, leaving the agent completely uninformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds no meaning to the single parameter 'ttl_minutes'. The agent cannot learn what the TTL controls, the units (though implied by the name), what null default means, or how the value affects session behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'V1 Session Create' is a tautology that merely restates the tool name with a version prefix. It does not state what a session is, what creating one accomplishes, or how it differs from the sibling 'screenshot' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The sibling tool 'screenshot' exists, but no conditions, prerequisites, or routing context are provided to help an agent decide which to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
screenshotsession_createScreenshot any website with one API call PNG, JPEG, WebP, or PDF. Custom viewports, device emulation, ad blocking, dark mode, and smart caching.
Free screenshot and webpage capture API. Capture full-page screenshots, specific elements, or PDF snapshots of any URL. No API keys required.
Screenshot any URL as a hosted image. No local browser; handles bot walls and full-page captures.
Render-and-verify API: HTML/CSS to image or PDF, screenshot any URL, confirm the text rendered.
Add one secure layer between your agents and this server.
