easy-ui-mcp

Overview Schema Source Related Servers Discussions Admin

ui_upload_file

ui_upload_file

Uploads the built-in default_draft.png test file to the file input or file-chooser trigger matching a CSS selector, enabling browser upload testing.

Instructions

Upload the built-in test file default_draft.png (a tiny PNG) to the single element matching the selector: an input[type=file] (hidden ones work), or a button/label whose click opens the file chooser. Takes no path: this is the only file it can ever upload. If the input's accept excludes images the response says so. Selectors containing "nth=" are positional: call ui_get_page_state again after the page changes before reusing them.

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": {
      "selector": "<selector>"
    },
    "name": "ui_upload_file"
  }
}

Input Schema

Name	Required	Description	Default
`selector`	Yes	CSS selector, or the `selector` value of an element from ui_get_page_state, passed unchanged
`session_id`	No	Which open session to act on, as returned by ui_start_session. Optional with one open session; required when several are open.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 10, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations to lean on, the description still discloses the key behaviors: exactly one file is ever uploaded, no path is accepted, hidden inputs are handled, and an accept mismatch is surfaced in the response. The stale-positional-selector warning adds operational context an agent could not infer from the schema.

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 core action and constraint, with no filler. The final sentence on positional selectors is edge-case detail but is short and actionable rather than padding.

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 two-parameter tool with full schema coverage and no output schema, the description covers target types, the fixed file, failure signaling via the accept case, and selector reuse hazards. The only gap is what a successful response looks like beyond the accept-mismatch note.

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 baseline is 3, but the description adds real meaning by clarifying that the selector may be raw CSS or the value returned by ui_get_page_state passed unchanged, and by explaining positional 'nth=' selector lifetime. Session handling is left to the schema, which 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?

The description names a specific verb (upload), a specific artifact (the built-in default_draft.png test file), and the exact target element types (input[type=file], or a button/label that opens a file chooser). That precision cleanly separates it from fill/type/click siblings without needing to name them.

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 states the conditions under which the tool applies (file input, hidden inputs, or chooser-opening button/label) and explicitly rules out a path argument. The re-fetch guidance for positional 'nth=' selectors is a concrete when-to-do-something-else rule, though it never names an alternative tool for non-file interactions.

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