Skip to main content
Glama
Sign In
sandboxed-browser-mcp

sandboxed-browser-mcp

by smkamranqadri
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Upload

browser_upload

Attach local files to a browser file input using its ref, label, or chooser button instead of clicking. Reports each attached file and the visible page changes.

Instructions

Attaches files from this machine to a file input by ref: the input, its label, or the button that opens its file chooser. Use it instead of clicking a file input. Paths are absolute or ~/, inside the server's home; credential, key, history and browser-profile files are refused. Reports each file attached and the changes on screen.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ref": "<ref>",
      "files": "<files>"
    },
    "name": "browser_upload"
  }
}

Input Schema

NameRequiredDescriptionDefault
refYesRef of the file input, its label, or the button that opens its file chooser (e12, f2e7 …), as browser_snapshot or browser_find showed it.
filesYesThe files to attach, as paths on this machine inside the server's home: absolute, or starting with ~/.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=false and openWorldHint=true; the description adds substantive behavior beyond that: path must be inside the server's home, credential/key/history/browser-profile files are refused, and the tool reports attached files and on-screen changes. It does not detail failure modes for invalid refs, but the safety and output behavior are unusually well disclosed.

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?

Front-loads the action and target, then packs usage guidance, path constraints, security refusals, and reporting behavior into three tight sentences with no filler.

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?

With no output schema, the description still explains what gets reported back, and it covers the critical path and security constraints. It is complete enough to call correctly, though it omits what happens when a ref is stale or a file 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 coverage is 100%, so both parameters are already documented. The description restates that ref may be the input, its label, or the button that opens the chooser, and that files are absolute or ~/ inside the home, but adds little beyond the schema text.

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 (attaches files) and resource (a file input identified by ref), and explicitly distinguishes the approach from clicking a file input. An agent can identify the tool's job without opening the schema.

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 a clear directive: 'Use it instead of clicking a file input,' which resolves the main ambiguity against browser_click. It does not spell out exclusions or failure cases, but the primary alternative is named.

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

Deploy Server

Other Tools