MCP Screenshot Server

add_arrow

Draw an arrow on a screenshot to highlight a specific region or direction, with customizable start/end points, color, line width, and head size.

Instructions

Draw an arrow on the image.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`x1`	Yes	X coordinate of the arrow start
`x2`	Yes	X coordinate of the arrow end (tip)
`y1`	Yes	Y coordinate of the arrow start
`y2`	Yes	Y coordinate of the arrow end (tip)
`color`	No	Color of the arrow	red
`image_id`	Yes	ID of the image to annotate
`head_size`	No	Size of the arrow head
`line_width`	No	Width of the arrow line

Output Schema

TableJSON Schema

Name	Required	Description	Default
`message`	Yes	Status message
`image_id`	Yes	Image ID that was annotated

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 15, 2026

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It does not mention that this modifies the image, whether it's additive (overlay) or destructive, if undo is possible, or what the response contains. It only states the action, leaving the agent to infer side effects. Sibling tools like undo suggest reversibility, but that's not stated.

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?

A single, clear sentence with no filler. It is appropriately concise for a simple operation, though it lacks the nuance that could be packed into a few more words.

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

Completeness2/5

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

Given the 8 parameters, the existence of an output schema, and numerous sibling tools, the description is too minimal. It doesn't explain when to use an arrow versus other annotations, what the effect on the image is, or any required preconditions. The schema covers parameters well, but the high-level context for correct invocation is missing.

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 description coverage is 100%, so the schema already documents all parameters. The description adds no information about parameters. Baseline is 3, and the description neither improves nor worsens the situation.

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?

The description 'Draw an arrow on the image' clearly states the verb (draw) and resource (arrow on image). It is specific enough to distinguish from e.g., add_box or add_text, though it doesn't explicitly call out the arrowhead feature that distinguishes it from add_line.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like add_line or add_box. It doesn't mention use cases, prerequisites, or why an arrow would be preferred. The description simply states the action without context for selection.

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