一个用于文章内容质量保障（QA）的 MCP（Model Context Protocol）服务器。把一篇文章交给 Claude，就能得到一份问题报告，其中每一条发现都附加了修复建议，所以这份报告不只是"正确的"，而是直接可用的。
"发现必带修复"这一约定由测试套件强制执行：任何只输出发现、却不给出可操作修复的检查，都会导致测试套件失败。
四个工具、一个提示词、零 API 密钥。一切都在本地运行。
工具 | 输入 | 检查内容 |
| HTML 或纯文本，可选焦点关键词 | 运行下方全部检查、合并所有发现、按严重程度排序，并返回可发布/需修复/阻止发布的结论 |
| 纯文本 | Flesch-Kincaid 年级水平、长句、被动语态占比 |
| 纯文本 | 套话（"delve into"、"in today's fast-paced world"等，共 15 种模式）、em/en 破折号密度、箭头字形、正文散文中的 emoji |
| 文章 HTML，可选焦点关键词 | 标题和 meta 长度、H1/H2 结构、图片 alt 覆盖、内部链接、关键词存在与密度 |
另加一个 qa_review 提示词，用来驱动完整报告，并要求模型给出编辑裁决——既不淡化问题，也不凭空捏造问题。
每个发现都是一个对象：
{
"check": "seo-onpage",
"severity": "high",
"excerpt": null,
"finding": "No meta description.",
"fix": "Add a 120-155 character meta description that states the article's payoff and includes the keyword once."
}完整运行示例见 samples/sample-report.md：该样本包含 22 条针对刻意破坏的 fixture 样板文章得出的发现，可用 npm run sample 重新生成。
Related MCP server: OpenSEO-Lite
git clone https://github.com/Alvi-808/content-qa-mcp.git
cd content-qa-mcp
npm install
npm test # 14 tests, includes a real MCP client/server handshake注册（Claude Code CLI）：
claude mcp add content-qa -- node /absolute/path/to/content-qa-mcp/src/server.js已验证可用：
content-qa: C:\Program Files\nodejs\node.exe C:\...\content-qa-mcp\src\server.js - √ Connected然后，在 Claude Code 会话中：对这篇文章执行 "run qa_full_report ..."，或使用 qa_review 提示词。
用 claude mcp remove content-qa 移除。
在 Windows 上，需要注册 stdio MCP 服务器并使用 node.exe 的绝对路径和脚本：
claude mcp add content-qa -- "C:\Program Files\nodejs\node.exe" "C:\path\to\content-qa-mcp\src\server.js"凡是经由 npx 或 .cmd shim 运行的注册，在 Windows 上常常会静默地无法连接，因为被生成的进程根本无法正确挂接 stdio。使用绝对路径的 node.exe 加上脚本路径则每次都能成功。本仓库的端到端测试也使用了相同的模式（process.execPath）。
各检查项都是纯函数，位于 src/checks/ 中且不需要 MCP 即可引入。服务器只是在它们之上的一层薄协议层，所以同样的检查可以运行在 CI、Git hook 或流水线中。
SEO 检查的范围是有意设定的。 它用正则解析格式良好的 CMS 文章输出（WordPress、Ghost、静态站点生成器）。它并不是一个通用 HTML 解析器，也不会去对抗那些恶意标记。明确边界总比装作没有边界好。
纯文本输入会跳过 SEO 检查，而不是报出虚假的"缺失标签"问题。
套话列表封禁的是"一类话"，而不是具体某个字符串。 每个条目都是一个模式，所以即使把某个陈词滥调换个说法，也照样会被抓到。
这是我做付费编辑内容 QA 时的实际操作流程，把它打包成了可以让 agent 调用的工具。它蕴含的规则是：一份只说哪里错了却不说接下来怎么做，不会把活儿推给别人去做罢了。要么把修复方案一起交付，要么就不要发布这个发现。
在某次
Scan prose for machine-writing tells: stock phrases (delve into, in today's fast-paced world, ...), em/en-dash density, arrow glyphs, emoji. Findings with fixes.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Article prose, plain text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral disclosure burden. It lists what the scan looks for and promises 'Findings with fixes,' which implies a non-mutating analysis that returns suggestions. However, it leaves ambiguity about whether fixes are applied automatically or merely proposed, and it does not mention output structure or limitations.
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 two compact sentences with no filler. Detection categories are front-loaded, and the output promise is stated in one crisp fragment, 'Findings with fixes.'
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 low-complexity tool with a single well-documented parameter and no output schema, the description provides the essential purpose and output promise. It would benefit from clarifying whether fixes are returned as suggestions or applied to the input, but the invocation context is otherwise 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?
There is a single 'text' parameter with 100% schema description coverage ('Article prose, plain text'). The description repeats the prose idea but adds no new parameter-level detail such as length limits, accepted formats, or normalization behavior, so it stays at the baseline for high schema coverage.
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 opens with a specific verb and resource: 'Scan prose for machine-writing tells.' It enumerates concrete detection categories (stock phrases, em/en-dash density, arrow glyphs, emoji), making it readily distinguishable from siblings like readability_check or seo_onpage_check.
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 intended use is implied by the description: use when you need to detect machine-writing tells in prose. However, it never explicitly states when to prefer this tool over qa_full_report, readability_check, or seo_onpage_check, nor does it give any when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run every check (readability, AI-writing tells, on-page SEO) on one article and return a single report. Every finding comes with the fix attached. Accepts raw HTML (preferred) or plain text; the SEO check only runs on HTML input.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | The article: raw HTML (preferred) or plain text | |
| focusKeyword | No | Primary keyword the article targets |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the SEO check only runs on HTML input, which is a behavioral constraint. However, it doesn't mention whether the tool is read-only or if it has any side effects, rate limits, or other behavioral traits. The description is honest but not exhaustive.
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 two sentences, front-loaded with the core purpose and the key constraint about HTML. Every sentence earns its place, and there is no fluff.
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?
Given the tool's complexity (running multiple checks) and the absence of an output schema, the description does a good job of setting expectations: it returns a single report with fixes attached. It could mention the format of the report or whether it's a summary, but the description is adequate for an agent to decide to call it.
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?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds context that 'input' can be raw HTML or plain text and that HTML is preferred, which is useful. It doesn't add much about 'focusKeyword' beyond what the schema says, but the schema already covers it. Baseline 3 is appropriate.
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 clearly states the tool runs every check (readability, AI-writing tells, on-page SEO) on one article and returns a single report. It distinguishes itself from the sibling tools by being the comprehensive 'full report' option, while the siblings are individual checks.
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 implies when to use this tool: when you want all checks at once. It also provides a clear preference for HTML input and notes that the SEO check only runs on HTML. However, it doesn't explicitly state when to use the individual sibling tools instead, though the distinction is fairly obvious from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flesch-Kincaid grade, long-sentence and passive-voice findings for article prose. Plain text in; findings with fixes out.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Article prose, plain text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Plain text in; findings with fixes out' clearly signals a side-effect-free analysis operation returning suggestions, and enumerates the three specific checks performed. It doesn't disclose edge cases (e.g., handling of non-prose input) but for a stateless analysis tool the core behavioral profile is well covered.
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 compact sentences with zero waste. The analysis types are front-loaded in the first sentence, and the input/output contract is packed into a pithy second sentence. Every word earns its place.
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 single-parameter analysis tool with 100% schema coverage and no output schema, the description is nearly complete: it states input format, the three checks, and the output shape (findings with fixes). The only minor ambiguity is what 'fixes' precisely means — whether suggestions or corrected text — but the core calling contract is clear.
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?
Schema description coverage is 100% — the single 'text' parameter is already documented as 'Article prose, plain text'. The description's 'Plain text in' is mostly redundant with the schema. Baseline 3 applies here since the schema fully handles parameter documentation and the description does not add meaningful syntax or format detail beyond it.
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 names a specific resource ('article prose') and a clear operation with concrete analysis dimensions: Flesch-Kincaid grade, long-sentence and passive-voice findings. This distinctly separates it from its siblings (qa_full_report, ai_tell_scan, seo_onpage_check), which cover different QA, AI and SEO concerns respectively. An agent can immediately tell what this tool produces.
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 purpose is clear enough that an agent can infer when to use it (readability analysis of prose), but the description gives no explicit when-to-use/when-not-to-use guidance and names no alternatives. Siblings cover different domains so confusion is unlikely, but no exclusions or selection criteria are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Title, meta description, heading structure, image alt coverage, internal links, and keyword usage for one article's HTML. Built for well-formed CMS article output (WordPress, Ghost, static sites), not adversarial markup.
| Name | Required | Description | Default |
|---|---|---|---|
| html | Yes | The article page HTML | |
| focusKeyword | No | Primary keyword the article targets |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only analysis but never states that it makes no modifications, requires no authentication, or has side effects. The input constraint is mentioned, but behavioral expectations (e.g., safety, external calls) are absent.
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 sentences, zero fluff. The core list of checks is front-loaded, followed by constraints. Information density is high with no redundant wording.
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?
There is no output schema and no mention of what the tool returns (score, report, list?). Since the tool has only two simple parameters, the description covers input well, but the absence of any statement about the return value leaves agents guessing. An agent cannot reliably use the output without more info.
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?
Schema coverage is 100% (both html and focusKeyword have descriptions). The description adds minor context by enumerating SEO aspects and the 'one article' scope, but it doesn't go beyond what's already obvious from the parameter names and 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?
Description clearly lists the specific checks (title, meta description, heading structure, etc.) performed on a single article's HTML. The verb 'check' is implied but the resource is explicit. It doesn't distinguish itself from siblings like qa_full_report, but the purpose is unambiguous.
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 phrase 'Built for well-formed CMS article output (WordPress, Ghost, static sites), not adversarial markup' provides clear context on when to use (clean CMS HTML) and explicitly rules out one exclusion. However, it doesn't compare to siblings like readability_check or qa_full_report, so it earns a 4 rather than 5.
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.
v1.0.0ai_tell_scanqa_full_reportreadability_checkseo_onpage_checkScored across 4 tools
Each tool targets a distinct aspect of content QA: readability, AI tells, on-page SEO, and a combined full report. There's no overlapping purpose; the full report explicitly aggregates the other three, which is clear.
All names use lowercase_with_underscores and are descriptive noun phrases. Minor inconsistency in word type ('report', 'check', 'scan') but no mixing of conventions, so it's mostly predictable.
Four tools is well-scoped for a content QA server, covering the core checks and an aggregated report. Each tool earns its place without unnecessary bloat or overly thin coverage.
The server covers the primary QA dimensions for articles: readability, AI-writing tells, and on-page SEO, plus a comprehensive report. There are no obvious missing operations for the stated domain.
Six tools for SEO and AI-readability audits. 91 checks, 11 score modules.
SEO, GEO & AI Visibility — research, write, optimize, publish & monitor content. 121 tools.
Technical SEO and AI-readiness audits for any page, plus a check that your fix worked.
AI Visibility and Content Intelligence tools for Claude and MCP-compatible agents.
