Skip to main content
Glama
Sign In
pironjulien

nexus-browser

by pironjulien
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

browser_screenshot

Read-onlyIdempotent

Capture a tab, full page, or cropped element as a PNG and return its file path instead of bulky base64, so agents can inspect web content without large payloads.

Instructions

Screenshot of the tab, of the whole page (full_page=True), or of one element cropped to the pixel (PNG), even if the page has scrolled.

By default, the image is written to ~/.nexus/nexus-browser/screenshots/ and only its path is returned (output_path): no bulky base64 in the response. Do not open a capture larger than 500 KB with an image reader. Targeting:

  • selector: CSS selector of the element to crop (e.g. "#dashboard-card")

  • mark: mark number to crop (e.g. mark=4)

  • output_path: absolute PNG path (optional, otherwise the local cache)

  • full_page=True: the whole scrollable page, beyond the visible area (height capped at 16384 px; fullPage.truncated says so). Ignored when an element is targeted.

  • inline=True: attaches the image to the response (no file): WebP, long side at most 2000 px and 2.56 megapixels, at most 500 KB, so every model reads it as sent. data.image: width, height, scale and css_per_image_px, css_origin to turn a position on the image into page CSS pixels. Same target as the last image sent for this tab and nothing changed: no image again ("unchanged"), unless force=True.

  • region=[x1, y1, x2, y2]: zoom on that area, in pixels of the last whole-view image attached for this tab (browser_screenshot(inline=True) first): enlarged up to 4× within the same limits, to read small text without sending the whole view in large.

Input Schema

NameRequiredDescriptionDefault
markNo
forceNo
inlineNo
regionNo
tab_idYesYour tab's id (from browser_new_tab, or a tab adopted with browser_adopt_tab).
selectorNo
full_pageNo
output_pathNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only say read-only/idempotent/non-destructive; the description adds the operationally important behavior: default write location, no base64 bloat, the 500 KB reader warning, the 16384 px height cap with a fullPage.truncated flag, the WebP/2000 px/2.56 MP/500 KB inline limits, the 'unchanged' dedup response and the force override, and the extra css_per_image_px/css_origin mapping fields returned with the image.

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 capability and then organized under a 'Targeting' heading, with no filler sentences; nearly every clause carries a constraint. It is dense and long, and a few limits (4× zoom, megapixel caps) are packed in tightly, but nothing is redundant.

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?

For an 8-parameter tool with no output schema, it covers output format, size limits, caching, dedup and coordinate mapping thoroughly. Remaining gaps: what a 'mark' number originates from (presumably browser_find/browser_vision_inspect) and how this tool relates to browser_vision_inspect in a two-step inspect-then-crop workflow.

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

Parameters5/5

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

Schema description coverage is only 13%, so the description carries the burden and does: selector, mark, output_path, full_page, inline, region and force all get meaning plus examples and interaction rules (full_page ignored with an element target, region coordinates are in pixels of the last whole-view image). Only tab_id is left to the schema, which documents it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource (capture a screenshot of the tab, the whole page, or one element) and names the output format (PNG). It is precise about scope, but it never distinguishes itself from the closest sibling, browser_vision_inspect, so an agent must infer which one to reach for.

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 real decision rules: default is file + path returned, inline=True when the model should see the image, region requires a prior inline whole-view capture, and full_page is ignored when an element is targeted. Missing is any statement of when *not* to use this tool (e.g. in favour of browser_vision_inspect).

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