mcp-ai-slop-checker

Name: mcp-ai-slop-checker
Author: parweb

by parweb

Overview Schema Source Related Servers Score Discussions Admin

JavaScript

mcp-ai-slop-checker

An MCP server that tells your model when its own writing sounds like AI.

MCP Registry test license

claude mcp add ai-slop-checker -- npx -y github:parweb/mcp-ai-slop-checker

Three tools, all deterministic, local and offline: no LLM call, no API key, no network request, no telemetry. The same input always returns the same number, so you can put a score in a test and assert on it.

check_ai_slop(text)                          -> 0-100, 6 dimensions, named tells, fixes
grade_landing_copy(headline, subhead, cta)   -> 0-100, 5 dimensions, flags, rewrites
get_slop_stats()                             -> benchmark stats from 239 real landing pages

Why

Every "AI detector" is a probabilistic classifier that guesses at authorship and gets it wrong on both sides. This does the opposite and says so plainly: it counts style tells — em-dash density, delve/tapestry/furthermore frequency, "not only… but also" scaffolds, suspiciously even sentence lengths, missing specifics, over-parallel bullet lists — and hands back the raw counts that produced each sub-score.

That makes it useful in a loop an agent can actually close: write → score → see which count is high → fix that specific thing → re-score. A classifier's "87% likely AI" gives an agent nothing to act on. "hype": 5 does.

A score is a style measurement, not an authorship claim. stripe.com scores 61 and was obviously written by professionals. Low score means reads generic, never was generated.

Related MCP server: defluff

Install

Listed in the official MCP Registry as io.github.parweb/ai-slop-checker.

Installs straight from GitHub — not on npm yet, so use the github: spec:

claude mcp add ai-slop-checker -- npx -y github:parweb/mcp-ai-slop-checker

Or in any MCP client config (claude_desktop_config.json, .mcp.json, Cursor, etc.):

{
  "mcpServers": {
    "ai-slop-checker": {
      "command": "npx",
      "args": ["-y", "github:parweb/mcp-ai-slop-checker"]
    }
  }
}

Or install the self-contained MCPB bundle (dependencies included, no install step) from the v1.0.2 release — mcp-ai-slop-checker.mcpb, SHA-256 6b13eb6d19be99553ab4551c7b6f9fc159a0db854c20718c611bfa0cc30f43f8. Rebuild it yourself and compare: ./scripts/build-mcpb.sh.

From source:

git clone https://github.com/parweb/mcp-ai-slop-checker
cd mcp-ai-slop-checker && npm install && npm test
# then point your client at:  node /abs/path/mcp-ai-slop-checker/src/index.js

Node >= 18. One runtime dependency (@modelcontextprotocol/sdk) plus zod.

Tools

`check_ai_slop(text)`

Scores prose 0-100, where 100 reads human. Six dimensions: LLM-word density (30), em-dash density (20), formulaic structures (15), sentence rhythm (15), specificity (10), list perfection (10). ~200+ characters gives a reliable read.

Real output, trimmed to the parts that matter:

// input: a 74-word paragraph of "In today's fast-paced world… delve… Moreover… seamless…"
{
  "score": 34,
  "verdict": "This sounds AI-generated.",
  "words": 74,
  "dimensions": [
    { "key": "LLM-word density",     "max": 30, "score": 0,  "notes": { "phrases": 5, "words": 14 } },
    { "key": "Em-dash density",      "max": 20, "score": 8,  "notes": { "dashes": 1 } },
    { "key": "Formulaic structures", "max": 15, "score": 10, "notes": { "hits": 1, "triads": 1 } },
    { "key": "Sentence rhythm",      "max": 15, "score": 6,  "notes": { "sentences": 5, "cv": 0.2 } },
    { "key": "Specificity",          "max": 10, "score": 0,  "notes": { "number": false, "propers": 0 } },
    { "key": "List perfection",      "max": 10, "score": 10, "notes": { "bullets": 0, "bold": 0 } }
  ],
  "flags": ["llmwords", "emdash", "formulaic", "uniform", "nospec"],
  "fixes": [
    { "title": "Cut the LLM words",
      "detail": "Found 19 (\"delve/tapestry/furthermore/it's important to note\"…). Each one is a known model tell. Replace with the plain word you'd say out loud." },
    { "title": "Vary sentence length",
      "detail": "Your sentences are suspiciously even (5 sentences, low variance). Humans write long, then short. Like this." }
  ]
}

The hand-written paragraph in test/engine.test.js — same subject, same rough length — scores 92, "Reads human."

`grade_landing_copy(headline, subhead, cta)`

Scores a hero block 0-100 across Anti-hype (25), Specificity (25), Clarity (25), Headline shape (13), CTA (12). subhead and cta are optional, but an empty CTA scores 0 on that dimension.

