Skip to main content
Glama
lewisvoncken

Playwright MCP

by lewisvoncken

browser_type

Destructive

Types text into web page elements during browser automation, supporting character-by-character input and form submission.

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

  • Schema definition for the browser_type tool, including name, title, description, inputSchema (typeSchema), and type.
    schema: {
      name: 'browser_type',
      title: 'Type text',
      description: 'Type text into editable element',
      inputSchema: typeSchema,
      type: 'destructive',
    },
  • Handler implementation for browser_type tool: locates element from snapshot, generates code snippets, and performs fill/pressSequentially/press actions based on slowly and submit params.
    handle: async (context, params) => {
      const snapshot = context.currentTabOrDie().snapshotOrDie();
      const locator = snapshot.refLocator(params);
    
      const code: string[] = [];
      const steps: (() => Promise<void>)[] = [];
    
      if (params.slowly) {
        code.push(`// Press "${params.text}" sequentially into "${params.element}"`);
        code.push(`await page.${await generateLocator(locator)}.pressSequentially(${javascript.quote(params.text)});`);
        steps.push(() => locator.pressSequentially(params.text));
      } else {
        code.push(`// Fill "${params.text}" into "${params.element}"`);
        code.push(`await page.${await generateLocator(locator)}.fill(${javascript.quote(params.text)});`);
        steps.push(() => locator.fill(params.text));
      }
    
      if (params.submit) {
        code.push(`// Submit text`);
        code.push(`await page.${await generateLocator(locator)}.press('Enter');`);
        steps.push(() => locator.press('Enter'));
      }
    
      return {
        code,
        action: () => steps.reduce((acc, step) => acc.then(step), Promise.resolve()),
        captureSnapshot: true,
        waitForNetwork: true,
      };
    },
  • typeSchema definition used as inputSchema for browser_type, extending elementSchema with text, submit, and slowly fields.
    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.'),
    });
  • Export default array of snapshot tools, including the browser_type (as 'type') tool for use in higher-level registration.
    export default [
      snapshot,
      click,
      drag,
      hover,
      type,
      selectOption,
    ];
  • src/tools.ts:36-52 (registration)
    Registration of snapshotTools array spreading ...snapshot (which includes browser_type) along with other tools.
    export const snapshotTools: Tool<any>[] = [
      ...common(true),
      ...console,
      ...dialogs(true),
      ...files(true),
      ...install,
      ...keyboard(true),
      ...navigate(true),
      ...network,
      ...pdf,
      ...screenshot,
      ...snapshot,
      ...tabs(true),
      ...testing,
      ...video,
      ...wait(true),
    ];
Behavior4/5

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

The description adds valuable behavioral context beyond the annotations. While annotations indicate destructiveHint=true (implying mutation) and openWorldHint=true (implying unpredictable environment), the description clarifies this specifically types text into editable elements, which helps the agent understand the scope of the destructive action. No contradiction with annotations exists.

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 perfectly concise at 5 words, front-loading the core action ('Type text') and target ('into editable element') with zero wasted words. Every element earns its place in this minimal but complete statement of purpose.

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?

Given the tool's complexity (destructive browser interaction with 5 parameters) and the absence of an output schema, the description is minimally adequate. It states what the tool does but lacks information about return values, error conditions, or integration with other browser tools. The annotations provide safety context, but more behavioral guidance would be helpful.

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, the schema already documents all 5 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 for high schema coverage without providing extra value.

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 clearly states the action ('Type text') and target ('into editable element'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like browser_fill_form or browser_press_key, which might have overlapping functionality for text input scenarios.

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?

No guidance is provided about when to use this tool versus alternatives. The description doesn't mention when this tool is appropriate compared to browser_fill_form (for forms) or browser_press_key (for keyboard input), 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/lewisvoncken/playwright-mcp'

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