Cursor 配置 HotLogin MCP：从环境启动到页面检查

做浏览器自动化时，最容易卡住的往往不是“怎么打开网页”，而是如何把环境准备、页面检查、结果记录和收尾操作连成一个可复核的流程。

这篇文章记录一次基于 HotLogin Local API MCP Server 的接入思路：在 Cursor 中配置 MCP，让 AI 助手能够调用已定义的本地工具，完成一次低风险的浏览器环境检查。

本文只讨论自有系统、测试环境或已获授权的公开页面。不要用自动化绕过站点规则、验证码、访问控制或隐私限制。

1. MCP 解决的是什么问题？

MCP（Model Context Protocol）可以理解为 AI 客户端与外部工具之间的一种标准连接方式。

它不是让 AI 获得“无限制的浏览器控制权”，而是把 AI 可调用的能力限制在服务端公开的工具中。对于浏览器环境管理，这种边界非常重要：AI 可以协助执行确定的步骤，但任务目标、权限范围和最终判断仍应该由人负责。

HotLogin 的 MCP Server 对接的是本地 Local API。根据项目公开的工具清单，它覆盖了以下几类能力：

• 查询、创建、更新、启动和关闭浏览器环境；

• 查询和维护环境分组、代理记录；

• 在环境启动后连接浏览器会话；

• 访问页面、读取可见文本、截图、等待元素和执行经授权的页面交互；

• 查询本地服务健康状态和环境运行状态。

这很适合“规则清楚、结果可验证”的工作，例如测试环境中的页面回归检查、公开页面的信息核验，或者团队内的环境盘点。

2. 接入前的准备条件

先确认这几项基础条件：

1. 已安装并启动 HotLogin 客户端；

2. 本地 Local API 可访问；

3. Node.js 版本不低于 18；

4. 已安装 Cursor，并可在设置中添加 MCP Server；

5. 如果本地 API 开启了鉴权，准备好正确的 `API_KEY`，不要将它写进公开仓库或截图。

如果团队统一管理本地 API 配置，还应确认端口、基础地址和密钥由谁维护。自动化失败时，很多问题并不在提示词，而在本地服务没有启动、端口不一致或鉴权配置错误。

3. 在 Cursor 中添加 MCP Server

打开 Cursor 的 Settings → MCP → Add new MCP server，添加下面的最小配置：

{
  "mcpServers": {
    "hotlogin-local-api": {
      "command": "npx",
      "args": ["-y", "hotlogin-local-api-mcp"]
    }
  }
}

如果本地 API 使用了非默认端口或开启了鉴权，则增加环境变量：

{
  "mcpServers": {
    "hotlogin-local-api": {
      "command": "npx",
      "args": ["-y", "hotlogin-local-api-mcp"],
      "env": {
        "PORT": "60000",
        "API_KEY": "your_api_key"
      }
    }
  }
}

也可以使用 BASE_URL 指定完整的本地 API 根地址，例如：

{
  "env": {
    "BASE_URL": "http://127.0.0.1:60000",
    "API_KEY": "your_api_key"
  }
}

配置保存后，在 Cursor 的 MCP 面板确认服务已连接。第一次不要立刻给 AI 下达复杂任务，先让它调用健康检查工具，确认本地服务能正常响应。

4. 一次环境检查应该怎样拆分？

假设目标是：在指定浏览器环境中打开自有测试站登录页，检查标题、错误提示和登录按钮是否正常显示，并保留截图。

不要只写“帮我检查登录页”。更稳妥的写法是给出明确边界：

请仅在名称为「QA-登录页检查」的 HotLogin 环境中执行以下操作：
1. 检查本地服务状态；
2. 启动该环境；
3. 连接启动后返回的浏览器会话；
4. 访问 https://example.com/login；
5. 读取页面标题，检查登录按钮是否存在，并截取页面；
6. 返回检查结果、错误信息和截图说明；
7. 完成后关闭该环境。

不要填写账号密码，不要提交表单，不要访问任何未授权地址。