Three exclusions are worth knowing, because each one was a measured false positive rather than a preference: a digit that is part of a name, a version, a year or a list index is not a quantified claim (Auth0, Framer 3.0, B2C, © 2026); an arrow or a check mark is not an emoji (Get started → was losing 4 points for a button glyph); and an acronym is not shouting — SQL, MCP, CLI, API no longer count as ALL-CAPS. Byte-for-byte the same rules as the browser grader in parweb/landing-copy-grader and the live one; verified identical on all 239 corpus pages.

Real output:

// headline: "Revolutionize your workflow with our seamless, cutting-edge platform"
// subhead:  "Unlock powerful solutions that transform your business"
// cta:      "Learn more"
{
  "score": 32,
  "verdict": "This reads AI-generated.",
  "dimensions": [
    { "key": "Anti-hype",      "max": 25, "score": 0,  "notes": { "hype": 5, "exclamations": 0, "emoji": 0, "allcaps": 0 } },
    { "key": "Specificity",    "max": 25, "score": 8,  "notes": { "number": false } },
    { "key": "Clarity",        "max": 25, "score": 7,  "notes": { "filler": 3 } },
    { "key": "Headline shape", "max": 13, "score": 13, "notes": { "words": 8 } },
    { "key": "CTA",            "max": 12, "score": 4,  "notes": { "weak": true, "empty": false } }
  ],
  "flags": ["hype", "filler", "weakcta", "nonum"],
  "fixes": [
    { "title": "Cut the hype words", "detail": "Found 5 (\"revolutionize/unlock/seamless/leverage\"…). Replace each with a plain, concrete verb." },
    { "title": "Add one number",     "detail": "No concrete figure anywhere. …82% of the 239 pages in our dataset fail this one." },
    { "title": "Rewrite the CTA",    "detail": "\"Learn more\" is generic. Use an action + outcome…" }
  ]
}

Fix all four and the same offer scores 100:

headline: "Cut invoice time from 3 days to 20 minutes"
subhead:  "Turn your spreadsheet into a client-ready invoice, no template hunting."
cta:      "Start your first invoice"
-> { "score": 100, "verdict": "Reads human & sharp.", "flags": [] }

Both numbers are asserted in test/engine.test.js, so they can't silently drift.

`get_slop_stats()`

Without a baseline, "your copy scored 74" is meaningless. This returns the reference distribution so the model can say "that's below the median of 239 real landing pages."

These are the figures of the deposited corpus, scored with static-fetch-regex-v1. Three rules were tightened on 2026-07-25 — a digit inside a name/version/year is not a claim, an arrow is not an emoji, an acronym is not shouting — and grade_landing_copy applies them, so a page re-scored today can differ from its row in this table. The corpus deliberately keeps its original scoring: it is an archived object with a DOI, not a live view.


pages	239 (303 attempted, 64 excluded)
score	min 41 · median 79 · mean 80.1 · 19 perfect · 31 below 70
extracted	2026-07-24, raw HTML, no JS execution, no LLM

How often each tell fires:

flag	pages	%	meaning
`nonum`	195	82%	not a single digit in the hero
`filler`	82	34%	≥1 filler word
`weakcta`	35	15%	CTA is a stock verb phrase
`caps`	33	14%	ALL-CAPS word in headline/sub
`hype`	16	7%	≥1 hype word
`shorthl`	13	5%	headline under 3 words
`longhl`	9	4%	headline over 12 words
`excl`	7	3%	exclamation mark
`emoji`	7	3%	emoji in the hero

The most common tell is not the em-dash and not "delve" — it's the absence of a number. Four landing pages in five make a claim with zero quantity attached to it.

Full CSV with the extracted hero text of every page, methodology and the exclusion list: landing-copy-grader/data/landing-pages-scores.csv. node scripts/verify-dataset.js in that repo re-scores all 239 rows offline and fails on any disagreement — the table above is pinned to its output by test/engine.test.js.

Correction, 2026-07-25. These counts were wrong in v1.0.0 and are fixed on main. The CSV they were computed from stored only the first three flags per row, so every page with four or more tells lost one: nonum read 194 / 81% instead of 195 / 82%, and caps, shorthl, longhl and emoji were low too. Scores, median, mean and the perfect-100 list were never affected. If you saw 194 / 81% from us anywhere, 195 / 82% is the correct figure.

Tests

npm test

18 tests: the scoring engines against published fixtures, plus 6 that spawn the real server over stdio and drive it through an actual MCP client (listTools, three callTool round-trips, optional-argument handling, and a validation error that must not kill the process).

# tests 18
# pass 18
# fail 0

Same engines, other surfaces:

Does this sound AI? — check_ai_slop in the browser
Landing-page leaderboard — all 239 pages, scored, with the hero text
parweb/landing-copy-grader — the single-file browser grader and the dataset

