Skip to main content
Glama
aamar-shahzad

MCP Screenshot Server

add_border

Add a customizable border around an image using a specified color and pixel width. Use this to frame screenshots or images for emphasis or annotation.

Instructions

Add a border around the entire image.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
colorNoBorder color#000000
widthNoBorder width in pixels
image_idYesID of the image

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
widthYesImage width in pixels
heightYesImage height in pixels
messageYesStatus message
image_idYesUnique identifier for the captured image

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations present, the description carries the full burden of behavioral disclosure. It only states the action 'add a border' but does not say whether the image is modified in-place, whether a new image is returned, whether the operation is reversible, or if any permissions are required. For a mutating tool, this leaves key behavioral traits undisclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler or redundant information. Every word contributes to understanding the tool's core function.

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?

The description is too sparse for a mutation tool without annotations. It doesn't explain what happens to the original image or what the tool returns, and while an output schema exists, the description itself lacks the behavioral context needed for an agent to invoke it confidently.

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?

The input schema has 100% coverage, with clear descriptions for color, width, and image_id. The description adds no extra parameter meaning, but the schema already provides sufficient detail, so the baseline score of 3 is appropriate.

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 states a clear verb and resource: 'Add a border around the entire image.' The phrase 'entire image' distinguishes it from sibling annotation tools like add_box or add_circle, which typically target local regions. However, it does not explicitly name alternatives or contrast with them, so a small inference is required.

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?

The description gives no explicit guidance on when to use this tool versus its siblings, nor does it mention prerequisites such as loading an image first. The only implied context is the tool's name and purpose, which is insufficient for selecting among the many similar image tools.

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