AI Humanizer MCP Server 对比：公开接口究竟能做什么

这份注明日期、非穷尽的评测核实了九家产品的第一方 MCP 人性化工具。这个数字只对应文末列出的产品方页面，不代表市场总数。它们的公开契约在 payload、传输方式、认证、执行模式和请求限制上各不相同。

本文核实的样本包括 HumanPen、WriteHuman、Phrasly、Duey AI、Ryter Pro、StealthGPT、Walter Writes、HumanText Pro 和 Undetectable AI。可复现边界是文末逐项列出的产品方页面、仓库、软件包与 schema；只有这些来源明确写出 humanization 工具，产品才进入表格。这是一份注明日期的来源账本，不是穷尽式市场搜索。本次没有授权账号、提交文字、上传文档或运行检测器。

HumanPen 发布本文，同时也是表中的产品之一。文中关于 HumanPen 的能力描述属于第一方产品声明，不是独立测试结果。

关键不在于页面有没有写 MCP，而在于公开工具契约是否真的定义了 humanization 操作，以及会有哪些数据经过接口。

先分清下面四类，才能避免把不同性质的接入方式塞进同一张名单：

1. 第一方 MCP：产品方发布或控制 Server，并明确记录 humanization 工具。表中已核实行都按这条规则进入本次注明日期的样本。
2. 第一方 API：产品方提供 REST 或流式接口。API 可以是 MCP Server 后面的服务，但只有 API 不能证明 MCP Server 已经存在。
3. 第三方 wrapper 或 actor：其他开发者围绕某个产品或通用流程提供适配器。维护责任、认证方式和数据路径应以这位开发者的契约为准。
4. 只有标签，未核实 humanization 工具：MCP 软件包或仓库确实存在，但本次检查的公开 schema 没有证明它提供 humanize 操作。

这套规则刻意保持保守。它并不是说未核实的能力绝对不存在，只表示在标注日期检查的公开材料不足以证明它。

目录和搜索结果只能告诉你去哪里找，工具 schema 才能说明 Agent 实际能调用什么。

下表记录的是 2026 年 8 月 26 日可查到的公开契约。只有相关 MCP 或产品页面为该工作流给出明确数字时，才会写入限制。

这些信息不衡量文本质量、检测器结果或学校是否允许使用，只描述接入边界。各家限制的单位也不同，可能是词、字符、套餐额度，或者没有公开数字。

规划工作流前必须保留限制的原始单位。30,000 字符不能写成 30,000 词。

HumanPen 和 HumanText Pro 提供本地 stdio 软件包。Ryter Pro 也链接了可选本地 stdio 软件包，但推荐使用托管 Streamable HTTP 端点。使用本地软件包时，MCP 进程在用户电脑上启动，从环境变量读取 API key，再通过标准输入输出与客户端通信。这里描述的是连接器运行在哪里，不代表改写模型或提交内容一定留在本机。

WriteHuman、Phrasly、Duey AI、Ryter Pro、StealthGPT、Walter Writes 和 Undetectable AI 提供托管连接。WriteHuman 与 Duey AI 记录了 OAuth 2.1 + PKCE，Phrasly 使用账号 OAuth 授权，Walter Writes 使用 OAuth 工作区授权。StealthGPT 的网页连接器走 OAuth，IDE 或 CLI 也可使用 bearer token；Undetectable AI 同时记录了浏览器 OAuth 与静态 API key；Ryter Pro 使用 `X-API-Key`。

认证方式会影响配置和凭据管理，却不能回答所有隐私问题。受限材料进入任何 Server 前，还要单独核对产品最新的数据保留、模型训练、删除和分包商条款。这些政策不在本次接口契约对比范围内。

HumanPen 的差异还在 payload 边界。它的 humanizer 工具接收 DOCX、PPTX 文件路径，并把结果写到本地输出路径；表中其他已核实工具记录的是文本输入。如果要看 HumanPen 的具体配置与文件路径流程，可以阅读在 Claude Code 中处理文档的独立指南。

本地 stdio 描述的是连接拓扑，不等于文档处理完全离线。

一次 humanization 调用可能直接返回内容，也可能只返回一张仍在处理中的任务回执。两种模式决定了 Agent 在第一次调用之后还需要做什么。

StealthGPT 直接在 MCP 中暴露异步步骤：`humanize_text` 返回 `runId`，随后由 `get_run_status` 获取最终结果。HumanPen 的 REST API 是文件任务流程：multipart 上传、收到任务回执、轮询，再下载可编辑文件；它的 MCP 工具会封装这段流程，并把完成文件写回磁盘。

新增契约中，Phrasly 把结果返回对话并保存到用户的 Phrasly 历史；Duey AI 把 `humanize_text` 与 Session 排期和状态工具分开；Ryter Pro 的 MCP 页面记录了 `humanize_text`，没有另列任务或轮询契约。各家的独立 API 还能补充更多边界：Undetectable AI 的 REST v2 先提交文本并返回待轮询 ID，Walter Writes 记录了同步与异步 API 任务，WriteHuman 另有 JSON REST API，其限制不能拿来替换 MCP 限制。

