Skip to main content
Glama
Sign In
Computer Use

Computer Use

by munimtechnologies
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Type in browser

browser_type
Destructive

Types text at the caret in the focused field of an agent browser tab, inserting without clearing existing content; click the field first and use browser_fill to replace the whole value.

Instructions

Type text into the field that currently has focus in one of the agent's tabs; browser_click the field first. Text is inserted at the caret without clearing existing content: to replace a field's whole value use browser_fill. Use browser_press_key for Enter, Tab, Backspace, arrows and shortcuts such as Cmd+A, and type_text for native apps. Never use the desktop press_key or type_text for a Chrome tab: those go to whichever Chrome window is in front, which can be the user's.

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": {
      "tab_id": "<tab_id>",
      "text": "<text>"
    },
    "name": "browser_type"
  }
}

Input Schema

NameRequiredDescriptionDefault
textYesExact text to type into the focused field
tab_idYestab_id of one of the agent's tabs, from browser_open_tab or browser_list_tabs
session_idNoStable task or thread ID. Pass the same value on every browser call for this task. Different IDs isolate tabs and cleanup within one MCP process. Omit for the default process session.
return_stateNoAppend a current snapshot and readiness status after acting. Without wait_for_selector, only a short pause and bounded navigation wait are used; SPA readiness is not guaranteed. Snapshot indices replace earlier ones. A timeout does not mean the action failed: re-observe with browser_snapshot before repeating it.
wait_timeout_msNoBound for wait_for_selector in milliseconds (default 8000, maximum 10000; 0 checks once). Requires wait_for_selector. Timeout preserves action success and returns current state. Use browser_snapshot with the same wait to re-observe without repeating an action.
wait_for_selectorNoWait for any visible element matching this CSS selector in the page, including open shadow roots (web components); child frames are not searched, and a timeout says how many were visible. On actions requires return_state=true. Returns readiness met, timeout or error; only this condition is checked, not general app readiness. Prefer a selector specific to the expected new UI.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.11.2
    • changedInput schema / properties / wait_for_selector / description
      Previous value: -"Wait for any visible element matching this CSS selector in the top-level document (not frames or shadow roots). On actions requires return_state=true. Returns readiness met, timeout or error; only this condition is checked, not general app readiness. Prefer a selector specific to the expected new UI."New value: +"Wait for any visible element matching this CSS selector in the page, including open shadow roots (web components); child frames are not searched, and a timeout says how many were visible. On actions requires return_state=true. Returns readiness met, timeout or error; only this condition is checked, not general app readiness. Prefer a selector specific to the expected new UI."
  2. Changed3 schema fields changedv0.7.1
    • changedInput schema / properties / return_state / description
      Previous value: -"After acting, wait for the page to settle (and finish loading, if the action navigated) and append a fresh browser_snapshot of this tab, so you can pick the next index in the same call. Its indices replace earlier ones."New value: +"Append a current snapshot and readiness status after acting. Without wait_for_selector, only a short pause and bounded navigation wait are used; SPA readiness is not guaranteed. Snapshot indices replace earlier ones. A timeout does not mean the action failed: re-observe with browser_snapshot before repeating it."
    • addedInput schema / properties / wait_for_selector
      Added value: +{
+  "description": "Wait for any visible element matching this CSS selector in the top-level document (not frames or shadow roots). On actions requires return_state=true. Returns readiness met, timeout or error; only this condition is checked, not general app readiness. Prefer a selector specific to the expected new UI.",
+  "maxLength": 2000,
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / wait_timeout_ms
      Added value: +{
+  "description": "Bound for wait_for_selector in milliseconds (default 8000, maximum 10000; 0 checks once). Requires wait_for_selector. Timeout preserves action success and returns current state. Use browser_snapshot with the same wait to re-observe without repeating an action.",
+  "maximum": 10000,
+  "minimum": 0,
+  "type": "integer"
+}
  3. Changed1 schema field changedv0.5.2
    • addedInput schema / properties / return_state
      Added value: +{
+  "description": "After acting, wait for the page to settle (and finish loading, if the action navigated) and append a fresh browser_snapshot of this tab, so you can pick the next index in the same call. Its indices replace earlier ones.",
+  "type": "boolean"
+}
  4. Changed1 schema field changedv0.4.3
    • addedInput schema / properties / session_id
      Added value: +{
+  "description": "Stable task or thread ID. Pass the same value on every browser call for this task. Different IDs isolate tabs and cleanup within one MCP process. Omit for the default process session.",
+  "maxLength": 128,
+  "minLength": 1,
+  "type": "string"
+}
  5. Changed2 schema fields changedv0.3.1
    • addedInput schema / properties / tab_id / description
      Added value: +"tab_id of one of the agent's tabs, from browser_open_tab or browser_list_tabs"
    • addedInput schema / properties / text / description
      Added value: +"Exact text to type into the focused field"
  6. First observedv0.3.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations only declare the safety profile (readOnlyHint=false, destructiveHint=true, idempotentHint=false); the description adds the behavior that actually matters — text is inserted at the caret and does not clear existing content, so repeated calls accumulate rather than replace. It also discloses the focus dependency and the cross-tool hazard of hitting the user's foreground window. It stops short of describing the action's response, which is left to the return_state parameter.

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 the insert-vs-replace distinction, then the routing rules. Dense but every clause carries decision-relevant information; the closing warning is long but justifies itself by preventing a real misfire into the user's own window.

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 six-parameter mutation tool with no output schema, the description covers purpose, preconditions, side-effect semantics and alternatives, and the schema fully documents the remaining parameters including re-observation on timeout. What is missing is a statement of what a successful type action returns when return_state is false, a minor gap given the parameter-level documentation.

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%, including tab_id sourcing, session_id isolation and the wait_for_selector/return_state pairing, so the schema already carries parameter meaning. The description adds only the implicit notion of a focused field within a tab and does not explain tab_id, session_id or the wait parameters at all — 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 and resource with scope: 'Type text into the field that currently has focus in one of the agent's tabs'. It immediately distinguishes itself from browser_fill (replace whole value), browser_press_key (Enter/Tab/shortcuts) and type_text (native apps), so an agent can pick the right tool without opening any schema.

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?

Gives an explicit precondition ('browser_click the field first'), names the correct alternative for the replace case, and routes special keys and non-browser targets to their own tools. It also carries a hard exclusion: never use desktop press_key/type_text for a Chrome tab, with the reason (wrong window can be the user's).

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