Skip to main content
Glama

measure_screen

Measures screen dimensions in points and pixels by tracing edges from a point, returning width, height, and fractional coordinates. Use to get numeric sizes (e.g., sidebar width) without screenshots.

Instructions

Measure the screen in points and pixels, without taking a picture of it. Plonk photographs the screen once and walks out from the given point in all four directions until one pixel is unlike the one before it, which is where an edge is. What comes back is how far the point could travel each way: the run across and the run down. Prefer this over take_screenshot whenever the answer is a number: how wide that sidebar is, how tall that row is, how big the gap between two things is, is that tap target 44 points. An image costs far more tokens and still has to be eyeballed. Use extract_text when the answer is words, and take_screenshot when it is 'what does this look like'. Read the result honestly: these are two independent runs through one point, not the outline of an element. Inside a plain rectangle they are its width and height; inside a gap they are the gap; on a large flat background they run until something else is in the way, which may be most of the screen. When the exact bounds of a specific element matter, pass 'interactive' and let the user point at it. Three ways to ask. Pass 'point' for the runs through one place. Pass 'from' and 'to' for the straight-line distance between two places, which needs no capture at all. Pass 'interactive' to hand the user the ruler and wait up to five minutes while they measure it themselves. Points are fractions 0..1 of the screen's visible area with origin at TOP-LEFT, the same space apply_layout and save_zone_set use, so {x:0.5,y:0.5} is the middle of the screen. Returns 'points' {x,y,w,h} in screen points (absolute, origin top-left of the primary display) where w is the run across and h the run down, 'pixels' {w,h} in the display's own pixels — twice the points on a Retina screen, which is the difference that matters when checking an asset — 'fraction' {x,y,w,h} of that screen's visible area ready to hand to apply_layout, 'scale', and 'text', the same line Plonk shows the user. A distance also carries 'distance' and 'distance_pixels'. Needs macOS Screen Recording permission, the same as a screenshot; without it the call fails rather than guessing. What is measured is a still taken when the call started, so a screen that is animating measures as it was at that moment.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoThe other end of a distance, in the same fractions as 'point'
fromNoOne end of a distance, in the same fractions as 'point'
pointNoWhere to measure from, as fractions 0..1 of the screen's visible area, origin TOP-LEFT. {x:0.5,y:0.5} is the middle of the screen
screenNoMonitor index from get_state (0 = primary, the default). Every point is a fraction of this screen
toleranceNoHow different one pixel must be from the pixel beside it, on a scale of 255, to count as an edge. Omit to use the user's setting (10 by default). Lower stops at fainter borders and finds smaller things; raise it for a photograph or video, where every pixel differs a little from the last
interactiveNoHand the user the ruler instead of measuring a given point: they hover, drag, click to copy and press Escape, and the last measurement comes back. The one to use when it is their screen and their judgement of what to measure. Waits up to five minutes
Behavior5/5

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

No annotations are provided, so the description carries full burden. It discloses that the tool takes a still at call start (so animating screens are measured as of that moment), requires macOS Screen Recording permission and fails without it, returns two independent runs not an outline, and explains edge detection behavior (tolerance, large flat backgrounds). It also notes the interactive mode waits up to five minutes. This is comprehensive behavioral disclosure.

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?

The description is long but every sentence adds value. It is front-loaded with the core purpose, then usage guidance, then behavioral details, then parameter semantics. While it could be slightly more concise, the density of useful information justifies the length. No filler or repetition.

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?

Given the tool's complexity (6 parameters, 3 modes, nested objects, no output schema), the description is remarkably complete. It explains the return structure (points, pixels, fraction, scale, text, distance), the difference between points and pixels on Retina, the coordinate system, edge detection behavior, permission requirements, and timing semantics. It also covers all three usage modes and their appropriate contexts. The absence of an output schema makes this description essential, and it delivers.

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 description coverage is 100%, so baseline is 3. The description adds significant value beyond the schema: it explains the coordinate system (fractions 0..1, origin top-left, same as apply_layout), the meaning of 'point' vs 'from'/'to' vs 'interactive', and the tolerance parameter's effect (lower stops at fainter borders, raise for photos/videos). It also clarifies the 'screen' parameter's default and relationship to get_state. This exceeds the baseline.

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?

The description clearly states the tool measures screen dimensions in points and pixels without taking a picture, and explicitly distinguishes it from take_screenshot and extract_text. It specifies the verb (measure), resource (screen), and scope (runs from a point in four directions), making it distinct from siblings.

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?

The description provides explicit when-to-use guidance: 'Prefer this over take_screenshot whenever the answer is a number' and names alternatives: 'Use extract_text when the answer is words, and take_screenshot when it is what does this look like'. It also explains the three modes (point, from/to, interactive) and when to use each, including the interactive mode for user judgment.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ostapondo/Plonk'

If you have feedback or need assistance with the MCP directory API, please join our Discord server