聊天场景里，文本结果可能就是交付物；论文、报告或演示文稿通常要交文件。后一种情况应记录源路径、输出路径、任务状态和返回文件类型，再做文档级验收。完整步骤可以看 Word 文档返回后的复核流程。

工具调用成功，只能证明工具正常返回，不能证明每条引用、域、表格、注释或幻灯片对象都正确保留。

Text2Go 的公开仓库与 npm 软件包名都是 `ai-humanizer-mcp-server`，在搜索结果里很容易让人直接下结论。不过，在本次检查的 1.0.7 版本公开 TypeScript 源码中，Server 只注册了一个名为 `detect` 的工具，并调用文本检测端点；检查范围内没有找到已注册的 humanization 工具。

因此，更稳妥的分类是 MCP 软件包存在，但 humanization 未核实。不能进一步写成这项能力永远不会存在，因为软件包、远程端点或文档都可能在核验日期之后变化。

社区 actor 又是另一类。Apify 上的 `Humanize AI Text` 把开发者标为 Neatrat，同时注明由社区维护。它可能提供一条自动化路径，但并不是某个具名 humanizer 产品方发布的第一方 MCP 或 API 契约。Actor 页面的说法只能归属于该条目，不能自动转移给任何底层产品。

看到目录结果后，应打开当前 schema 回答三个问题：谁在运营、注册了哪些工具、内容会发往哪个端点。只要有一个答案缺失，文章里就应保留这项不确定性，不要用标题代替证据。

“未核实”是一种证据状态，不是对未来能力的判决。

先确定交付物和控制边界，再看产品名。

1. 明确最终交付物。 Agent 要在聊天中返回文本，还是必须交付可编辑 DOCX 或 PPTX？
2. 阅读真实工具 schema。 核对 humanize 工具、必填字段、最小输入和输出对象。
3. 记录传输与归属。 区分本地 stdio、托管 HTTP 与社区运营的 actor。
4. 让认证方式匹配客户端。 OAuth 可以避免在部分客户端粘贴长期 key；API key 可能更适合受控的本地自动化。
5. 处理完整执行状态。 第一次返回 job ID 或 run ID 时，流程必须包含轮询、终态处理和明确输出路径。
6. 让单位跟着限制走。 不要把字符、词、credits 和月度额度折成一个没有单位的数字。
7. 在 Server 之外定义验收。 重新核对含义、引用、数字、格式，以及最终任务适用的 AI 使用规则。

在本文核查的公开契约中，HumanPen 采用文件导向：MCP README 记录的是 DOCX 与 PPTX 路径，而不是粘贴文本框。HumanPen 发布本文，因此正式材料使用前，应先用可丢弃文件验证这项第一方声明。其公开流程也允许选择片段，以便缩小需要复核的范围。

符合条件时可以免费继续降 AI。

AI humanizer API 与 MCP Server 是一回事吗？ 不是。REST API 定义应用请求与响应；MCP Server 用 Agent 客户端可发现的协议暴露工具和资源。产品方可能同时提供两者，也可能只提供一种。

本次核查的 MCP 中，哪一个接收文档文件？ HumanPen 的公开 MCP README 为 humanization 工具记录了 DOCX 与 PPTX 文件路径，并把结果文件写回磁盘。某个产品网页端有上传功能，不代表它的 MCP 工具也接受文件。

本地 stdio MCP 会让文档完全离线吗？ 不一定。Stdio 只描述客户端与本地连接器怎样通信。还要查看连接器源码和产品方网络契约，才能判断内容是否会发送到远程 API。

OAuth 一定比 API key 更合适吗？ 两者解决凭据管理的方式不同。OAuth 可以让兼容客户端不必粘贴静态 key；放在环境变量里的 API key 则可能适合受控的本地自动化。任何一种方式本身都不能证明数据保留或内容隐私政策。

为什么 Text2Go 没被列为已核实的 humanizer MCP？ 本次检查的软件包源码注册了检测工具，没有注册 humanization 工具。如果未来公开版本提供并记录 humanize 操作，分类也应随证据更新。

MCP humanizer 能保证检测器结果吗？ 本文没有测试，也不支持这项结论。公开契约描述调用、payload、任务状态与限制，不能证明未来在 Turnitin 或其他检测器中的结果。

以下页面与公开仓库核查于 2026 年 8 月 26 日。端点、schema、限制和认证都可能变化，正式接入前应重新打开实时契约。

• HumanPen：开发者页面、humanizer 工作流、REST API 参考与 MCP 仓库 README
• WriteHuman：MCP 页面、API 页面与 MCP 上线说明
• Phrasly：MCP 页面
• Duey AI：MCP 页面
• Ryter Pro：MCP 页面
• StealthGPT：MCP 页面、MCP 集成参考与 API 页面
• Walter Writes：MCP 概览与开发者文档
• HumanText Pro：MCP 页面、npm 软件包与公开仓库
• Undetectable AI：MCP 页面、开发者页面与 Humanization API v2 指南
• Text2Go：公开仓库与已发布的 Server 源码
• 第三方示例：Apify Humanize AI Text actor