lyra-browser

Official

Overview Schema Source Related Servers Discussions Admin

screenshot

Capture the current page as a PNG and return its file path so agents can visually inspect layout, images, and charts that text extraction cannot convey.

Instructions

Capture the page as a PNG file and return its path.

Use it to see the page — layout, images, charts, anything read_page cannot put into words. The file is what you look at; inline=true adds base64 only for a client without access to this machine's filesystem.

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

Input Schema

Name	Required	Description	Default
`inline`	No
`full_page`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 3, 2026

TDQS

A4.3/5.0

Behavior4/5

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

No annotations are provided, so the description carries the burden. It discloses the output artifact (a PNG path) and the conditional base64 behavior of inline=true, which is genuinely useful context. It stops short of stating permissions or that the operation is read-only/non-mutating, leaving a small gap.

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 core action, then justification, then the inline caveat. Every clause adds information, though the sentence about the file being 'what you look at' is slightly redundant with the preceding line.

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

Completeness4/5

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

An output schema exists, so return values need not be detailed, yet the path is still surfaced helpfully. Usage is well covered; the only real omission is any explanation of the full_page parameter.

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 coverage is 0% with 2 parameters. The description explains inline=true (base64 for clients without filesystem access) but says nothing about full_page, leaving half the parameters undocumented in both schema and prose.

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 the page as a PNG file') plus the return form (its path). It explicitly distinguishes itself from the sibling read_page, so an agent can choose 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?

Explicitly names when to use it — to *see* layout, images, charts, anything read_page cannot verbalize — and names the alternative tool. The inline clause further scopes usage to clients lacking filesystem access.

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