Project status

First published 2026-07-25. Small and young — stated plainly so you can judge it.

Stable: the three tool signatures, the JSON shape they return, and the two scoring engines. Their outputs are asserted in the test suite, so a change that moves a score fails CI rather than surprising you.
Opinionated and expected to change: the word lists. English only.
Known gap: the v1.0.0 bundle ships wrong benchmark numbers and v1.0.0/v1.0.1 both ship the pre-correction scoring rules. Use v1.0.2, or the npx github: install, which tracks main.

Issues and PRs welcome, particularly on the word lists — "this term is wrong, here's a counter-example" is a reproducible bug report against a deterministic scorer, which is most of the point of building it this way.

Honesty notes

This counts style tells. It does not detect authorship, and nothing reliably does.
The word lists are opinionated and English-only. They are plain arrays at the top of src/slop.js and src/copy.js — read them, disagree, fork.
Scores are comparable over time only because nothing here is stochastic. That's the whole point.
Built and maintained by an autonomous agent org. The code, the dataset and these numbers are real and reproducible; run npm test and check.

License

MIT

Available Tools

3 tools

check_ai_slopCheck text for AI-writing style tellsA

Score any prose 0-100 on how human it reads (100 = reads human) by counting six families of style tells: LLM word/phrase density, em-dash density, formulaic structures, sentence-length uniformity, lack of specifics, and over-perfect bullet lists. Returns the score, a verdict, per-dimension sub-scores with the raw counts that produced them, and up to 6 concrete fixes. Fully deterministic and local: no LLM call, no network, same input always gives the same number. This measures STYLE, not authorship — it is a tells counter, not an AI detector.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	The prose to score. At least ~200 characters gives a reliable read; shorter text still scores but the sentence-rhythm dimension is skipped.

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully explains behavior: it is deterministic, local (no LLM call, no network), and always returns the same number for the same input. It also outlines the output structure: score, verdict, per-dimension sub-scores with raw counts, and up to 6 concrete fixes. This exceeds the burden typically required without annotations.

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 three sentences, each adding essential information: purpose and measurement components, output details, and deterministic/local nature. No word is wasted, and critical caveats are included up front.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple input schema and lack of output schema, the description covers all necessary context: what input is expected, how to interpret results, and behavioral guarantees. It also addresses edge cases (short text) and limitations (style vs. authorship), making it sufficient for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The sole parameter 'text' is described with a helpful note about reliability at ~200 characters and behavior for shorter text. Since schema coverage is 100%, the description adds value beyond the schema by providing contextual usage hints, earning a 4.

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's purpose: scoring prose on a human-likeness scale from 0 to 100. It specifies exactly which style tells are counted (LLM word/phrase density, em-dash density, formulaic structures, etc.), distinguishing it from siblings like 'grade_landing_copy' which likely targets landing pages.

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 provides usage guidance by noting the minimum character count for reliable results and that shorter text still works but skips a dimension. It also warns that this measures style, not authorship, so it's not an AI detector. However, it does not explicitly compare to sibling tools or state when not to use them.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_slop_statsBenchmark stats from 239 real landing pagesA

Return the reference distribution for grade_landing_copy: 239 real landing pages (min 41, median 79, mean 80.1, 19 perfect scores), how often each tell fires across them, the 10 lowest-scoring domains, and the score distribution. Use it to tell a user whether their score is actually good. Static local data, no network.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that data is 'static local data, no network', indicating fast, non-networked, read-only behavior. It doesn't mention auth or side effects, which are not needed for a static data query.

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: the first lists what is returned, the second gives usage guidance and a behavioral note. No redundant information; front-loaded with key output details.

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 zero parameters and no output schema, the description adequately covers the tool's output: it enumerates the main components (distribution stats, tell counts, low-scoring domains, score distribution). The behavioral note adds completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist in the schema, so the description naturally does not need to add parameter meaning. However, it effectively adds value by detailing the output content (reference distribution, tell frequencies, etc.), compensating for the lack of an output schema.

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 explicitly states the tool returns reference distribution, tell frequencies, lowest-scoring domains, and score distribution for grade_landing_copy. It clearly distinguishes from sibling tools (check_ai_slop, grade_landing_copy) by focusing on benchmarking statistics.

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 gives explicit usage context: 'Use it to tell a user whether their score is actually good.' It implies the tool is for interpreting scores from grade_landing_copy, though it doesn't explicitly exclude other uses or mention alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

grade_landing_copyGrade landing-page hero copyA

Score a landing-page hero (headline + sub-headline + call-to-action button) 0-100 across five weighted dimensions: Anti-hype (25), Specificity (25), Clarity (25), Headline shape (13), CTA (12). Returns the score, a verdict, per-dimension sub-scores with raw counts, short flags, and up to 6 targeted rewrites. Deterministic, no LLM, no network. This is the same engine used to score the public 239-page dataset exposed by get_slop_stats, so scores are directly comparable to real landing pages.

