Skip to main content
Glama
xav-ie

Browser Session MCP

by xav-ie
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

type

Destructive

Types text into an input, textarea, or contenteditable element matched by CSS selector, firing real key events so page input handlers run. Optionally clears the field first and paces keystrokes.

Instructions

Type text into the first element matching a CSS selector in the session's active tab: waits up to timeout for it, clicks it to focus, then sends real key events for each character, so the page's input handlers fire. Use press_key afterwards for Enter or Tab, and press_key alone for single keys. clear empties the field first; without it, text is appended. delay paces the characters for pages that react to typing speed. It doesn't check that the element is editable: typing into a button or plain text reports success but changes nothing, so target an input, textarea or contenteditable element. Returns how many characters were typed. Fails if the selector matches nothing within timeout.

Input Schema

NameRequiredDescriptionDefault
textYesThe text to type.
clearNoEmpty the field's current value before typing. Default false, which appends.
delayNoMilliseconds to pause after each character, for pages that react to typing speed. Default 0.
timeoutNoMilliseconds to wait for `selector` to appear. Default 5000.
selectorYesCSS selector of the input, textarea or editable element.
sessionIdYesThe id returned by open_browser_session. Errors if no open session has it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / clear / description
      Added value: +"Empty the field's current value before typing. Default false, which appends."
    • addedInput schema / properties / delay / description
      Added value: +"Milliseconds to pause after each character, for pages that react to typing speed. Default 0."
    • addedInput schema / properties / selector / description
      Added value: +"CSS selector of the input, textarea or editable element."
    • addedInput schema / properties / sessionId / description
      Added value: +"The id returned by open_browser_session. Errors if no open session has it."
    • addedInput schema / properties / text / description
      Added value: +"The text to type."
    • addedInput schema / properties / timeout
      Added value: +{
+  "description": "Milliseconds to wait for `selector` to appear. Default 5000.",
+  "minimum": 1,
+  "type": "integer"
+}
  2. First observedv0.1.2

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations (destructive/openWorld/non-idempotent) by disclosing the wait-then-click-to-focus sequence, real key event dispatch so page handlers fire, and the failure mode of a non-matching selector. The most valuable disclosure is the silent no-op on non-editable targets — success reported but nothing changed — which no annotation conveys.

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?

Front-loaded with the core action and mechanism, then usage routing and caveats. It is a single dense paragraph with no filler sentences, though the caveat about non-editable elements could be its own sentence for scanability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description compensates by stating the return value (number of characters typed) and the failure condition. For a 6-parameter mutation tool, the description covers what an agent needs to call it correctly and interpret the result.

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 behavioral meaning the schema does not: timeout governs both waiting for the element and the failure condition, clear vs append semantics, and delay exists for speed-sensitive pages. It stops short of adding format details for selector/sessionId, which the schema already covers.

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 target (type text into the first element matching a CSS selector in the active tab) and explains the mechanism (focus click + real key events). It is clearly distinguished from press_key, which it names as the tool for single keys and Enter/Tab.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing: use press_key afterwards for Enter or Tab, press_key alone for single keys, and target an input/textarea/contenteditable rather than a button. The clear-vs-append choice and the delay option are both framed by when you'd want them.

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