这是一个由人类编辑用红笔修缮过的原稿返回给你的 MCP 服务器。 把韩语原稿打磨得更容易阅读。Upstage Solar Pro 4 负责润色句子， 而事实、引用、文体是否保持不变，由代码来判定。内容不做任何增删。
这是部署在 Vercel 上使用的服务端 MCP。每天最多免费 100 次调用，超出部分 使用自己的密钥（BYOK）即可。
这不是一台抹去“AI 味”的工具，而是消除读者需要读两遍的地方的工具。 所以工作顺序也不是探测、代换，而是跟吃人类编辑一样。
步骤 | 谁做 | 做什么 |
1. 通读 | 代码 | 先测出句子长度分布、冗长句、翻译腔、被动感、套话空话、节奏偏差 |
2. 意见 | Solar | 读出数据里看不到的东西——断掉的逻辑、重叠的段落、僵死的节奏 |
3. 修改 | Solar | 只针对“意见”中所指出的位置进行修改 |
4. 对比 | 代码 | 与原文对照，找出原本没有的数字、被改的引用、文体翻转 |
5. 修正 | Solar | 只对“对比”中暴露出的地方做局部修正 |
我们不会去问模型“你到底改了多少”。 因为自己刚写的东西自己评分，从来都会偏高。修改率、数字保留、引用比对、文体判断，全部由代码来算。输入一致，结果永远一致。
红笔原则 —— 如果不能一句话说清楚为什么改，就不动笔。
以删减为方向 —— 意正的好编辑不做追加。如果字数增加，就会报警告。
语气属于作者的 —— 把书面体调成礼貌态，这也算改写。反转会被判定阻无法采用。
事实不可动 —— 只要原文中没有的任何一个数字或句子出现，那这份修改稿就不予采用。
Related MCP server: mcp-korean-spell
工具 | 做什么 | 费用 |
| 通读原稿并返回值修改稿。本体。 | 1~3 次调用 |
| 不修改，只给“为什么不吸收”的意见。 | 1 次调用 |
| 句子长度、翻译腔、被动、节奏，按 0~100 分打分 | 免费 |
| 原稿与修改稿对比，找残留。其他模型改过的文章也检验。 | 免费 |
| 把一个段落做多个方向不一的方案改写。 | 1 次调用 |
| 查看今天剩余免费额度。 | 免费 |
proofread 参数参数 | 说明 |
| 要修改的稿件（最长 20,000 字） |
|
|
|
|
|
|
| 阅读对象。例如 |
| 附加要求。例如 |
| “一个字都不能改”的语句，在对比阶段强制执行 |
支持 Stream HTTP 的客户端（Claude Code、Cursor 等），直接将 URL 放入即可。
{
"mcpServers": {
"human-proofreader": {
"url": "https://<your-deployment>.vercel.app/api/mcp"
}
}
}Claude Code 只需一行命令即可。
claude mcp add --transport http human-proofreader https://<your-deployment>.vercel.app/api/mcp只支持 stdio 的客户端可以加上 npx -y mcp-remote <url>。
为了让部署 URL 直接交给 AI 完成安装，我们同时提供了机器读取的说明。两条路径都会读取某个请求头中的部署实际地址——占位符不会被原样复制。
路径 | 内容 |
| 散文式的说明文档：按客户端的安装命令、工具列表、免费额度与 BYOH 规则、结果返回方式等 |
| 相同内容的结构化清单。也包含可直接插入配置的完整配置片段 |
免费额度是以 Solar 调用 1 为单位来计算的。比如 proofread 一次等于通读 1 次 + 修改 1 次，那就扣 2 次。不以工具调用次数来计，是因为如果按工具调用次数算，同样的额度对不同人可能在量级上差十倍，上报、评估都会乱套。
readability 和 compare 不调用 Solar，不会扣减额度。
每天重置时间：KST 午夜。
想超额使用，就把自己的密钥放进 Header。不用工具参数而是放 header，是因为参数会以明文留在客户端对话记录中。
{
"mcpServers": {
"human-proofreader": {
"url": "https://<your-deployment>.vercel.app/api/mcp",
"headers": {
"X-Upstage-Api-Key": "up_..."
}
}
}
}Header | 路由 | 获取 Key |
| 直接用 Upstream ( | |
| 用 OpenRouter（模型 |
用自己的 Key 接入后，不再有每日上限，费用从对应提供方的账户中结算。
git clone https://github.com/SolarLLM/human-proofreader-mcp
cd human-proofreader-mcp && npm install
cp .env.example .env.local # OPENROUTER_API_KEY 또는 UPSTAGE_API_KEY 를 채운다
npm run dev # http://localhost:3000/api/mcpvercel deploy --prod变量 | 说明 |
| 免费一层级服务器 Key。两者选一个。 |
| 每日免费调用次数（默认 100） |
| 配额计数存储。若缺失，会用实例内存做近似统计，并在响应中标注。 |
| 对命中标识符做哈希时加入的值。部署内不同维护。 |
| 单次最大接收字符（默认 20,000） |
没有 Redis 也能工作，但 Serverless 是多实例状态，用户总数会变松。如果想要实际卡到 100 次，就去掉 Upstash Redis。
Vercel 配额及 depth：Hobby 计划函数执行时间 60 秒中断。deep（3 次）在长稿中可能超过它，所以 Hobby 上建议使用 standard 及以下，或升至 Pro（最长 300 秒）。
npm test # 결정적 계층(가독성·대조·변경률) 회귀 테스트
npm run typecheckLLM 那层不做测试。但所有判定代码都一一测试——因为“门没有响”才是这个服务器最危险的故障。
修改率是判断“是否过度修改”的标准。如果用人单位一次，光一个助词变化也会把整个词粗算为“已修改”，大约会变成双倍数值（实际：字符 22.8% → 词元 46.9%）。所以这里按字符为单位。
用句块、段块单位去 1:1 对位的方法全部放弃了。好的修改本来就是拆长句、并短句、纳段——无论选什么单位，1:1 对应都会把“拆/并”当成“对不上”，从而把正常的修改判定为重写。通过项目“フル”（把一段拆成四段的紧急公告 8 成会被判 75%，实际只有 27%）。
整篇文字直接跑 LCS（最长公共子序列）是准确且可负担的：两屏 2 万字符对 2 万字符，只要 1.1 秒。在一轮 Solar 调用超过 20 秒的背景下，这已完全可承受。结果与 Python difflib 的字符级判断完全一致（实测 0.228 = 0.228；0.680 = 0.68）。
阈值设为 警告 30% · 中止 50%。韩语因为助词、尾词音节高度重，内容完全不同的两篇文章相似度底也有 0.65~0.70。中止线 0.50 取这个底之下、正常重改（0.25~0.45）之上，因此能够区分“认真修改”与“已被重写”。
代码 | 判定 | 检测项 |
| 不采用 | 原稿中不存在的句子出现 |
| 不采用 | 原稿中不存在的数据出现 |
| 不采用 | 直接引用未能以原样保留 |
| 不采用 | 语气被翻转（如 from basic text-style over to a higher style） |
| 不采用 | 指定保存的句子发生变化 |
| 不采用 | 修改率 50% 以上——这不是修改，而是重作 |
| 警告 | 修改率 30~50% |
| 警告 | 新增原有套话 |
| 警告 | 语体上调 / 口语结尾变少 |
| 警告 | 丢失小标题，或篇幅增加 15% 以上 |
| 观察 | 记录新增单词 / 消失数字（只展示，不拦截） |
整句的添加一定会被抓到。但句中几个词的替换，不会用“给门禁”挡掉，而以 new_terms 列表显示出来——校订本来就会替换词，如果也拦截会造成大量误报。实测中，这一列表抓到过“与原始对比” → “与同规模基线对比”这一类的隐性修饰追加。
韩语中的“AI 味”问题的敏感度、文体分类体系，来自 epoko77-ai/im-not-ai。 代码没有直接复用，全部重写。本服务器的设计，也不是“去除 AI 味”，而是以“写好读的韩语”为出发点的独立项目。
MIT
This server cannot be deployed
AI web novel co-writer: series, characters, episodes, and quality evaluation. Korean-first.
Proofread live pages and sites for spelling, grammar, and placeholder text. Free: 2 pages a month.
Korean ID document verification and PII masking APIs
Loads your personal writing voice into any AI and scores how closely a draft matches it.
