Skip to main content
Glama

browser_type

Destructive

Type text into web page elements for automated testing or interaction, supporting character-by-character input and form submission options.

Instructions

Type text into editable element

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
elementYesHuman-readable element description used to obtain permission to interact with the element
refYesExact target element reference from the page snapshot
textYesText to type into the element
submitNoWhether to submit entered text (press Enter after)
slowlyNoWhether to type one character at a time. Useful for triggering key handlers in the page. By default entire text is filled in at once.

Implementation Reference

  • The handler function that executes the browser_type tool: locates an element using provided selector or ref, fills or presses sequentially the text (slowly if specified), and optionally submits with Enter key.
    handle: async (tab, params, response) => {
      const locator = await tab.refLocator(params);
    
      await tab.waitForCompletion(async () => {
        if (params.slowly) {
          response.setIncludeSnapshot();
          response.addCode(`await page.${await generateLocator(locator)}.pressSequentially(${javascript.quote(params.text)});`);
          await locator.pressSequentially(params.text);
        } else {
          response.addCode(`await page.${await generateLocator(locator)}.fill(${javascript.quote(params.text)});`);
          await locator.fill(params.text);
        }
    
        if (params.submit) {
          response.setIncludeSnapshot();
          response.addCode(`await page.${await generateLocator(locator)}.press('Enter');`);
          await locator.press('Enter');
        }
      });
    },
  • Schema definition for the browser_type tool, extending elementSchema with text (required), submit, and slowly options. Specifies name, title, description, and marks as destructive.
    const typeSchema = elementSchema.extend({
      text: z.string().describe('Text to type into the element'),
      submit: z.boolean().optional().describe('Whether to submit entered text (press Enter after)'),
      slowly: z.boolean().optional().describe('Whether to type one character at a time. Useful for triggering key handlers in the page. By default entire text is filled in at once.'),
    });
    
    const type = defineTabTool({
      capability: 'core',
      schema: {
        name: 'browser_type',
        title: 'Type text',
        description: 'Type text into editable element',
        inputSchema: typeSchema,
        type: 'destructive',
      },
  • src/tools.ts:36-52 (registration)
    Registration of all tools into allTools array by spreading exports from individual tool modules, including keyboard (line 43: ...keyboard) which exports the browser_type tool. This array is used by BrowserServerBackend.tools() via filteredTools.
    export const allTools: Tool<any>[] = [
      ...common,
      ...console,
      ...dialogs,
      ...evaluate,
      ...files,
      ...install,
      ...keyboard,
      ...navigate,
      ...network,
      ...mouse,
      ...pdf,
      ...screenshot,
      ...snapshot,
      ...tabs,
      ...wait,
    ];
Behavior4/5

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

Annotations indicate destructiveHint=true (mutation) and openWorldHint=true (unpredictable environment), but the description adds valuable context: it specifies this is for 'editable element' interaction, implying text fields or areas where user input is expected. This clarifies the scope beyond what annotations provide, though it doesn't mention potential side effects like form submission triggers.

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?

The description is a single, focused sentence with zero wasted words. It's front-loaded with the core action ('Type text') and immediately specifies the target ('into editable element'), making it highly efficient and scannable.

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

Completeness3/5

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

For a destructive tool (per annotations) with 5 parameters and no output schema, the description is minimally adequate. It identifies the action and target but lacks details about error conditions, what constitutes an 'editable element', or the visual/state changes expected after typing. The annotations help, but more behavioral context would improve completeness.

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?

With 100% schema description coverage, all parameters are documented in the schema. The description doesn't add any parameter-specific information beyond the schema's details about element, ref, text, submit, and slowly. The baseline of 3 is appropriate since the schema carries the full parameter documentation burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Type text into editable element' clearly states the verb ('Type') and target ('editable element'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like browser_press_key or browser_select_option, which also involve text input interactions in different contexts.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when browser_type is appropriate compared to browser_press_key (for single keys/commands) or browser_select_option (for dropdown selections), nor does it specify prerequisites like needing a page snapshot or element reference from browser_snapshot.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/maywzh/playwright-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server