这种表达有四个好处：

• 明确了允许使用的环境；

• 明确了操作范围；

• 明确了输出内容；

• 明确了禁止动作和收尾动作。

5. 典型执行链路

从工具调用的角度看，一条正常链路通常是：

health_check
  → env_query / env_profile
  → env_launch
  → session_attach
  → page_visit
  → page_text / element_exists / page_capture
  → env_terminate

这里有两个容易忽略的点。

5.1 环境启动不等于已经连接页面

env_launch 的作用是启动环境。之后需要使用返回的浏览器会话信息进行 session_attach，才能继续调用 page_visit、page_capture 或元素操作类工具。

如果连接会话时超时，应该先检查环境是否仍在运行；会话地址过期时重新启动环境并获取新的会话信息。不要在连接失败的状态下连续重试页面操作。

5.2 截图不是结果，检查项才是结果

截图只能作为证据的一部分。更可用的检查记录至少应包含：

| 字段 | 示例 |

| --- | --- |

| 环境名称 | QA-登录页检查 |

| 访问地址 | https://example.com/login |

| 执行时间 | 以任务日志为准 |

| 页面标题 | 实际读取值 |

| 登录按钮 | 存在 / 不存在 |

| 异常信息 | 加载超时、元素缺失等 |

| 附件 | 页面截图 |

这样当测试失败时，负责人能判断是环境问题、站点问题，还是检查规则本身有误。

6. 哪些任务适合先交给 MCP？

建议优先从下面三类开始：

场景一：自有站点的页面回归检查

打开指定地址、检查关键文案或元素、截取页面、汇总异常。这类任务的输入和输出相对清晰，适合作为第一批自动化任务。

场景二：已授权的公开信息研究

按既定清单访问公开页面，读取可见内容并保留来源。研究结论、信息可信度和使用边界仍需要人工判断。

场景三：团队环境日常整理

查询环境、检查分组、确认哪些环境仍在运行，并按已经批准的规则进行整理。涉及删除环境、修改代理、清理 Cookie 或缓存时，建议单独审批。

7. 不建议直接自动化的动作

工具存在不代表应该默认调用。以下操作应当保留人工确认：

• 提交真实账号密码、支付或身份认证信息；

• 删除环境、清空缓存或修改大批量配置；

• 写入 Cookie、修改代理或改变团队权限；

• 对第三方平台进行批量发布、批量提交或高频访问；

• 涉及隐私数据、合同条款、资金和不可逆业务决策的操作。

一个实用规则是：可读取、可验证、可停止的任务先自动化；高影响、不可逆或涉及授权判断的任务交给人。

8. 常见报错排查

本地服务健康检查失败

检查 HotLogin 客户端是否启动，再核对 PORT、BASE_URL、API_KEY 是否与本地服务配置一致。

MCP Server 在 Cursor 中无法启动

确认 Node.js 版本不低于 18；Windows 环境下如果 npx 无法正常拉起，可根据项目文档改用 cmd /c npx -y hotlogin-local-api-mcp 的形式。

会话连接超时

检查环境是否仍在运行。如果启动后返回的会话地址已失效，重新启动环境并使用新的会话信息连接。

AI 做了超出任务范围的动作

这不是靠“再提醒一次”就能完全解决的问题。应该缩小提示词范围、按角色收紧 MCP 可用工具、给高影响动作增加人工审批，并要求结果按固定模板输出。

结语

把 MCP 接入浏览器环境管理，真正带来的不是“让 AI 替你点页面”，而是让重复操作变成有边界、有证据、能复核的流程。

第一次接入时，建议只选一个低风险任务：启动一个测试环境、访问一个自有页面、检查两个元素、留下截图、关闭环境。流程跑稳后，再逐步扩展到更多团队场景。

项目源码与最新配置请以 [HotLogin MCP GitHub 仓库](https://github.com/hotlogin-browser/hotlogin-mcp) 为准。浏览器环境方案可在 [HotLogin 官网](https://www.hotlogin.com/) 查看。