Skip to main content
Glama

fill_form

Automate form completion for login, registration, or search by filling multiple fields sequentially with optional Enter key presses and submit button clicks.

Instructions

Fill out one or multiple form fields in sequence, perfect for login forms, registration, search inputs, or any text entry. Supports pressing Enter after each field and clicking a submit button. Commonly used for authentication flows before accessing chat interfaces. Each field can be filled independently with optional Enter key press.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sessionIdYesSession ID obtained from initialize_session
fieldsYesArray of form field objects to fill in sequence. Each field requires a CSS selector and value. Example: [{selector: 'input[name="email"]', value: 'user@example.com'}, {selector: 'input[type="password"]', value: 'mypassword'}]
submitButtonNoOptional CSS selector for submit button to click after all fields are filled (e.g., 'button[type="submit"]', '#login-button')

Implementation Reference

  • Core implementation of the fill_form tool handler. Fills specified form fields using Playwright's page.fill and page.click methods, handles optional Enter presses and submit button, returns success status with page info.
    export async function fillForm(sessionId, fields, submitButton = null) {
      const session = getSession(sessionId);
      const { page } = session;
    
      try {
        for (const field of fields) {
          const { selector, value, pressEnter = false } = field;
    
          await page.waitForSelector(selector, { timeout: 5000 });
          await page.fill(selector, value);
    
          if (pressEnter) {
            await page.press(selector, "Enter");
            await page.waitForTimeout(1000);
          }
        }
    
        if (submitButton) {
          await page.click(submitButton);
          await page.waitForTimeout(2000);
        }
    
        return {
          success: true,
          sessionId,
          currentUrl: page.url(),
          title: await page.title(),
          message: `Filled ${fields.length} field(s) successfully`,
        };
      } catch (error) {
        throw new Error(`Failed to fill form: ${error.message}`);
      }
    }
  • MCP tool schema definition for 'fill_form' including name, description, and detailed inputSchema with properties for sessionId, fields array (with selector/value/pressEnter), and optional submitButton.
    {
      name: "fill_form",
      description:
        "Fill out one or multiple form fields in sequence, perfect for login forms, registration, search inputs, or any text entry. Supports pressing Enter after each field and clicking a submit button. Commonly used for authentication flows before accessing chat interfaces. Each field can be filled independently with optional Enter key press.",
      inputSchema: {
        type: "object",
        properties: {
          sessionId: {
            type: "string",
            description: "Session ID obtained from initialize_session",
          },
          fields: {
            type: "array",
            description:
              "Array of form field objects to fill in sequence. Each field requires a CSS selector and value. Example: [{selector: 'input[name=\"email\"]', value: 'user@example.com'}, {selector: 'input[type=\"password\"]', value: 'mypassword'}]",
            items: {
              type: "object",
              properties: {
                selector: {
                  type: "string",
                  description:
                    "CSS selector for the input field (e.g., 'input[name=\"username\"]', '#email', '.search-box')",
                },
                value: {
                  type: "string",
                  description: "Text value to enter into the field",
                },
                pressEnter: {
                  type: "boolean",
                  description:
                    "Press Enter key after filling this field to submit or trigger search (default: false)",
                },
              },
              required: ["selector", "value"],
            },
          },
          submitButton: {
            type: "string",
            description:
              "Optional CSS selector for submit button to click after all fields are filled (e.g., 'button[type=\"submit\"]', '#login-button')",
          },
        },
        required: ["sessionId", "fields"],
      },
    },
  • src/index.js:459-474 (registration)
    Registration and dispatch logic in the CallToolRequestSchema handler: validates parameters and calls the fillForm handler function for the 'fill_form' tool.
    case "fill_form": {
      const { sessionId, fields, submitButton } = args;
      if (!sessionId) {
        throw new McpError(
          ErrorCode.InvalidParams,
          "sessionId parameter is required"
        );
      }
      if (!fields || !Array.isArray(fields)) {
        throw new McpError(
          ErrorCode.InvalidParams,
          "fields parameter must be an array"
        );
      }
      result = await fillForm(sessionId, fields, submitButton);
      break;
  • src/index.js:13-26 (registration)
    Import statement registering the fillForm function by importing it into the main MCP server index.js for use in tool handlers.
      takeScreenshot,
      clickElement,
      fillForm,
      switchTab,
      waitForElement,
      navigateToUrl,
      getCurrentPageInfo,
      initializeSession,
      closeSession,
      startNetworkCapture,
      stopNetworkCapture,
      getNetworkCaptureStatus,
      clearNetworkCapture,
    } from "./tools/reverseEngineer.js";
  • Re-export of fillForm from interaction.js, enabling centralized import in src/index.js.
    export { clickElement, fillForm, waitForElement } from "./interaction.js";
Behavior3/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It does describe key behaviors: sequential field filling, optional Enter key press after each field, optional submit button clicking after all fields. However, it doesn't mention error handling, timeout behavior, what happens if selectors don't match, or whether this modifies page state. For a tool with no annotations and 3 parameters, this leaves significant behavioral gaps.

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?

The description is appropriately sized at 3 sentences, front-loading the core purpose. Every sentence adds value: first establishes the main function, second details behavioral capabilities, third provides common use case. There's minimal redundancy, though the 'Each field can be filled independently' phrase slightly overlaps with earlier content about sequential filling.

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 3 parameters with 100% schema coverage but no annotations and no output schema, the description provides adequate but incomplete context. It covers the tool's purpose and basic usage scenarios well, but lacks information about return values, error conditions, performance characteristics, or dependencies on other tools like initialize_session. For a form interaction tool with no structured safety hints, more behavioral context 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?

Schema description coverage is 100%, so the schema already documents all 3 parameters thoroughly. The description adds minimal value beyond the schema: it mentions 'one or multiple form fields' which aligns with the fields array parameter, and 'pressing Enter after each field' which aligns with pressEnter boolean. However, it doesn't provide additional semantic context beyond what's already in the comprehensive schema descriptions.

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?

The description clearly states the tool's purpose with specific verbs ('fill out', 'press Enter', 'click submit') and resources ('form fields', 'login forms', 'registration', 'search inputs', 'text entry'). It distinguishes from siblings like click_element by focusing specifically on form field population rather than general clicking, and from navigate_to_url by handling form interaction rather than page navigation.

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

Usage Guidelines4/5

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

The description provides clear context for when to use this tool ('perfect for login forms, registration, search inputs, or any text entry', 'commonly used for authentication flows before accessing chat interfaces'). It doesn't explicitly state when NOT to use it or name specific alternatives among siblings, but the context strongly implies this is for form filling scenarios rather than other interactions.

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/pyscout/webscout-mcp'

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