A
licenseA
qualityD
maintenanceEnables AI agents to perform instant SEO, performance, and security audits of any website through the Model Context Protocol. It provides comprehensive analysis without requiring API keys or configuration.
11
5
MIT
content-qa-mcp
by Alvi-808
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@content-qa-mcpRun qa_full_report on this article with focus keyword 'MCP'."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
content-qa-mcp
An MCP (Model Context Protocol) server for editorial content QA. Point Claude at an article and get a findings report where every finding comes with the fix attached, so the report is usable instead of only correct.
That findings-with-fixes contract is enforced by the test suite: a check that emits a finding without an actionable fix fails the suite.
What it does
Four tools, one prompt, zero API keys. Everything runs locally.
Tool | Input | What it checks |
| HTML or plain text, optional focus keyword | Runs all checks below, merges findings, sorts by severity, returns a publish/fix/block verdict |
| plain text | Flesch-Kincaid grade, long sentences, passive-voice share |
| plain text | Stock phrases ("delve into", "in today's fast-paced world", 15 patterns total), em/en-dash density, arrow glyphs, emoji in body prose |
| article HTML, optional focus keyword | Title and meta length, H1/H2 structure, image alt coverage, internal links, keyword presence and density |
Plus a qa_review prompt that drives the full report and asks the model for an editorial verdict without softening or inventing findings.
Every finding is one object:
{
"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."
}See a full run in samples/sample-report.md: 22 findings on the deliberately broken fixture article, regenerable with npm run sample.
Related MCP server: pangram-editorial
Install and register in Claude Code
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 handshakeRegister (Claude Code CLI):
claude mcp add content-qa -- node /absolute/path/to/content-qa-mcp/src/server.jsVerified working:
content-qa: C:\Program Files\nodejs\node.exe C:\...\content-qa-mcp\src\server.js - √ ConnectedThen, in a Claude Code session: "run qa_full_report on this article" or use the qa_review prompt.
Remove with claude mcp remove content-qa.
Windows note (the part most tutorials skip)
On Windows, register stdio MCP servers with the absolute path to node.exe and the script:
claude mcp add content-qa -- "C:\Program Files\nodejs\node.exe" "C:\path\to\content-qa-mcp\src\server.js"Registrations that go through npx or a .cmd shim routinely fail to connect on Windows because the spawned process never attaches stdio correctly, and the failure is silent. Absolute node.exe plus the script path works every time. The end-to-end test in this repo uses the same pattern (process.execPath).
Design notes
Checks are pure functions in
src/checks/, importable without MCP. The server is a thin protocol layer over them, so the same checks can run in CI, a git hook, or a pipeline.The SEO check is scoped on purpose. It parses well-formed CMS article output (WordPress, Ghost, static-site generators) with regex extraction. It is not a general HTML parser and does not try to survive adversarial markup. Naming the boundary beats pretending there isn't one.
Plain-text input skips the SEO check instead of reporting fake "missing tag" findings.
The stock-phrase list bans classes, not strings. Each entry is a pattern, so one-word rewrites of a cliche still get caught.
Why this exists
This is the working method behind my paid editorial QA work, packaged as tools an agent can call. The rule it encodes: a QA report that says what is wrong without saying what to do next just moves the work to someone else's desk. Findings ship with fixes or they don't ship.
License
MIT
Available Tools
4 toolsai_tell_scanAI-writing tell scanA
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Article prose, plain text |
TDQS
A3.8/5.0
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
qa_full_reportFull editorial QA reportA
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | The article: raw HTML (preferred) or plain text | |
| focusKeyword | No | Primary keyword the article targets |
TDQS
A4/5.0
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
readability_checkReadability checkA
Flesch-Kincaid grade, long-sentence and passive-voice findings for article prose. Plain text in; findings with fixes out.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Article prose, plain text |
TDQS
A4/5.0
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
seo_onpage_checkOn-page SEO checkB
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| html | Yes | The article page HTML | |
| focusKeyword | No | Primary keyword the article targets |
TDQS
B3.4/5.0
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
v1.0.0- First observed
ai_tell_scan - First observed
qa_full_report - First observed
readability_check - First observed
seo_onpage_check
TDQS
A4/5.0
Scored across 4 tools
Disambiguation5/5
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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
Six tools for SEO and AI-readability audits. 91 checks, 11 score modules.
SEO, GEO & AI Visibility — research, write, optimize, publish & monitor content. 122 tools.
AI Visibility and Content Intelligence tools for Claude and MCP-compatible agents.
Audits how AI answer engines read a page and grades it A+ to F across four measured layers.
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables AI attribution audits and quick transparency checks on written content, providing authorship analysis and segment breakdowns for editorial review.22MIT
- AlicenseNot gradedqualityBmaintenanceProvides 23 bounded MCP tools for AI agents to perform technical SEO audits, including crawl setup, page analysis, issue detection, and report exports, all while keeping data local.6MIT
- AlicenseAqualityAmaintenanceEnables human-like non-fiction authoring by training custom voices, applying tone presets, auditing drafts for AI tells, and managing dictionaries, all locally.1019978MIT