Click on "Install 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., "@ats-fill-mcp Inspect the current job application form and fill it using my resume."
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.
通用网申表单 AI 自动填写的 可复用 MCP 服务器。把「Agent/LLM 做语义规划 + 页内批量执行」的混合方案固化为服务，可在任何网申站点复用，避免逐字段手工点选、也规避牛客式“几何错位”。
flowchart LR
A[Agent / LLM<br/>MCP 客户端] -- inspect_form --> M[ats-fill-mcp]
A -- fill_form ops --> M
M -- inject engine.js<br/>capture/exec --> B[已登录 Chrome<br/>CDP 9222]
A -- verify_form --> M
A -- read 简历 md --> P[(简历预填个人信息.md)]语义层（Agent/LLM）：调用 inspect_form 看结构 → 对照简历给出 ops（按 msg/id/name 寻址、值别名归一）。这正是本方案相对牛客脚本的核心优势。
执行层（本服务）：页内 engine.js + 批量执行器：native setter + input/change、原生 select、radio/checkbox、省市两级级联下拉、日期回车、多行“增加更多”。
Related MCP server: MCP智能简历投递助手
cd ats-fill-mcp
npm install先关闭已开着的 Chrome，再带远程调试端口启动（沿用你已登录网申账号的用户目录）：
"C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222若想与日常浏览器并存，可另设
--user-data-dir=D:\chrome-debug，但需在其中重新登录目标网申站。
mcp.servers）{
"servers": {
"ats-fill": {
"type": "stdio",
"command": "node",
"args": ["c:/Users/Mr.z/Desktop/release-learn/ats-fill-mcp/src/index.js"],
"env": { "CDP_URL": "http://127.0.0.1:9222" }
}
}
}重启 VS Code / 重载窗口后，MCP 工具即对 Copilot 可用。
工具 | 说明 |
| 打开/聚焦页面并注入引擎 |
| 采集字段： |
| 批量执行，返回每项成功/失败与回读值 |
| 回读校验（ |
推荐工作流（Copilot 提示词可复用）：
1) inspect_form { url: "<网申页>" }
2) 读取简历源（如 简历预填个人信息.md），据此生成 fill_form 的 ops。
3) fill_form { ops: [ ... ] }
4) verify_form { msgs: ["姓名","民族","期望工作地点1","企业名称", ...] }
5) 由用户复核后，在页面上点“保存”。目标寻址优先级：id > name > msg（WinTalent/大易等表单控件带 msg="字段语义"，最稳）
{op:"text", msg:"证件号码", value:"421022200502060614"} — 文本/textarea
{op:"clear", msg:"其他外语水平及成绩"} — 清空
{op:"date", msg:"到岗时间", value:"2026-09-06"}
{op:"select", msg:"民族", value:"汉族"} — 原生下拉，选项文本精确→模糊匹配
{op:"radio", msg:"性别", label:"男"}
{op:"check", msg:"同意声明", on:true}
{op:"cascade", cityId:"11_245_1", provSub:"湖北", citySub:"荆州"} — 省市两级（省级自动取 firstLevl+cityId）
{op:"addRow", text:"实习经历", times:1} — 点“增加更多/继续添加 …”
本服务不点“保存”、不上传附件（照片/学籍报告/成绩单/外语证明/身份证/简历需用户本地上传）。
自动填入需与用户提供的真实简历一致；敏感字段（证件号等）请确保来源可靠，避免虚假申报。
若表单非“msg”体系：用 id/name 寻址即可；字段语义由调用方(Agent)按 inspect_form 的上下文判定。
中文 ID 以数字开头 → 内部一律用 getElementById/msg 寻址，不受 CSS 数字开头限制影响。
拿到任意新网申页后：inspect_form 会输出其 msgFields/addButtons；对照简历把“实习经历、项目、教育、家庭”等字段写成 ops 即可，无需为该站写模板——语义规划由 Agent 现算，执行由本服务现跑。
按 ops 批量执行填写/纠错。支持 text/date/select/radio/check/cascade/addRow；控件用 id/name/msg 寻址。返回每项成功与否与回读值。
| Name | Required | Description | Default |
|---|---|---|---|
| ops | Yes | 填写操作数组，见工具说明 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does a solid job: it discloses batch behavior, supported control types, addressing by id/name/msg, and the per-item success/readback return contract. It does not detail error handling or side effects, but it is materially transparent.
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 three concise, front-loaded sentences with no filler. The first sentence gives the core behavior, the second enumerates capabilities, and the third states the result format.
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?
For a one-parameter tool with no annotations and no output schema, the description covers input semantics, supported control types, addressing, and return values. The main remaining gap is an explicit per-operation JSON shape or example, but the description is sufficient for an agent to call the tool with reasonable confidence.
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?
The schema only documents ops as '填写操作数组，见工具说明', so the description adds real meaning by explaining what ops can contain: supported field types, addressing methods, and return semantics. This exceeds the schema baseline and helps an agent construct valid operations.
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 states a specific verb and resource: '按 ops 批量执行填写/纠错' (batch fill/correct according to ops), and further specifies supported control types and addressing modes. This makes it easy to distinguish from sibling tools like navigate, inspect_form, and verify_form.
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 makes its context clear: use it to fill or correct form controls in batch. However, it does not explicitly discuss when to prefer a sibling tool or when not to use this tool, such as inspecting the form first or verifying afterwards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
采集当前(或给定 url)网申表单结构：带 msg 语义的字段清单、当前值、下拉选项、可用的“添加更多”按钮。用于 Agent 语义规划。
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | 可选：要导航并采集的表单 URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. The verb 采集, combined with the listed outputs, conveys a read-only inspection operation and tells the agent what it will receive. It does not explicitly state 'no side effects', but the inspection framing makes the behavior clear enough.
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?
One dense sentence front-loads the action and resource, listst the collected elements, and ends with usage purpose. There is no filler, and each clause contributes to an agent's understanding of when and how to invoke it.
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?
With no output schema, the description enumerates the main return components — field list, current values, dropdown options, add-more buttons — so an agent can anticipate the result. It could be more explicit about exact return shape or failure behavior, but for a single optional-parameter inspection tool it is largely sufficient.
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?
The schema covers the only parameter, url, 100% with a description of optional navigation and collection. The tool description adds the key semantic that omitting url inspects the current form while providing one navigates and inspects a given URL, which goes beyond the schema.
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 uses a specific verb, 采集, and a specific resource, 网申表单结构, and enumerates exactly what is collected: fields with msg semantics, current values, dropdown options, and available 'add more' buttons. This clearly distinguishes it from the sibling tools navigate, fill_form, and verify_form.
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?
It states the intended context: 用于 Agent 语义规划, which signals use during semantic planning rather than execution. It does not explicitly name fill_form or verify_form as alternatives or state when not to use it, so it stops short of the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
回读指定 msg 字段当前真实值，用于填写后校验。传 ["*"] 可返回全部。
| Name | Required | Description | Default |
|---|---|---|---|
| msgs | Yes | 要校验的字段语义(msg)，如 ["姓名","民族","企业名称"] 或 ["*"] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral burden. '回读' strongly implies a non-mutating read operation, and '当前真实值' adds useful nuance that it returns the actual current value. However, it does not explicitly state that no side effects occur, nor does it describe error cases or return behavior.
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?
Two short sentences: the first states the core purpose and behavior, the second covers the special wildcard case. There is no redundant or filler content, and the most important information is 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?
For a one-parameter read-back tool with no output schema, the description is largely complete: it explains the action, when to use it, and the only special input value. It could mention the return format or behavior for invalid fields, but the sibling tool context and simple scope make this adequate.
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?
The schema already documents the msgs parameter well, including the wildcard, so the baseline is 3. The tool description adds context about 'current real values' and the purpose of validation, but it does not meaningfully extend the parameter semantics beyond what the schema already provides.
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 identifies a specific action (回读/read back), a specific resource (specified msg fields), and the intended use case (post-fill verification). It distinguishes itself from fill_form by describing a read-back operation, though it does not explicitly contrast itself with inspect_form.
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 gives clear context: this is for validating after the form has been filled ('用于填写后校验'). It does not list exclusions or explicitly name alternatives, but the usage context is concrete enough for an agent to decide when to call it.
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. Dates show when Glama detected each change.
v0.1.0fill_forminspect_formnavigateverify_formEach tool targets a distinct phase: navigate opens the page, inspect_form reads structure, fill_form writes values, and verify_form confirms results. There is no meaningful overlap between their responsibilities.
Three tools follow a clear verb_noun pattern (inspect_form, fill_form, verify_form), while navigate is a bare verb. The imperative style is consistent, but the missing _form suffix is a minor deviation.
Four tools cover the full form-filling workflow without redundancy. The count is appropriate for the server's focused purpose.
The set forms a complete lifecycle: navigate to the page, inspect structure, fill or update values, and verify results. No obvious operations are missing for the stated ATS form-filling domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Search AI-native jobs, inspect application forms, and fetch free interview-prep resources.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/EXPR2023/ats-fill-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
