Reads data from Google Sheets to auto-fill web forms.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@form-auto-mcp Fill the internal form using the attached Excel file"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for Claude Desktop that automates internal system form submissions using Playwright.
Read data from Excel/CSV or Google Sheets and auto-fill forms
Automated menu navigation (menu text click → page transition)
Label/ID/Placeholder-based form field matching
Visible mode (browser shown) / Fast mode (background) toggle
Result report with success/failure counts + screenshots on failure
Related MCP server: UI Test Gen MCP Server
Node.js 18+
Add to claude_desktop_config.json:
Mac: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"form-automation": {
"command": "npx",
"args": ["form-auto-mcp"]
}
}
}Restart Claude Desktop. That's it — no clone, no build needed.
Create a .env file:
GOOGLE_API_KEY=your_api_keyIn Claude Desktop, provide a site URL and attach an Excel file:
"https://your-site.com 에 이 엑셀로 폼 입력해줘" (attach file)
"https://your-site.com 에 이 구글 시트로 폼 입력해줘: [sheet URL]"
"빠르게 폼 입력해줘"
Everything is controlled from the Excel file — menu path, form fields, and save button.
메뉴경로 | field1 | field2 | ... | 저장버튼 |
MenuA > SubMenuB | Value1 | Value2 | ... | Submit |
메뉴경로 (first column): menu path to click, separated by >
Form fields (middle columns): column name = form label, ID, or placeholder on screen
저장버튼 (last column): text of the save/submit button to click
See templates/test-demoqa.xlsx for a sample
A sample Excel for demoqa.com is included so you can try the automation right away.
From Claude Desktop:
"https://demoqa.com/elements 에 templates/test-demoqa.xlsx 파일로 폼 입력해줘"
Or from terminal (for developers):
git clone https://github.com/jayounglee92/form-auto-mcp.git
cd form-auto-mcp
npm install
npm run build
node test-run.mjsA browser window will open and fill out the Text Box form 3 times in a row.
MIT
엑셀 또는 Google Sheets 데이터를 읽어 내부 시스템 폼을 자동으로 입력합니다. 엑셀에 메뉴경로, 폼 필드, 저장버튼 텍스트가 모두 포함되어 있습니다.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | 실행 모드: visible(브라우저 표시) | fast(백그라운드) | visible |
| site_url | Yes | 접속할 사이트 URL | |
| file_path | No | 엑셀/CSV 파일 경로 (source_type이 excel일 때) | |
| sheet_url | No | Google Sheets URL (source_type이 google_sheets일 때) | |
| source_type | Yes | 데이터 소스 유형 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does not disclose whether the tool actually submits the form or just fills fields, despite mentioning 'save button text' in the source data. It also omits any side effects, authentication requirements, or safety implications. The description implies a mutating action but lacks explicit behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, with the first stating the core purpose and the second adding useful context about the data structure. There is no filler or redundant repetition of the schema. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is an automation tool with potential side effects, yet the description fails to explain the full workflow: what happens after form filling, whether it saves, what the output or result is, or any prerequisites. The schema covers parameters well, but behavioral and flow details are missing. For a tool that modifies system state, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents every parameter. The description adds minimal extra value, only explaining that the Excel file contains menu routes, form fields, and save button text, which is contextual but not directly about parameters. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads Excel or Google Sheets data and automatically fills internal system forms. The verb 'automatically inputs' and the resources (Excel/Google Sheets, system form) make the purpose specific and unambiguous. With no sibling tools, differentiation is not needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context: it is used for automating form entry from spreadsheet data. No exclusions or alternatives are needed because there are no sibling tools, which is acceptable. The context is clear enough for an agent to infer when this tool would be relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.2run-workflowScored across 1 tool
With only one tool, there is no possibility of confusion. The tool's purpose is clearly defined as running a data-driven form workflow, so an agent can accurately select it without ambiguity.
The tool name 'run-workflow' follows a clean verb-noun pattern, which is consistent and readable. Since there is only one tool, no naming conflicts or stylistic inconsistencies exist.
A single tool feels thin for the stated purpose of form automation, which could encompass a broader set of operations. The count is borderline but not extreme, as the tool covers the core workflow directly.
The tool addresses the primary task of reading data and filling forms, but there are notable gaps such as listing workflows, checking status, or handling configuration. For a more comprehensive form automation server, additional tools would be expected.
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
Give AI agents access to form submissions — read, search, update, and process file attachments.
Detect, review and fill existing PDF forms from JSON or Excel; reuse saved templates
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
