MCP 接入指南

浏览器自动化如何接入 MCP？从环境启动到页面检查

把“打开环境、检查页面、记录结果”拆成可执行步骤，才能让自动化既能帮忙，也能被团队复核。

核心思路：HotLogin MCP 是连接 HotLogin Local API 的本地 MCP Server。它让兼容 MCP 的 AI 客户端调用经定义的环境管理与浏览器会话工具；真正决定结果可靠性的，是本地服务、操作边界和明确的验收标准。

接入前先回答三个问题

任务是什么？优先选择规则清晰、低风险、结果能被验证的页面检查或环境整理任务。

运行在哪里？确认 HotLogin 客户端已启动，本地 API 地址、端口和鉴权方式正确。

谁来确认？让负责人确认输入来源、允许动作、异常处理和最终结论，避免把“执行”误当成“批准”。

结果如何保存？预先规定记录字段，例如环境名称、访问地址、检查时间、截图和异常说明。

第一步：连接本地服务

仓库提供的最小配置可通过 npx 启动 MCP 服务；若本地 API 有鉴权，需要提供匹配的端口或基础地址及 API Key。不要把密钥写进共享文档或公开提示词。

第二步：确认服务健康状态

开始业务任务前先检查本地服务是否可用。连接异常时，优先检查客户端是否启动、端口和 BASE_URL 是否一致、鉴权是否正确；不要通过无止境重试掩盖配置问题。

第三步：选择并启动浏览器环境

先查询现有环境、详情与分组，确认项目归属后再启动。对于临时任务，使用清晰命名并注明负责人；不再使用时及时关闭窗口。

第四步：连接会话后做页面级操作

环境启动会返回用于连接浏览器会话的信息。会话连接成功后，才执行页面访问、截图、读取可见文本、等待元素或填写经授权的表单等动作。页面工具应服务于具体检查项，而不是为自动化而自动化。

第五步：输出结果并收尾

将通过项、失败项与可复现线索交给负责人；关闭不再使用的环境。涉及删除环境、清理缓存、写入 Cookie 或修改代理等动作时，应单独审批。

一个适合先落地的案例：登录页回归检查

假设产品团队要确认自有网站的登录页在指定环境内是否能正常打开。AI 可以在授权范围内：启动指定环境、访问页面、读取页面标题和错误提示、检查登录按钮是否存在、截取页面作为证据。它不应自行提交真实账号、绕过验证码，或替代测试负责人判定是否上线。

验收模板

访问 URL｜环境编号或名称｜页面标题｜关键元素存在性｜截图｜错误信息｜执行时间｜人工确认人。把模板固定下来，后续任务才容易横向比较。

团队最容易忽略的风险

把“可调用”误解为“应调用”

本地 API 可以提供多种工具，并不代表所有工具都应开放给所有任务。权限要与影响程度匹配。

没有处理会话过期

启动环境后获得的会话地址可能失效。出现连接超时，应重新启动并检查状态，而不是让任务继续操作未知会话。

忽略网站规则与数据边界

仅对已授权系统和合法数据执行操作，并遵守目标服务规则、隐私政策及适用法律。技术连接能力不能替代合规判断。

常见问题

必须使用本地 API 吗？

是。该 MCP 服务基于 HotLogin Local API 工作，因此需要已运行的 HotLogin 客户端和可访问的本地 API。

它是否只支持环境管理？

除了环境、分组和代理相关操作，公开工具列表还包含会话连接后的页面访问、截图、读取文本、元素交互及等待等浏览器自动化能力。实际可用范围应以当前版本的工具说明和权限配置为准。

浏览器自动化如何接入 MCP？从环境启动到页面检查:梳理本地 API、浏览器会话、页面检查与团队操作规范

接入前先回答三个问题

第一步：连接本地服务

第二步：确认服务健康状态

第三步：选择并启动浏览器环境

第四步：连接会话后做页面级操作

第五步：输出结果并收尾

一个适合先落地的案例：登录页回归检查

团队最容易忽略的风险

把“可调用”误解为“应调用”

没有处理会话过期

忽略网站规则与数据边界

常见问题

必须使用本地 API 吗？

它是否只支持环境管理？