Skip to main content
Glama

upload_file

Attach a local file to a browser file input without opening the OS file picker; target hidden inputs and submit after upload.

Instructions

Attach a local file to a file input () without opening the operating system's file picker. Waits for the input to exist; it may be hidden, as styled upload buttons often hide the real input, so target the input itself. The file must exist on the machine running this server. After attaching, click the page's upload or submit button if it has one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filePathYesAbsolute path to the file on the machine running this server, e.g. '/home/me/report.pdf' or 'C:/Users/me/report.pdf'.
selectorYesHow to find the element, e.g. { by: 'css', value: '#login-button' } or { by: 'id', value: 'user-name' }. Prefer id, name, or a short CSS selector.
timeoutMsNoHow long to wait for the file input to exist, in milliseconds (default 10000).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.3.0
    • addedInput schema / properties / filePath / description
      Added value: +"Absolute path to the file on the machine running this server, e.g. '/home/me/report.pdf' or 'C:/Users/me/report.pdf'."
    • addedInput schema / properties / selector / description
      Added value: +"How to find the element, e.g. { by: 'css', value: '#login-button' } or { by: 'id', value: 'user-name' }. Prefer id, name, or a short CSS selector."
    • addedInput schema / properties / selector / properties / by / description
      Added value: +"Locator strategy: css, xpath, id, name, class/className, tag/tagName, linkText, or partialLinkText."
    • addedInput schema / properties / selector / properties / value / description
      Added value: +"The locator for that strategy, e.g. '#login-button' for css, 'user-name' for id, or //button[@type=\"submit\"] for xpath."
    • addedInput schema / properties / timeoutMs / description
      Added value: +"How long to wait for the file input to exist, in milliseconds (default 10000)."
  2. First observedv0.1.2

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are provided, so the description must carry the full burden. It does well: explains waiting for input existence, that hidden inputs are common, that the file must exist on the server's machine, and the post-upload click expectation. Doesn't cover whether the attach triggers events or what happens on failure, but covers the behavioral essentials an agent needs.

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?

Four sentences, all earning their place, front-loaded with the action and the picker-avoidance point. No filler or repetition of the name.

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 3-param nested-schema tool with no output schema and no annotations, the description covers the core workflow and edge cases (hidden input, server-side file, follow-up click). Missing a note on return value/errors and any permission or security context, but broadly complete for the browser-automation domain.

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% with rich parameter docs (selector object, filePath examples, timeoutMs default/range). The description adds the server-side file location fact ('on the machine running this server'), reinforcing filePath semantics, but otherwise the schema fully documents parameters. Baseline 3 is appropriate.

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+resource: attach a local file to a file input. Distinguishes from sibling 'type' or 'click' by clarifying it bypasses the OS file picker and targets the hidden input directly, which is the key differentiator for upload tools.

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 context on when to use (attach without picker) and what to do afterward ('click the page's upload or submit button if it has one'), plus the constraint 'the file must exist on the machine running this server'. No explicit when-not guidance or named alternatives, but strong for the category.

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