real-browser-mcp

Overview Schema Source Related Servers Discussions Admin

browser_upload_file

Upload local files to a web page's file input by giving a file path and optional snapshot ref or CSS selector, or auto-detect the first file input; works on strict-CSP pages.

Instructions

Upload a file through a file input element. Uses CDP DOM.setFileInputFiles — works even on strict-CSP pages. Provide the local file path and either a ref from snapshot, a CSS selector targeting the file input, or omit both to auto-find the first input[type="file"].

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "browser_upload_file"
  }
}

Input Schema

Name	Required	Description
`ref`	No	Element reference from snapshot (e.g. "e12")
`files`	No	Array of local file paths to upload (multiple files)
`filePath`	No	Local file path to upload (single file)
`selector`	No	CSS selector for the file input element

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.3.0Oct 19, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does disclose a non-obvious trait: it works via CDP and therefore functions on strict-CSP pages, which is real behavioral context beyond the schema. It remains silent on post-upload behavior (change/input events firing, validation failures, or errors when no file input exists).

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?

Three sentences, front-loaded with the action and mechanism, with no filler. The final targeting sentence is slightly tangled to parse but every clause carries information.

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 a 4-optional-parameter action with no output schema and no annotations, the description covers mechanism, CSP behavior, and all three targeting modes. The only real gap is the files/filePath relationship and failure behavior when no file input is found.

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 baseline is 3. The description adds the targeting precedence (ref vs selector vs auto-find) but does not clarify the distinction between 'files' (multiple) and 'filePath' (single), or what happens if both are supplied.

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?

States a specific verb and resource ('Upload a file through a file input element') and immediately names the mechanism (CDP DOM.setFileInputFiles), which separates it from generic siblings like browser_click or browser_fill_form. An agent can tell exactly which task this tool owns.

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 concrete targeting guidance: use a snapshot ref, a CSS selector, or omit both to auto-find the first input[type="file"]. This is clear context for invocation, though it never explicitly contrasts with a named sibling or states when not to use it.

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