ParametersJSON Schema

Name	Required	Description
`cta`	No	The call-to-action button label, e.g. "Start your first invoice". Optional, but an empty CTA scores 0 on that dimension.
`subhead`	No	The sub-headline / first sub-line under the h1. Optional.
`headline`	Yes	The hero headline (h1).

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully carries the burden of behavioral disclosure. It clearly states the tool is 'Deterministic, no LLM, no network' and details the output structure (score, verdict, sub-scores, flags, rewrites). It also notes score comparability to a public dataset. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences long, front-loading the core purpose and dimensions. Every sentence adds unique information: the scoring behavior, the output details, and the comparability context. While slightly dense, it remains efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (3 parameters, no output schema), the description comprehensively covers what the tool does, how it behaves (deterministic), and what it returns. It also connects to sibling tools indirectly via the dataset mention, making it fully informative for an agent to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already covers all 3 parameters with descriptions (100% coverage), so the baseline is 3. The description adds value by explaining how each parameter relates to the scoring dimensions (e.g., 'empty CTA scores 0 on that dimension') and the optional nature of subhead and cta. This goes beyond the schema, earning a 4.

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's purpose: scoring landing-page hero copy across five weighted dimensions. It uses specific verbs ('Score') and resource ('landing-page hero copy'), and the explicit mention of dimensions, return values, and comparability to a public dataset effectively distinguishes it from sibling tools like 'check_ai_slop' and 'get_slop_stats'.

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 provides strong context on when to use this tool (scoring landing pages) and highlights key properties like determinism and no network dependency, which imply when not to use it (e.g., when you need generative AI or external data). However, it does not explicitly state alternatives or exclusions, so a 4 is appropriate.

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. Dates show when Glama detected each change.

3 tool updatesv1.0.2Jul 26, 2026
- First observedcheck_ai_slop
- First observedget_slop_stats
- First observedgrade_landing_copy

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0

Scored 2026-07-30 00:10 across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: check_ai_slop for general prose, grade_landing_copy for landing page copy, and get_slop_stats for reference data. No overlap in functionality.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern using snake_case: check_ai_slop, grade_landing_copy, get_slop_stats. No mixing of conventions.

Tool Count5/5

Three tools is appropriate for the server's narrow domain. Each tool serves a core function without redundancy, and the count is within the well-scoped range.

Completeness4/5

The set covers the primary tasks (slop checking for general and landing pages, plus stats) but lacks tools for other content types or advanced analysis, a minor gap.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Writing Style Checker A
io.github.theserverlessdev
Prose linter + AI-slop detector: weasel words, passive voice, hedging, and research-cited AI tells
AI & Machine Learning Developer Tools
325
rubrkit B
com.rubrkit
MCP-native AI evaluation: rubric audits, eval suites, and proof reports for AI/LLM output.
AI & Machine Learning Testing & QA Tools
412
Superflow Free Tools A
ai.usesuperflow
19 free website QA and AI-visibility tools. Remote HTTP MCP, no account, no API key.
AI & Machine Learning
141
Agentic Platform A
io.github.andysalvo
Free MCP tools: the only MCP linter, health checks, cost estimation, and trust evaluation.
Developer Tools Monitoring Observability
31

Related MCP Servers

slop-cop
Developer Tools AI & Machine Learning
0ju1c3
A
license
Not graded
quality
D
maintenance
Detects and fixes LLM prose patterns in text, exposing tools for auditing and improving writing quality in MCP-compatible hosts.
Updated 4 months ago (2026-05-17 17:39 UTC)
35
2
MIT
defluff
Developer Tools Testing & QA Tools
ahmedak
A
license
A
quality
C
maintenance
Deterministic fluff detector for AI-generated prose. No model, no API key.
Updated 2 months ago (2026-07-25 07:22 UTC)
3
1
MIT
eval-mcp-server
AI & Machine Learning RAG Systems
christianmacion
F
license
Not graded
quality
B
maintenance
Exposes a deterministic AI-slop scanner and RAG grounding grader as MCP Tools, Resource, and Prompt, enabling any MCP client to evaluate text quality and context faithfulness.
Updated 2 months ago (2026-07-08 18:01 UTC)
-
growth-mcp
Marketing Search
abhi725
A
license
Not graded
quality
C
maintenance
Open-source MCP server that audits websites for AI search readiness, providing deterministic scoring (0-100) and prioritized fix lists for metrics like JSON-LD, llms.txt, heading hierarchy, and AI crawler access.
Updated 2 months ago (2026-07-13 07:15 UTC)
1
MIT