Skip to main content
Glama
Gwakko

agent-in-browser

by Gwakko
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

type

Enter text into inputs, textareas, or contenteditable elements using real keyboard events; focus and clear a target field or use current focus, and optionally press Enter to submit.

Instructions

Type text into an input, textarea or contenteditable using real keyboard input events. If an element is given (ref, selector or match) it is focused and, by default, cleared first; otherwise the text goes to the element that already has focus. submit=true presses Enter afterwards and, if that navigates, reports the new page. Returns the number of characters typed. To set several fields, selects or checkboxes in one call use fill_form; for non-text keys such as Tab or Escape use press_key.

Input Schema

NameRequiredDescriptionDefault
refNoElement ref from the latest snapshot or find, e.g. "e12". Preferred: unambiguous and fastest; stale after navigation.
tabNoTab id from tabs_list. Defaults to the current tab.
textYesText to type, inserted as typed input.
clearNoClear the field before typing (default true when an element is given; set false to append).
matchNoVisible text or accessible name to match (case-insensitive substring), e.g. "Sign up"; use when you have no ref.
submitNoPress Enter after typing, e.g. to submit a search box (default false).
selectorNoCSS selector; the first matching element is used.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.1.2
    • changedInput schema / properties / clear / description
      Previous value: -"Clear the field first (default true when an element is given)."New value: +"Clear the field before typing (default true when an element is given; set false to append)."
    • changedInput schema / properties / match / description
      Previous value: -"Visible text / accessible name to match (case-insensitive substring)."New value: +"Visible text or accessible name to match (case-insensitive substring), e.g. \"Sign up\"; use when you have no ref."
    • changedInput schema / properties / ref / description
      Previous value: -"Element ref from snapshot/find, e.g. \"e12\". Preferred."New value: +"Element ref from the latest snapshot or find, e.g. \"e12\". Preferred: unambiguous and fastest; stale after navigation."
    • changedInput schema / properties / selector / description
      Previous value: -"CSS selector (first match)."New value: +"CSS selector; the first matching element is used."
    • changedInput schema / properties / submit / description
      Previous value: -"Press Enter after typing."New value: +"Press Enter after typing, e.g. to submit a search box (default false)."
    • changedInput schema / properties / text / description
      Previous value: -"Text to type."New value: +"Text to type, inserted as typed input."
  2. First observedv0.1.1

TDQS

A4.5/5.0
Behavior4/5

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

Adds real behavior beyond annotations: focusing the element, clearing by default first, submit=true pressing Enter and reporting the new page if navigation occurs, and returning the character count. It does not mention failure modes (e.g. what happens if no element matches the selector or the ref is stale) — the schema hints refs go stale, but the description doesn't address it.

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, then defaults, then return value, then sibling routing — a sensible order in a single tight paragraph. Slightly dense, but no sentence is waste.

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?

No output schema exists, and the description does state the return value (characters typed), so that gap is covered. For an open-world, mutating browser tool, more on error/no-match behavior would complete it, but everything needed to call it correctly is present.

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; the description earns above baseline by stating the default clear-on-focus/append semantics, the ref-vs-selector-vs-match precedence, and the submit behavior. It does not add format details for text or tab beyond what the schema already carries.

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 input/textarea/contenteditable) and immediately distinguishes the mechanism (real keyboard input events) from a value-setting operation. The named alternatives (fill_form, press_key) make its scope unambiguous relative to siblings.

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?

Explicitly routes to fill_form for multiple fields/selects/checkboxes and to press_key for non-text keys like Tab or Escape, and explains the no-element case (types into the focused element). An agent can pick the right tool without opening other schemas.

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