Skip to main content
Glama
deenesjakoruzh
Alvi-808

content-qa-mcp

by Alvi-808
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

content-qa-mcp

Ein MCP-Server (Model Context Protocol) für redaktionelles Content-QA. Man legt Claude einen Artikel vor und erhält einen Befundbericht, in dem jeder Befund den passenden Fix direkt mitliefert – der Bericht ist nutzbar statt nur korrekt.

Dieses Prinzip „Befund mit Fix“ wird von der Testsuite durchgesetzt: Eine Prüfung, die einen Befund ohne umsetzbaren Fix erzeugt, lässt die Suite fehlschlagen.

Was es tut

Vier Tools, ein Prompt, null API-Schlüssel. Alles läuft lokal.

Tool

Eingabe

Was geprüft wird

qa_full_report

HTML oder reiner Text, optional Fokus-Keyword

Führt alle unten genannten Prüfungen aus, bündelt die Befunde, sortiert nach Schweregrad und gibt ein Urteil zurück (publish/fix/block)

ai_tell_scan

reiner Text

Standardfloskeln („delve into“, „in today's fast-paced world“, 15 Muster insgesamt), Dichte von em- und en-dashes, Pfeil-Glyphen, Emojis im Fließtext

readability_check

reiner Text

Flesch-Kincaid-Wert, lange Sätze, Anteil Passivkonstruktionen

seo_onpage_check

Artikel-HTML, optional Fokus-Keyword

Länge von Titel und Meta-Beschreibung, H1/H2-Struktur, Abdeckung durch Alt-Texte bei Bildern, interne Links, Keyword-Präsenz und -Dichte

Außerdem gibt es einen qa_review-Prompt, der den kompletten Bericht anstößt und das Modell um ein redaktionelles Urteil bittet – ohne Befunde abzumildern oder zu erfinden.

Jeder Befund ist genau ein Objekt:

{
  "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."
}

Einen vollständigen Lauf mit samples/sample-report.md ansehen: 22 Befunde am absichtlich fehlerhaften Dummy-Artikel, regenerierbar mit npm run sample.

Related MCP server: Stylotrace MCP Server

Installieren und in Claude Code registrieren

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

Registrieren (Cloude Code CLI):

claude mcp add content-qa -- node /absolute/path/to/content-qa-mcp/src/server.js

Verifiziert funktionsfähig:

content-qa: C:\Program Files\nodejs\node.exe C:\...\content-qa-mcp\src\server.js - √ Connected

In einer Claude-Code-Sitzung dann z. B. „run qa_full_review on this article“ sagen oder den qa_review-Prompt nutzen.

Entfernen mit claude mcp remove content-qa.

Windows-Hinweis (der Teil, den die meisten Tutorials weglassen

On Windows registriert man stdio-MCP-Server mit dem absoluten Pfad zu node.exe und dem Skript:

claude mcp add content-qa -- "C:\Program Files\nodejs\node.exe" "C:\path\to\content-qa-mcp\src\server.js"

Registrierungen über npx oder einen .cmd-Shim führen unter Windows regelmäßig zu Verbindungsfehlern, weil der gestartete Prozess stdio nie korrekt anbindet – und der Fehler passiert still. Der absolute node.exe-Pfad plus Skriptpfad funktioniert dagegen zuverlässig. Der End-to-End-Test in diesem Repo nutzt genau dieses Muster (process.execPath).

Design-Anmerkungen

  • Die Prüfungen sind reine Funktionen in src/checks/, die unabhängig von MCP importieren können. Der Server ist nur seine dünne Protokollschicht darüber, sodass dieselben Prüfungen auch in CI, in einem Git-Hook oder in einer Pipeline laufen können.

  • Die SEO-Prüfung ist bewusst eng gefasst. Sie parst wohlgeformte CMS-Artikelausgaben (WordPress, Ghost, Static-Site-Generatoren) mit regex-Extraktion. Sie ist kein allgemeiner HTML-Parser und tut nicht so, als müsse sie gegen feindliches Markup funktionieren. Die Grenze zu benennen ist besser, als so zu tun, als gäbe es sie nicht.

  • Reine-Text-Eingabe überspringt die SEO-Prüfung, statt erfundene „fehlende-Tags“-Befunde zu melden.

  • Die Floskelliste verbietet Klassen, keine Strings. Jeder Eintrag ist ein Muster, sodass auch Ein-Wort-Umformulierungen einer Floskel erkannt werden.

Warum es das gibt

Das ist die Arbeitsmethode, die hinter meiner bezahlten redaktionellen QA-Arbeit steht – verpackt in Werkzeuge, die ein Agent aufrufen kann. Die Regel darin: Eine-QA-Bericht, der sagt, was angibt kaputt ist, ohne auch zu sagen, was zu tun ist, schafft die Arbeit nur auf den Schreibtisch von jemand anders. Befunde werden nur mit Fixes ausgeliefert – oder gar nicht.

Lizenz

MIT

Available Tools

4 tools
ai_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.

NameRequiredDescriptionDefault
textYesArticle 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.

NameRequiredDescriptionDefault
inputYesThe article: raw HTML (preferred) or plain text
focusKeywordNoPrimary 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.

NameRequiredDescriptionDefault
textYesArticle 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.

NameRequiredDescriptionDefault
htmlYesThe article page HTML
focusKeywordNoPrimary 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.

  1. 4 tool updatesv1.0.0
    • First observedai_tell_scan
    • First observedqa_full_report
    • First observedreadability_check
    • First observedseo_onpage_check
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

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

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • SiteAudit MCP

    vdalhambra
    A
    license
    A
    quality
    D
    maintenance
    Enables 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

  • Stylotrace MCP Server

    zhangyoufu-123
    A
    license
    Not graded
    quality
    B
    maintenance
    Exposes 43 writing tools to any MCP-capable agent host, enabling clarifying questions, outline generation, drafting, revision, anti-AI audit, reader profiling, and export as one guided workflow. It learns the user's voice from their tracked edits and can distill a project directory into reports, READMEs, or blog posts based on the user's style.
    1
    MIT

  • OpenSEO-Lite

    Nagacash
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents to perform live Google SERP searches, run on-page and full-site SEO audits with prioritized fixes, and check brand visibility in AI answer engines via four MCP tools.
    MIT

  • grammar-coach

    Najeeb-AI-bots
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables AI hosts to check text for grammar, spelling, and style errors, measure readability, and generate tone-adjusted rewrites through structured tool calls. Every tool returns predictable, typed output for reliable routing and results.
    MIT