Skip to main content
Glama

upload_image

Uploads an image to a web page by targeting a file input element or simulating a drag-and-drop at a specified viewport coordinate.

Instructions

Feeds a picture the session is already holding - a screenshot or zoom taken with the computer tool, which prints an imageId such as img_3 - into a page, so no file has to travel through you. There are two ways to aim it and you must pick exactly one: ref, an element from read_page or find, which is how you reach a file input the page keeps hidden behind styling; or coordinate, an [x, y] point in the viewport, for editors that take a dropped file and expose no input at all. Giving both is an error and so is giving neither; imageId and tabId are always needed. Down the ref path the image is written to a scratch file in this session's download folder and handed to the input, and should that element turn out not to be a file input, the tool scrolls to it and drops the image on it instead. Down the coordinate path whatever sits under the point gets a synthesized dragenter, dragover and drop, plus a paste event as a fallback when none of the three was taken up. Read the result line: it names which of drop, paste or nothing the page actually handled, so a target that quietly ignored the image cannot pass for success.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
refNoAn element id from read_page or find, in the form ref_9. Reach for it whenever the target can be named - above all a file input the page hides - rather than aiming at pixels. Cannot be combined with coordinate, and goes stale as soon as the page navigates or re-renders.
tabIdYesThe tab that is to receive the image; always required. tabs_context_mcp lists the ids of this session's tabs if you do not have one.
imageIdYesThe id reported when the picture was captured by the computer tool (its screenshot or zoom action), for instance img_3; an image the user supplied carries one too. Only the 20 most recent survive in the session, so an id from much earlier may already be gone.
filenameNoThe name the page should see, image.png when you leave it out. A directory part is stripped off, and a bare name with no suffix gains .png, or .jpg when the capture is a JPEG.
coordinateNoA point [x, y] in viewport pixels, for a visible region that accepts dropped files without exposing an input. Take the numbers off the newest screenshot; a scroll or a layout shift since then has moved the target out from under them. Cannot be combined with ref.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A5/5.0
Behavior5/5

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

With no annotations provided, the description carries full behavioral transparency. It discloses side effects in detail: writing a scratch file, scrolling and falling back to drop for non-input elements, synthesizing drag/drop/paste events, and reporting which mechanism the page actually handled via the result line.

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?

Every sentence supplies necessary operational detail with no filler. The single paragraph flows logically from purpose to constraints, per-path behavior, and result interpretation, making it dense yet well organized.

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 five parameters, conditional exclusivity, fallback behaviors, and a result contract, the description is complete. It tells the agent how to obtain ids, what to expect on errors, and how to validate success via the result line, leaving no operational gap.

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?

The schema descriptions already cover all five parameters, and the prose adds critical semantics beyond them: imageId freshness ('Only the 20 most recent survive'), filename defaulting and sanitization ('directory part stripped', '.png' added), ref staleness after navigation, and coordinate invalidation after scroll or layout shift.

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 states the tool's purpose precisely: 'Feeds a picture the session is already holding ... into a page'. It distinguishes the action from sibling tools by referencing the computer tool for capture and read_page/find for element references, making the verb and resource unmistakable.

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?

It explicitly contrasts the two targeting paths (ref vs coordinate), states when each is appropriate ('above all a file input the page hides' vs 'a visible region that accepts dropped files without exposing an input'), and notes constraints like 'Giving both is an error and so is giving neither'. It also points to sibling tools (tabs_context_mcp, read_page, find) for obtaining required ids.

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