Skip to main content
Glama

browser_drop_file

Handing a file to the page needs "Allow access to file URLs" for the Agent360 Browser MCP extension (off by default for Chrome Web Store installs); that switch also lets the extension open any local file as a page, so whether to turn it on…

Instructions

Handing a file to the page needs "Allow access to file URLs" for the Agent360 Browser MCP extension (off by default for Chrome Web Store installs); that switch also lets the extension open any local file as a page, so whether to turn it on is the user's call. A "Not allowed" error from the handoff is reported as file-access-off unless Chrome confirms that file access is on. Upload a file when browser_upload_file fails. Two strategies: (1) uses the target itself when it is a file input, or a hidden inside it; (2) if there is none, clicks the target and intercepts the NATIVE OS file-chooser it opens - pass the selector of the button that opens the dialog, and the file is supplied programmatically without the dialog ever appearing. Other file inputs on the page do not get the file: when neither strategy works, the error lists them in other_file_inputs, each with a selector to pass if it is the right field - a CSS selector that matched that input alone when the tool looked (built from its id, its name or its position on the page), or null when none did, for instance for an input inside a shadow root. The answer describes the input that got the file in input. If the field is empty afterwards although the page's change handler saw the file in it, the answer is ok with cleared_by_page: true and seen_in_field - X and Facebook empty the field after reading the file, and a page that rejects the file can do the same, so check the page before attaching again. Files must be regular files inside the working directory the MCP server runs in - folders, symlinks and hardlinks that point outside it are refused.

Input Schema

NameRequiredDescriptionDefault
fileNoSingle absolute file path. Alias: `file_path`.
filesNoArray of absolute file paths
selectorYesCSS selector for the drop-zone target element (e.g. ".upload-area")

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.28.0
    • changedInput schema / properties / file / description
      Previous value: -"Single absolute file path"New value: +"Single absolute file path. Alias: `file_path`."
  2. First observedv1.0.0

TDQS

A4.1/5.0
Behavior5/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 so richly: it discloses the file-access prerequisite, the 'Not allowed' -> file-access-off error mapping, two distinct internal strategies (direct file input vs. intercepting the native OS chooser), and filesystem constraints (regular files inside the working directory; folders/symlinks/hardlinks pointing outside refused). This is unusually complete behavioral disclosure.

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

Conciseness3/5

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

Every sentence is substantive, but the text is a dense wall of long sentences with embedded parentheticals, and it is front-loaded with a prerequisite rather than the purpose. An agent gets the content but pays a high reading cost and must assemble the purpose itself.

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 does the job of describing returns and error payloads (input, cleared_by_page, seen_in_field, other_file_inputs, file-access-off). It is complete for a complex, multi-strategy tool, though the file vs. files parameters and the exact shape of the success response remain only implicitly covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema documents file/files/selector; the description still adds real meaning by explaining that selector points at the drop-zone target in strategy 1 but at the button that opens the dialog in strategy 2, and by tying the file argument to the working-directory constraint. It does not clarify the file vs. files (alias) distinction, keeping it below 5.

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 conveys that the tool hands a file to a page and explicitly routes relative to browser_upload_file ("Upload a file when browser_upload_file fails"), so the verb+resource is clear. However, no single crisp purpose sentence leads the text — the opening sentence is a prerequisite about the 'Allow access to file URLs' switch, so an agent must infer the core purpose from later fragments.

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?

It names the alternative explicitly ("Upload a file when browser_upload_file fails") and gives the selecting condition, plus a prerequisite (the file-URLs switch) and a re-attach caution after cleared_by_page. It stops short of stating when NOT to use it or why the sibling would fail, so the guidance is clear but not fully exhaustive.

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