DEV Community: Mohab Abdelkarim

Best AI Detector APIs in 2026: A Developer's Comparison (With Working Code)

Mohab Abdelkarim — Mon, 31 Aug 2026 23:56:18 +0000

If you run a platform that accepts user-submitted text, an LMS, a publishing pipeline, a marketplace, a support system, you are already processing AI-generated content whether or not you built anything to handle it. The question stopped being whether to detect it and became which API to wire in and what to do with the response.

This is a comparison of the AI detector APIs worth integrating in 2026, with real endpoints and runnable code for each. The evaluation criteria are the ones that actually matter in production: consistency across repeated scans, behavior on edited and paraphrased text, false-positive rate, and how much integration work the response format saves you.

What an AI Detector API Actually Returns
The Evaluation Criteria That Matter
Proofademic API
GPTZero API
Copyleaks API
Accuracy vs Consistency: The Metric Most Comparisons Get Wrong
Integration Patterns That Work
Handling False Positives Without Building a Support Nightmare
Verdict
FAQs

1. What an AI Detector API Actually Returns

An AI detector API takes text and returns a probability estimate, not a verdict. The distinction matters for how you design around it.

A reasonable response looks something like this:

{
  "document": {
    "ai_probability": 0.87,
    "verdict": "likely_ai"
  },
  "sentences": [
    {
      "text": "Generative systems can produce fluent academic prose with highly predictable phrasing.",
      "ai_probability": 0.94,
      "signals": {
        "predictable_phrasing": 0.88,
        "generic_structure": 0.91,
        "sentence_variation": 0.22
      }
    }
  ],
  "words_processed": 412
}

Two things to note before you write any logic around this.

The document-level float is what most people build on, and it is the least useful field in the payload. A 0.87 and a 0.99 both round to "flag it," but they are different signals, and collapsing them into a boolean on ingestion throws away information you will want later when someone disputes a flag.

The sentence array is where the actual value is. A single document percentage forces an all-or-nothing decision. A sentence-level breakdown lets you build a review UI that shows a human exactly which passages triggered the score, which is the difference between a reviewer who can act on the result and one who has to take it on faith.

What none of these APIs do, regardless of marketing copy: prove authorship, identify which model generated the text, see the user's prompt history, or determine intent. Every one of them estimates likelihood from statistical patterns. Build accordingly.

2. The Evaluation Criteria That Matter

Headline accuracy numbers are close to useless for comparing these APIs, for reasons covered in section 6. Here is what to actually check.

Probability output, not binary labels. An API returning a flat "AI" or "human" is manufacturing certainty it does not have and removing your ability to build tiered responses.

Sentence-level granularity. Determines whether you can build a useful review interface or just a number nobody trusts.

Stability across edits. Most real-world text is edited, paraphrased, or partially rewritten. An API whose score swings from 0.95 to 0.03 after a few sentence tweaks is not giving you a signal you can automate against. Good behavior is gradual degradation as text is modified.

False-positive rate, with a stated methodology. This is the number that will generate your support tickets. Any vendor citing a false-positive rate should tell you what set it was measured on.

Response structure that saves integration work. Whether you can drop the payload into a dashboard or have to build your own aggregation layer on top of it.

Auth and rate limits documented clearly. Self-explanatory, and surprisingly often not the case.

3. Proofademic API

Proofademic's detection suite went from early access to generally available over the course of 2026, and it is now a multi-endpoint platform rather than a single detector: AI text detection, AI image detection, plagiarism checking, and a grammar checker, with keys and usage managed at platform.proofademic.ai and references at docs.proofademic.ai.

Auth is a simple X-API-Key header. Here is the image detector, which has the most publicly documented request shape:

curl -X POST \
  https://developer-portal.proofademic.ai/api/image-detector/predict/ \
  -H "X-API-Key: YOUR_API_KEY" \
  -F "file=@campus.jpg"

{
  "prediction": "real",
  "confidence": 0.9964,
  "probabilities": {
    "real": 0.9964,
    "fake": 0.0013,
    "inpainting": 0.0022
  }
}

The inpainting class is worth calling out. Most image detectors give you a real-or-fake binary, which is not the distinction that matters most in practice. A photo that is genuine except for one edited region is a different moderation case from a fully generated image, and getting that as a separate probability rather than inferring it from a middling confidence score is a meaningful difference if you are building review workflows.

For text detection, the API returns document-level confidence paired with sentence-level evidence, which is the structure section 1 argued for. Full request and response formats are in the API reference rather than reproduced on the marketing site, so check docs.proofademic.ai/api-reference/detector before building against it.

The false-positive number. Proofademic publishes a 0.2 percent document-level false-positive rate from a March 2026 evaluation on a held-out set of 4,200 fully human-authored academic texts. That is a specific claim with a stated methodology and sample size, which puts it in a different category from an unqualified "99% accurate" banner. Worth noting the scope: it is measured on academic writing, which is what the model is calibrated for. Treat it as a strong signal for academic and editorial use rather than a universal figure.

Where it fits. Academic calibration is the differentiator, tuned for citation-heavy essays, technical papers, and formal prose, which are exactly the writing styles that trip up general-purpose detectors. Coverage spans 23 languages and it includes Paraphrase Shield for rewritten AI text. Plans run from a free 1,000-word one-time scan up to Professional at $45/month for 600,000 words and 25,000 words per scan.

Watch out for. The independent picture is more mixed than the vendor number. One third-party review found human samples scoring 13 and 19 percent AI rather than zero, and a mixed human-AI sample landing at 77 percent, which is arguably high for genuinely blended text. Neither result is disqualifying, but it is a reminder to set your own thresholds from your own data rather than inheriting the vendor's.

4. GPTZero API

GPTZero is the most widely deployed detector in education, which matters practically: if your users are already familiar with a score from somewhere, it is often this one. The API offers sentence-level highlighting, multi-language support, and mature documentation with a large installed base behind it.

curl -X POST https://api.gptzero.me/v2/predict/text \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "document": "Your text here",
    "multilingual": false
  }'

Watch out for. GPTZero publicly disputed a University of Chicago Booth benchmark in January 2026, arguing the researchers queried the wrong API field, and states a corrected re-run shows a 0.05 percent false-positive rate with 99.3 percent recall. Read closely, the rebuttal emphasizes recall rather than directly matching the lowest measured false-positive rates in that study, so the competing claims are not fully in conflict even though they are framed that way. Verify against your own data before treating either number as settled.

5. Copyleaks API

Copyleaks is the enterprise pick, less a pure AI detector than a content authenticity platform: plagiarism and AI detection from both text and file uploads, broad language coverage, and native LMS integrations already built for Canvas, Moodle, Blackboard, Brightspace, Schoology, Sakai, and Edsby.

Auth is OAuth-style rather than a static key, which is more setup but better for multi-tenant deployments:

# 1. Get a token
curl -X POST https://id.copyleaks.com/v3/account/login/api \
  -H "Content-Type: application/json" \
  -d '{"email": "YOUR_EMAIL", "key": "YOUR_API_KEY"}'

# 2. Submit a scan with the returned token
curl -X PUT https://api.copyleaks.com/v3/scans/submit/file/SCAN_ID \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "base64": "BASE64_ENCODED_CONTENT",
    "filename": "submission.txt",
    "properties": {
      "webhooks": { "status": "https://your-app.com/webhook/{STATUS}" }
    }
  }'

Note the webhook-first design. Copyleaks is built around async submission with callback delivery rather than synchronous responses, which is the right architecture at institutional volume but more infrastructure to stand up if you just need to score a paragraph.

Where it fits. Universities and large publishers that need plagiarism and AI detection running through one system rather than stitching two vendors together. Overkill for most standalone products.

6. Accuracy vs Consistency: The Metric Most Comparisons Get Wrong

The first question everyone asks is which API is most accurate. It is the wrong question, and understanding why will save you from picking based on a meaningless number.

Accuracy assumes a clean ground truth: this text is AI, this text is human. Most real content does not sort that way. It is AI-drafted and human-edited, or human-written and AI-polished, or rewritten three times by both. There is no universal label two detectors are obligated to agree on for that text. Two APIs can return different scores on the same input and both be defensible.

Consistency is the measurable property that actually predicts whether you can build on an API:

Same text, multiple scans, similar results
Small edits produce small score changes
Rewriting degrades the score gradually rather than cliff-edging
No 0.95 to 0.03 swings from a two-sentence change

You can test this yourself in about twenty minutes, and you should, because no vendor publishes it:

import os
import requests

API_URL = "https://api.example-detector.com/v1/detect"
HEADERS = {"X-API-Key": os.environ["DETECTOR_API_KEY"]}

def score(text: str) -> float:
    r = requests.post(API_URL, headers=HEADERS,
                      json={"text": text}, timeout=15)
    r.raise_for_status()
    return r.json()["document"]["ai_probability"]

def consistency_check(base_text: str, edits: list[str]) -> None:
    """Score progressively edited versions to see how the API degrades."""
    baseline = score(base_text)
    print(f"baseline: {baseline:.3f}")

    for i, edited in enumerate(edits, start=1):
        s = score(edited)
        delta = abs(s - baseline)
        flag = "  <-- unstable" if delta > 0.4 else ""
        print(f"edit {i}: {s:.3f} (delta {delta:.3f}){flag}")

# Run the same text 5x to check scan-to-scan variance too
for _ in range(5):
    print(score(base_text))

Run that against a trial key for each candidate API with your own representative content. The results will tell you more than every accuracy claim on every vendor's homepage combined.

7. Integration Patterns That Work

Wrap the call with a timeout and treat non-200s as first-class. If detection sits in a submission flow, a hung request must never block the user from submitting:

async function detectAiContent(text) {
  const controller = new AbortController();
  const timeout = setTimeout(() => controller.abort(), 10000);

  try {
    const response = await fetch(process.env.DETECTOR_URL, {
      method: "POST",
      headers: {
        "X-API-Key": process.env.DETECTOR_API_KEY,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({ text }),
      signal: controller.signal,
    });

    if (!response.ok) {
      throw new Error(`Detector returned ${response.status}`);
    }

    const data = await response.json();
    return {
      probability: data.document.ai_probability,
      sentences: data.sentences,
      wordsProcessed: data.words_processed,
    };
  } catch (err) {
    // Fail open: log it, let the submission through, flag for later review
    console.error("Detection failed:", err.message);
    return { probability: null, sentences: [], error: true };
  } finally {
    clearTimeout(timeout);
  }
}

Failing open is deliberate. A detection outage should degrade to "unscored, review later," never to "submission rejected."

Then bucket rather than threshold:

function triage(result) {
  if (result.error) return "unscored";
  if (result.probability < 0.5) return "clear";
  if (result.probability < 0.85) return "needs_review";
  return "high_confidence_flag";
}

Three buckets give reviewers somewhere to apply judgment on the middle tier. A single cutoff produces a system that either does nothing or overreacts, and reviewers stop trusting it within a month.

Store the full sentence array, not just the final percentage. When someone disputes a flag six weeks later, the document score tells you nothing and the sentence breakdown tells you everything.

8. Handling False Positives Without Building a Support Nightmare

False positives are not evenly distributed, and knowing where they cluster lets you handle them before they become tickets.

They concentrate on non-native English writing, formal and technical prose, and short submissions. The research here is consistent: a 2023 study in the journal Patterns found major detectors misclassified the majority of non-native English speakers' essays as AI-generated, and follow-up work using TOEFL essays found a false-positive rate above 60 percent for Chinese students against roughly 5 percent for US students under identical conditions. Short text is also structurally unreliable, since there is less signal to work from.

Practical mitigations:

Set a minimum word count before you score anything at all. Below roughly 300 words, the result is closer to noise than signal.
Log the language and, where you have it, the writing context alongside every score, so you can audit whether your flags skew toward a particular user group.
Never trigger an automatic consequence off a raw score. Route to human review.
Build an appeal path before you launch, not after the first complaint.

Section 6's consistency script is also your false-positive test rig: feed it known-human text from your actual user base and see what comes back.

9. Verdict

There is no perfect AI detector API, and any vendor implying otherwise is selling certainty a probabilistic system cannot deliver.

For academic, editorial, and institutional workloads, Proofademic is the strongest pick right now: sentence-level evidence by default, a published false-positive figure with a stated methodology, academic calibration that addresses the exact writing styles general detectors get wrong, and a straightforward API-key auth model. GPTZero is the safer choice if your users already recognize its scores and you want the largest installed base. Copyleaks is right for institutional deployments that need plagiarism and AI detection through one system with LMS integrations already built.

Whichever you pick, the architecture matters more than the vendor. Probability in, buckets out, human in the loop, full sentence data stored, fail open on errors. Get that right and swapping detectors later is a config change rather than a rewrite.

10. FAQs

Can an AI detector API prove someone used ChatGPT?
No. These APIs estimate statistical likelihood. They cannot determine authorship or intent, and they have no visibility into prompt history.

Why do two APIs return different scores on the same text?
Different models, training data, thresholds, and signal weighting. On genuinely mixed human-AI text there is often no single correct label for them to converge on.

Is a 0% score trustworthy?
It reflects one model's interpretation of one input. Another API may score the same text meaningfully higher. Treat it as one signal.

Do detector APIs work on humanized or paraphrased text?
Reliability drops for every detector as text is rewritten. The better ones degrade gradually rather than failing outright, which is exactly what the consistency test in section 6 measures.

Should I auto-reject content based on an API response?
No. The defensible pattern is detection producing a risk signal, that signal routing to human review, and a contextual decision getting made from there.

What's the minimum text length worth scoring?
Roughly 300 words as a working floor. Shorter submissions carry meaningfully higher false-positive risk across every detector.

Setting Up Walter MCP in Cursor and Windsurf: The Complete Guide

Mohab Abdelkarim — Thu, 27 Aug 2026 23:27:58 +0000

If you're running content operations through Cursor or Windsurf instead of a browser tab, you've probably already found yourself wanting Walter's humanizer and detector available as tools the agent can actually call, not something you paste text into separately. This guide covers both pieces of that setup: the Skills that tell the agent what to do, and the MCP connector that gives it the tools to actually do it.

Two Pieces, Not One
Installing Walter Skills in Cursor and Windsurf
Connecting the Walter MCP Server
Verifying the Connection
Installing a Single Skill Instead of All 12
A Note on waltermcp.com
Troubleshooting
Conclusion
FAQs

1. Two Pieces, Not One

This is the single most common point of confusion, and it's worth getting straight before touching a config file.

Walter Skills are markdown instruction files. Once loaded into a project, they tell your agent how to approach a task, when to humanize, when to lock keywords, what format to return. They don't do anything on their own.

Walter MCP is the actual tool connector. It's what lets your agent call Walter's humanizer, detector, and keyword-preservation functions for real, rather than just knowing it's supposed to.

Straight from the walter-skills repo itself: the skills give the agent instructions, but without the MCP connector, it can follow the prompts and still not be able to perform the humanization or detection steps. You need both pieces for this to actually work end to end, not just one.

2. Installing Walter Skills in Cursor and Windsurf

This part is a single command, and it's the same command regardless of which editor you're using, since both are supported through the same registry.

npx skills add walterwritesai/walter-skills

Run that from your project root, in either Cursor's or Windsurf's integrated terminal. It pulls all 12 Walter Skills from Skills.sh, Vercel's open Skills registry, and installs them for the agent to pick up automatically. This is the same install path listed directly in the walter-skills GitHub repo, which confirms Claude Code, Cursor, Windsurf, and more than 60 other agents as supported through this route.

Here's what you get with that one command:

Code	Skill	For
SK-01	SEO Content Writer	General SEO content
SK-02	Agency QC Pipeline	Teams running drafts through multiple writers
SK-03	Local SEO Machine	City and service-page templates at scale
SK-04	Content Repurposer	Turning one piece into threads, posts, newsletters
SK-05	E-commerce Engine	Batch product descriptions and listings
SK-06	Newsletter Writer	Weekly newsletter authoring
SK-07	Programmatic SEO	Hundreds of templated pages from a CSV
SK-08	Brand Voice Adapter	Keeping tone consistent across writers
SK-09	Content Refresh	Updating old posts without losing rankings
SK-10	Lead Magnet Writer	Multi-page guides and whitepapers
SK-11	Social Media Manager	Platform-native posts from one source
SK-12	Documentation Writer	Technical docs, code blocks preserved exactly

If this is your first time using the Skills.sh registry in either editor, restart the editor after the install finishes. Both Cursor and Windsurf read their skill and MCP configuration at launch, so a running session won't always pick up a fresh install automatically.

3. Connecting the Walter MCP Server

This is the piece that actually gives the agent working tools, and it's a standard remote MCP server connection, which both editors support the same general way, just with slightly different config file locations and field names.

Walter's MCP server address is:

mcp-server.walterwrites.ai/mcp

In Cursor, add it to .cursor/mcp.json in your project root, or your global Cursor MCP settings if you want it available across every project:

{
  "mcpServers": {
    "walter": {
      "url": "https://mcp-server.walterwrites.ai/mcp"
    }
  }
}

You can also add it through the UI directly: open Cursor Settings, go to the MCP section, and add a new server using that same URL. Cursor handles the OAuth handshake automatically if the server requires it.

In Windsurf, the config file lives at ~/.codeium/windsurf/mcp_config.json, and the field name is different, which is the single most common mistake when copying a config between the two editors:

{
  "mcpServers": {
    "walter": {
      "serverUrl": "https://mcp-server.walterwrites.ai/mcp"
    }
  }
}

Windsurf uses serverUrl, not url. If you copy a working Cursor config straight into Windsurf without changing that field name, the server won't connect, and there's usually no obvious error message pointing you at why.

A quick honest note here: this MCP server address and the Claude-specific setup instructions (Claude → Settings → Connectors) are confirmed directly from Walter's own ecosystem. The Cursor and Windsurf config shown above follows the standard, documented way both editors connect to any remote MCP server, applied to Walter's address specifically. If it doesn't connect on the first try, check docs.walterwrites.ai for the most current setup steps before assuming your config is wrong.

4. Verifying the Connection

Once both pieces are in place, restart your editor and try a simple test prompt in a project where the skills are installed:

Humanize this sentence and show me the detection score before and after: "In today's rapidly evolving digital landscape, organizations must strategically leverage innovative technologies to optimize operational efficiency."

If the connection is working, the agent should actually call Walter's tools and come back with a rewritten sentence plus real before-and-after scores, not just a rewritten sentence with no scoring attached. If it only rewrites without scoring anything, the Skills are loaded but the MCP connector isn't, which is exactly the two-pieces problem from the first section.

In Cursor, you can also check connection status directly under Settings > Tools & MCP. In Windsurf, the MCP panel in Cascade shows connection status for each configured server.

5. Installing a Single Skill Instead of All 12

If you only need one workflow, the local SEO machine for a multi-location client, say, you don't need to install all 12 at once:

npx skills add walterwritesai/walter-skills --skill walter-local-seo

Swap in any of the skill slugs from the table above (walter-seo-writer, walter-agency-qc, walter-repurposer, and so on) to install just that one.

6. A Note on waltermcp.com

If you go looking for more Walter MCP setup material, you'll likely land on waltermcp.com, a community-run guide, not an official Walter Writes AI site. It's a genuinely useful resource, with a library of copy-paste prompts and walkthroughs for the same Skills covered here, but it's worth treating as a secondary reference rather than the source of truth.

As one concrete example of why that distinction matters: at the time of writing, waltermcp.com's own FAQ states Walter currently only supports English, with other languages on the roadmap, while Walter's official product pages describe support for dozens of languages across its humanizer and detector. That's exactly the kind of gap that can happen when a community resource doesn't get updated at the same pace as the product itself. Use waltermcp.com for the prompt ideas and workflow inspiration, but check Walter's own docs for anything you're relying on to be current.

7. Troubleshooting

Server shows as connected but nothing happens when you ask the agent to humanize something. This is almost always the two-pieces issue from section one. Confirm the Skills actually installed with npx skills add walterwritesai/walter-skills and that the MCP server shows as connected in your editor's settings, not just one or the other.

Windsurf won't connect even though the same config works in Cursor. Check the field name first. url works in Cursor, Windsurf needs serverUrl. This single difference causes most cross-editor config failures.

Skills don't show up after installing. Restart the editor. Both Cursor and Windsurf load skill and MCP configuration at launch, not while a session is already running.

JSON config won't save or throws an error. A trailing comma after the last entry in mcpServers is the most common culprit. Validate the file with a JSON linter before saving if you're editing it by hand.

8. Conclusion

The actual setup here is short: one terminal command for the Skills, one config entry for the MCP connector, and a restart in between. The part that actually trips people up isn't the technical steps, it's not realizing these are two separate systems that both need to be in place before anything works end to end. Get the connector and the Skills running together, and Cursor or Windsurf starts drafting, humanizing, and scoring content in the same agent loop you're already using for code.

9. FAQs

Do I need both Walter Skills and Walter MCP, or just one?
Both. Skills give the agent instructions for how to approach a task. The MCP connector gives it the actual tools to humanize and detect. Without the connector, the agent can follow the instructions but can't perform the humanization or detection steps themselves.

Does the same install command work in both Cursor and Windsurf?
Yes. npx skills add walterwritesai/walter-skills installs the same 12 skills through the Skills.sh registry regardless of which editor you run it in.

Why didn't my Windsurf config work when I copied it from Cursor?
Check the field name. Cursor uses url for a remote MCP server, Windsurf uses serverUrl. Copying a Cursor config into Windsurf without updating that field is the most common reason a connection silently fails.

Is waltermcp.com the official place to set up Walter's MCP connector?
No, it's a community-run guide, not run by Walter Writes AI. It's a useful secondary resource for prompts and workflow ideas, but check Walter's own documentation for anything setup-related that needs to be current.

Can I install just one Skill instead of all 12?
Yes, with the --skill flag: npx skills add walterwritesai/walter-skills --skill <skill-slug>, using the slug for whichever skill you need.

What should I test first after setting this up?
A simple before-and-after prompt, asking the agent to humanize a sentence and show the detection score on both versions. If it rewrites the text but never shows a score, the MCP connector isn't actually connected yet, even if the Skills are installed.

How to Add AI Content Detection to Your App With an API (Developer Guide)

Mohab Abdelkarim — Wed, 26 Aug 2026 22:57:54 +0000

If your product accepts user-submitted text, an essay, a cover letter, a marketplace listing, a forum post, you're already dealing with AI-generated content whether you've built anything to handle it or not. The question isn't really whether to add detection anymore. It's how to wire it in without turning it into a multi-week project.

This guide walks through adding AI content detection to a real app using Walter's AI Detector API: getting a key, making your first request, parsing the response correctly, and handling the part everyone skips, what to actually do when the score is wrong.

What You're Building
Getting an API Key
Making Your First Request
Understanding the Response
Wiring It Into Your App
Handling False Positives Properly
Common Integration Patterns
Pricing and Scaling
Conclusion
FAQs

1. What You're Building

By the end of this, you'll have a working function that takes a string of text, sends it to Walter's detector, and gets back a calibrated probability score you can act on, flag for review, log, or display, depending on what your app actually needs to do with it.

The API scores text generated by any major model, GPT-4, Claude, Gemini, Llama, and others, and returns a probability rather than a flat yes-or-no verdict, which matters more than it sounds like once you get to the section on false positives.

2. Getting an API Key

Sign up at platform.walterwrites.ai to get a key. Walter's infrastructure is SOC 2 Type I compliant, worth knowing if you're integrating this into anything that touches user data under a compliance requirement of your own, like an education product handling FERPA-covered records.

Keep the key server-side. This is a backend integration, not something you call directly from client-side JavaScript, for the same reason you wouldn't expose any other secret API key in a browser bundle.

3. Making Your First Request

The core endpoint is a single POST request:

curl https://api.walterwrites.ai/v1/detect \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "text": "In todays rapidly evolving digital landscape, organizations must strategically leverage innovative technologies to optimize operational efficiency.",
    "language": "en"
  }'

That's the whole request. Text in, a language hint if you have one, standard bearer token auth. No batching setup, no async job queue required for a single check like this one.

4. Understanding the Response

A successful call returns something like this:

{
  "id": "det_4k2p9x1m3",
  "status": "completed",
  "model": "detector-v3",
  "created_at": "2026-06-12T13:45:00Z",
  "output": {
    "ai_probability": 0.87,
    "words_processed": 12
  },
  "usage": {
    "credits_used": 12
  }
}

ai_probability is the field you'll build most of your logic around. It's a float between 0 and 1, not a binary flag, which is a deliberate design choice worth keeping intact in your own app rather than collapsing it into a boolean the first chance you get. A 0.87 and a 0.99 both round up to "flag this," but they're not the same signal, and you'll want that distinction later if you ever need to explain a decision to a user.

credits_used scales with word count, so logging it per request from day one saves you from guessing where your monthly quota went once volume picks up.

5. Wiring It Into Your App

Here's a minimal Node.js wrapper that handles the request, a timeout, and a couple of the error cases you'll actually hit in production:

async function detectAiContent(text, language = "en") {
  const controller = new AbortController();
  const timeout = setTimeout(() => controller.abort(), 10000);

  try {
    const response = await fetch("https://api.walterwrites.ai/v1/detect", {
      method: "POST",
      headers: {
        "Authorization": `Bearer ${process.env.WALTER_API_KEY}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({ text, language }),
      signal: controller.signal,
    });

    if (!response.ok) {
      throw new Error(`Detector API returned ${response.status}`);
    }

    const data = await response.json();
    return {
      probability: data.output.ai_probability,
      wordsProcessed: data.output.words_processed,
      creditsUsed: data.usage.credits_used,
    };
  } catch (err) {
    if (err.name === "AbortError") {
      throw new Error("Detector API request timed out");
    }
    throw err;
  } finally {
    clearTimeout(timeout);
  }
}

And the Python equivalent, for anyone wiring this into a Django or FastAPI backend instead:

import os
import requests

def detect_ai_content(text: str, language: str = "en") -> dict:
    response = requests.post(
        "https://api.walterwrites.ai/v1/detect",
        headers={
            "Authorization": f"Bearer {os.environ['WALTER_API_KEY']}",
            "Content-Type": "application/json",
        },
        json={"text": text, "language": language},
        timeout=10,
    )
    response.raise_for_status()
    data = response.json()
    return {
        "probability": data["output"]["ai_probability"],
        "words_processed": data["output"]["words_processed"],
        "credits_used": data["usage"]["credits_used"],
    }

Both versions treat a timeout and a non-200 response as first-class cases, not afterthoughts. If this call sits in the middle of a submission flow, a hung request shouldn't be able to block your user from submitting anything.

6. Handling False Positives Properly

This is the part most detection integrations get wrong, and it's the difference between a useful feature and a support ticket generator.

Walter's own published data on this is worth internalizing before you write any flagging logic: false positive rates typically run 4 to 12 percent at a 50 percent confidence threshold, meaning legitimate human writing gets incorrectly flagged roughly once every 10 to 25 samples. That's not a bug to route around, it's the actual behavior of probabilistic detection, and it shows up more on non-native English writing, highly formal or technical text, anything under 100 words, and heavily edited human content, since all of those reduce the natural variation detectors use as a human signal.

The practical response is a two-pass workflow, not a single hard cutoff. Flag anything above a threshold you choose based on your own risk tolerance, then have a human reviewer look specifically at the flagged cases rather than trusting the score as a final verdict. If you're building for a high-stakes context like academic integrity or hiring decisions, build in a way for the person on the other end to respond or appeal before any consequence lands, not after.

Here's what that looks like as a simple threshold wrapper around the function above:

async function reviewSubmission(text) {
  const result = await detectAiContent(text);

  if (result.probability < 0.5) {
    return { status: "clear", ...result };
  } else if (result.probability < 0.85) {
    return { status: "needs_review", ...result };
  } else {
    return { status: "high_confidence_flag", ...result };
  }
}

Three buckets instead of one binary cutoff gives your reviewers somewhere to actually apply judgment on the middle tier, instead of a system that either does nothing or overreacts every time.

It's also worth knowing this isn't a solved problem in any permanent sense. A widely cited 2023 paper by Sadasivan et al., "Can AI-Generated Text Be Reliably Detected?", makes the case that detection evasion is theoretically unbounded as models keep improving, which is part of why Walter retrains its detection models on a regular cycle against newer model outputs rather than shipping a static classifier once and leaving it alone. Build your integration assuming accuracy today isn't a permanent guarantee, and you'll avoid having to rearchitect anything when the numbers shift.

7. Common Integration Patterns

A few patterns show up repeatedly depending on what you're building.

LMS and edtech platforms typically score every submission automatically at upload time, surface a per-student dashboard for instructors, and route anything flagged into a review queue rather than an automatic penalty. If you're in this space, ask about Walter's education tier specifically, since it includes FERPA-aligned data handling and discounted volume pricing.

Content marketplaces and publishers generally flag at ingestion, before content goes live, which keeps obviously low-effort AI submissions from ever reaching an editor's queue in the first place.

HR and recruiting platforms apply this to cover letters, take-home assignments, and written interview responses. This is the context where the two-pass review workflow matters most, since a wrongly flagged candidate is a real cost to get wrong, not just a UX annoyance.

8. Pricing and Scaling

Pricing runs on monthly word quotas, which makes it straightforward to forecast against your own expected volume rather than guessing at enterprise-only pricing upfront.

Plan	Price	Included Volume
300K	$49/mo	300,000 words
1M	$129/mo	1,000,000 words
2M	$229/mo	2,000,000 words
5M	$479/mo	5,000,000 words
12M	$899/mo	12,000,000 words
25M	$1,699/mo	25,000,000 words

Higher-volume workloads and enterprise deployment needs go through a direct sales conversation rather than a fixed public tier.

9. Conclusion

Adding AI detection to a product is a smaller lift than it sounds like on paper, a single POST request gets you a working score. The part that actually takes engineering judgment is what happens after that response comes back: treating the probability as a probability, building a review path instead of a hard cutoff, and accounting for the specific conditions, short text, technical writing, non-native English, where false positives cluster. Get that part right and the integration itself is genuinely just a few hours of work.

10. FAQs

Do I need to handle async processing for single text checks?
No. A single detection request completes synchronously and returns a result directly, no polling or webhook setup required unless you're doing high-volume batch processing.

What's a reasonable false positive rate to expect?
Walter's own published data puts it at 4 to 12 percent at a 50 percent confidence threshold. Build your review workflow around that expectation rather than assuming a flag is automatically correct.

Should I ever use the AI probability score as the sole basis for an automated decision?
Not for anything with real consequences attached. The recommended pattern is a calibrated threshold that routes borderline and high-confidence flags to a human reviewer rather than triggering an automatic penalty or rejection.

Does this work on text from any AI model, or just ChatGPT?
The detector scores text generated by GPT-4, Claude, Gemini, Llama, and other major models, not just one vendor's output.

How often are the detection models updated?
Walter retrains its detection models on a recurring basis using output from newer language models as they're released, since a static classifier trained once tends to lose accuracy as the models generating text keep changing.

Is there a free way to test this before committing to a paid plan?
Sign up at platform.walterwrites.ai to get an API key and test against your own sample text before choosing a volume tier that matches your actual usage.

Walter MCP vs. Traditional AI Humanizer Workflows: Why Developers Are Switching

Mohab Abdelkarim — Mon, 10 Aug 2026 19:51:46 +0000

If you've integrated a third-party AI API into a content pipeline before, you already know the pattern. Auth headers. Rate limit handling. A conditional branch to decide whether to call a second endpoint based on the first response. Retry logic for the inevitable timeout. None of that is hard, individually, but it adds up to real code you own, test, and maintain indefinitely, for a task that's conceptually simple: check this text, fix it if it needs fixing.

MCP changes where that logic lives. Here's the actual before-and-after, not the marketing version.

The traditional workflow

Say you're building a content pipeline that drafts text, checks it for AI-detectability, and humanizes the flagged sections before publishing. Calling a humanizer's REST API directly, the shape of that integration typically looks something like this:

import requests
import time

API_KEY = "your-api-key"
BASE_URL = "https://api.example-humanizer.com/v1"

def detect(text: str) -> dict:
    resp = requests.post(
        f"{BASE_URL}/detect",
        headers={"Authorization": f"Bearer {API_KEY}"},
        json={"text": text},
        timeout=10,
    )
    resp.raise_for_status()
    return resp.json()

def humanize(text: str, preserve: list[str], mode: str = "balanced") -> dict:
    resp = requests.post(
        f"{BASE_URL}/humanize",
        headers={"Authorization": f"Bearer {API_KEY}"},
        json={"text": text, "preserve": preserve, "mode": mode},
        timeout=15,
    )
    resp.raise_for_status()
    return resp.json()

def process_draft(draft: str, keywords: list[str]) -> str:
    detection = detect(draft)
    flagged_paragraphs = [
        p for p in detection["paragraphs"] if p["score"] > 30
    ]

    if not flagged_paragraphs:
        return draft

    # Now you own the orchestration: rebuild the document from
    # flagged and unflagged sections, retry on rate limits, handle
    # partial failures, log what changed, verify preservation...
    result = draft
    for para in flagged_paragraphs:
        retries = 0
        while retries < 3:
            try:
                humanized = humanize(para["text"], preserve=keywords)
                result = result.replace(para["text"], humanized["text"])
                break
            except requests.exceptions.HTTPError as e:
                if e.response.status_code == 429:
                    time.sleep(2 ** retries)
                    retries += 1
                else:
                    raise

    return result

That's a simplified version. A production version needs proper logging, a real backoff strategy, preservation verification against the compliance response, and probably a queue if you're processing anything at volume. None of this is exotic engineering, it's just boilerplate that exists purely because two systems need to talk to each other, and you're the one who has to write, test, and maintain the glue.

The MCP workflow

Here's the same task through Walter's MCP server connected to Claude:

Draft a 1,200-word article about [topic]. Detect which paragraphs read
as AI-generated. Humanize only the flagged sections, preserving these
keywords: [keyword list]. Return the final text and a summary of what
changed.

That's it. No auth code, because the host manages the connection once, at setup, not per request. No conditional branching logic, because the LLM reads the detection result and decides what to humanize the same way it reads any other context. No retry logic you wrote, because that's handled at the protocol/host level, not in your application code. No manual response parsing, because the result comes back as part of the conversation, not a JSON blob you have to unpack.

The setup itself is one config entry:

[mcp_servers.walterwrites]
url = "https://mcp-server.walterwrites.ai/mcp"

or, in Claude's UI, adding a custom connector with a name and a URL. Done once, used indefinitely, across every conversation.

What actually changed, structurally

The real shift isn't "fewer lines of code" as a vanity metric. It's where the orchestration logic lives.

In the traditional model, your application is responsible for: deciding when to call detect, interpreting the response, deciding whether and what to call humanize on, handling failures at every step, and reassembling the final output. That's real application logic, specific to this integration, that has nothing to do with your actual product.

In the MCP model, the LLM host owns that orchestration. It decides which tool to call based on the conversation, in what order, and how to handle the response, the same general-purpose reasoning it's already doing for everything else in the conversation. Your "integration code" is a config entry pointing at a URL. The tool-selection logic that used to live in your if statements now lives in the model's reasoning, driven by your prompt instead of your source code.

This is the actual point of MCP as a protocol: instead of writing custom orchestration code for every tool you want an AI system to use, you expose the tool once, in a standard format, and let the host's own reasoning handle when and how to call it.

Side-by-side

	Traditional REST integration	Walter MCP
Auth handling	Your code, per request	Host-managed, once
Detect-then-humanize branching	Your conditional logic	Model's reasoning, driven by prompt
Retry/backoff	You write and maintain it	Handled at host/protocol level
Response parsing	You unpack JSON	Returned as conversational context
Adding a second AI client (e.g. ChatGPT)	Rewrite the integration	Same server, new client config
What you maintain long-term	Integration code + the pipeline logic	Just the pipeline logic

That last row is arguably the biggest deal for anything long-lived. A REST integration is code you own forever, it needs updating when the API changes, needs its own test coverage, needs someone who remembers why a specific retry threshold was chosen two years ago. An MCP connection is closer to infrastructure, configured once, and the burden of keeping the tool-calling logic correct shifts to the host and server maintainers rather than sitting in your repo.

Where the traditional API approach still wins

Being straight about this, since the MCP model isn't strictly better for every case.

High-throughput batch jobs outside a conversational context. If you're processing 50,000 product descriptions overnight in a cron job, you want deterministic, directly-controlled API calls in a script, not an LLM conversation orchestrating tool calls. MCP is built around a host managing a conversation; a headless batch pipeline doesn't have that conversational context to begin with. Direct API access (Walter, like most serious tools in this space, still exposes one) is the right tool here.

When you need guaranteed, deterministic control flow. LLM-driven tool selection is reliable but not deterministic in the strict sense, the model decides when to call a tool based on reasoning over the prompt. If a compliance requirement means step B must always run after step A with zero exceptions, encoding that in your own application logic with direct API calls gives you a guarantee an LLM-orchestrated flow doesn't strictly provide.

Extremely latency-sensitive paths. A direct API call has one network hop. An MCP-orchestrated flow goes through the host's reasoning loop first, which adds latency that matters in some real-time contexts and doesn't matter at all in others.

If your workflow is genuinely conversational, iterative content drafting, an agent doing multi-step reasoning, anything where a human or another agent is in the loop deciding what to do next, MCP removes real, ongoing maintenance burden. If it's a deterministic, high-volume, headless pipeline, direct API integration is still the right call, and that's true regardless of which humanizer you're using.

Migrating an existing integration

If you've already got a REST-based integration and want to move the conversational parts of your workflow to MCP without ripping everything out:

Keep the direct API integration for any headless/batch paths, that use case doesn't change.
For anything conversational or agent-driven, add the MCP server as a connector in whatever host you're using (Claude, ChatGPT Developer Mode, Codex) rather than routing those calls through your existing REST client.
Delete the orchestration code (the detect-then-humanize branching, the retry logic specific to that flow) for the paths you've moved, that's the actual payoff, not just an additional integration option sitting next to the old one.

The goal isn't running both forever. It's recognizing which parts of your pipeline are genuinely conversational (move to MCP, delete the glue code) and which are genuinely deterministic batch jobs (keep the direct API, it was never the wrong tool for that case).

FAQs

Does Walter still offer a direct REST API alongside MCP?
Yes. MCP is the right fit for conversational, host-driven workflows. Direct API access remains the better fit for headless batch processing and pipelines requiring deterministic control flow.

Is MCP slower than a direct API call?
There's more latency in an MCP-orchestrated flow than a single direct API call, since it goes through the host's reasoning loop first. For interactive, conversational use this is negligible. For latency-critical, high-frequency paths, direct API access is still the better choice.

Do I need to rewrite my whole pipeline to use MCP?
No. The two approaches are complementary, not mutually exclusive. Most teams keep direct API integration for batch/headless work and adopt MCP specifically for the conversational or agent-driven parts of their workflow.

What's the actual protocol-level benefit of MCP over a custom integration?
It solves the M×N integration problem: instead of writing custom glue code for every combination of AI host and external tool, a tool is exposed once via MCP and any compliant host can use it without additional integration work on either side.

How Walter MCP Handles Keyword Preservation at Scale (With Real Prompts)

Mohab Abdelkarim — Fri, 31 Jul 2026 00:44:18 +0000

TL;DR: Generic AI humanizers have no concept of a "protected span," they rewrite everything with equal weight, which means exact-match keywords silently get paraphrased away. Walter MCP fixes this by treating preservation as an explicit constraint passed before the rewrite runs, verified afterward with a compliance report. This post covers the actual mechanism, real prompt templates for single-article and batch (up to 25 items) use, and the specific edge cases that still break if you're not precise about them.

If you've ever run SEO content through a humanizer and found your target keyword quietly turned into a synonym, you've hit the core problem this post is about. It's not a bug in any specific tool, it's a structural consequence of how most humanization works.

Why this breaks by default

Most humanizers operate as a single, undifferentiated rewrite pass. You give them text, they give you back text that's statistically less predictable, varied sentence length, different transition words, less uniform rhythm. That's the whole mechanism. There's no concept baked into that process of "these fourteen characters must survive verbatim, everything else is fair game."

So when a rewrite model decides "best CRM for small business" reads more naturally as "top CRM for small businesses," it's not malfunctioning. It's doing exactly what it was optimized to do: produce more natural, less predictable text. It just has no idea that string was your target keyword and the whole reason the article exists.

This is the same class of problem as prompt injection or context leakage in other AI tooling contexts: the model has no privileged, protected region of its input unless you explicitly tell it one exists.

How Walter's preservation mechanism actually works

Walter MCP handles this by treating preservation as a constraint you pass explicitly before the humanization tool call runs, not something inferred from context. The flow looks like this:

1. detect(text) → paragraph-level AI-likelihood scores
2. humanize(text, preserve=[...exact strings...], flagged_only=true)
3. compliance_report → confirms each preserved string survived

The constraint list isn't a suggestion the model weighs against naturalness. It's closer to a hard filter applied to the rewrite, exact strings you list are checked against the output, and the compliance report step exists specifically because "I told it not to change X" and "X definitely didn't change" are two different claims, and only the second one is worth trusting in an automated pipeline.

The basic single-article prompt

Here's the actual prompt structure for a one-off article:

Write a 1,200-word article targeting "[exact keyword]".

Then:
1. Run detection on the draft. Show me paragraph-level scores, don't
   rewrite anything yet.
2. Humanize only the paragraphs that flagged.
3. Preserve these exact strings, character for character, including
   capitalization:
   - "[exact keyword]"
   - "[Brand Name]"
   - "[Product Name]"
4. Do not touch any links or numerical data.
5. Return a compliance report confirming each preserved string survived.

The detect-first step matters as much as the preservation list. Humanizing the whole document indiscriminately increases the surface area where something you forgot to list could get touched. Scoping the rewrite to only the flagged paragraphs shrinks that risk mechanically, not just as a style preference.

Scaling it: batch preservation across many items

Single-article preservation is straightforward. The real test is whether it holds up when you're processing 15 product descriptions or a batch of programmatic SEO pages in one pass, since that's where manual verification stops being feasible and you actually need the compliance report to be trustworthy.

Walter's batch tool handles up to 25 items per call, each with its own preservation list:

I have 15 product descriptions. For each one:

1. Humanize the description.
2. Preserve the exact product name and price for that specific item
   (see list below, one preservation set per item).
3. Flag any item scoring above 30 on detection after humanization for
   my manual review.
4. Return a per-item compliance report.

Item 1: [description] | Preserve: "[Product Name]", "[$Price]"
Item 2: [description] | Preserve: "[Product Name]", "[$Price]"
...

For programmatic SEO specifically, city-and-service landing pages being the common case, the preservation list is usually the page's exact H1 target phrase plus the service keyword:

Generate 20 local landing pages from this list of [city, service] pairs.
For each page:
1. Write a 300-word page targeting "[service] in [city]".
2. Humanize it.
3. Preserve the exact phrase "[service] in [city]" in the H1 and first
   paragraph of every single page, no exceptions.
4. Confirm in the report that phrase is present and unmodified on every
   page before returning results.

That last line matters more than it looks like it should. On a batch this size, "mostly correct" is a real failure mode, one page out of twenty silently losing its target phrase is exactly the kind of thing that doesn't get caught without an explicit per-item confirmation step.

Verifying preservation programmatically

If you're wiring this into an actual pipeline rather than running it interactively, don't just trust the compliance report text, parse it.

import re

def verify_preservation(compliance_report: str, required_terms: list[str]) -> dict:
    results = {}
    for term in required_terms:
        # crude but effective: check the term is quoted as confirmed
        # in the report text, adapt to whatever format your report returns
        pattern = re.escape(term)
        results[term] = bool(re.search(pattern, compliance_report))
    return results

This is intentionally simple, the actual point is: treat the compliance report as structured output you validate against your original constraint list, not prose you skim. If you're processing content at any real volume, that validation step is what turns "the tool says it worked" into something you can actually build an unattended pipeline around.

Where this still breaks

Being straight about the failure modes, since pretending this is bulletproof would be more dangerous than not mentioning it.

Vague terms instead of exact strings. "Preserve our brand name" is not the same instruction as "Google", capitalized exactly like that. The model has to infer what "our brand name" refers to, and inference is exactly the gap that produces inconsistent output. List exact strings, always.

Capitalization and punctuation drift. If your preservation list says google and the source content uses Google, you may get inconsistent casing across a batch, since you've effectively given two different targets across different items. Match the list to the source, exactly, not an approximation of it.

Preserved terms inside a flagged paragraph that also needs structural rewriting. This is the genuinely hard case. If a whole paragraph is flagged and needs rhythm/structure changes, the preserved term inside it has to survive a rewrite happening around it, not just avoid being touched directly. This is where the compliance report earns its keep, since this is the scenario most likely to produce a false sense of security without it.

Plural and singular mismatches. Preserving "AI humanizer" doesn't guarantee "AI humanizers" (plural) is also protected, if your content actually uses both forms, list both explicitly.

Reusable templates

Copy these directly and swap in your own values.

Single article, SEO-focused:

Write a [word count] article targeting "[keyword]". Run detection first,
humanize only flagged paragraphs, preserve "[keyword]", "[brand]", and
all links/stats exactly as written. Return a compliance report.

Batch, e-commerce:

Humanize these [N] product descriptions. Preserve each item's exact
product name and price. Flag anything scoring above [threshold] for
review. Return a per-item compliance report.

Batch, programmatic SEO:

Generate [N] pages from this [variable] list. Preserve "[fixed phrase
pattern]" in the H1 and first paragraph of every page. Confirm presence
on every single page in the report before returning results.

Brand-voice locked:

Apply these constraints to every piece in this conversation: always use
"[preferred term]" not "[avoided term]", always capitalize "[Term]".
After any humanization pass, confirm these rules held before returning
output.

If you're doing this repeatedly, these belong in a saved system prompt or a Walter Skill (a markdown file loaded into a Claude project) rather than retyped per conversation, that's a separate topic, but worth knowing the option exists once the same constraint list keeps showing up across sessions.

FAQs

Does keyword preservation slow down the humanization process?
Marginally, since the model has to check output against a constraint list rather than rewriting freely. In practice this is negligible compared to the time saved versus manually verifying keyword survival after the fact.

What happens if a preserved term genuinely can't fit naturally after a rewrite?
The compliance report should flag this rather than silently dropping the term or silently forcing awkward phrasing. If you see forced, unnatural insertion of a preserved term, that's a signal the surrounding paragraph needed a different rewrite approach, not just a workaround.

Can I preserve terms across multiple languages in one batch?
Yes, though each preserved string still needs to be listed exactly as it should appear in that specific language's version, term lists don't automatically translate or transfer between language variants in a batch.

How many items can be preserved and processed in a single batch call?
Up to 25 items per batch call, each with its own independent preservation list and settings.

One MCP Server, Three Assistants: Running Walter Across Claude, ChatGPT, and Codex

Mohab Abdelkarim — Mon, 20 Jul 2026 12:46:32 +0000

TL;DR: One MCP server, https://mcp-server.walterwrites.ai/mcp, now works across three completely different AI clients: Claude (stable, native connector support), ChatGPT (beta, via Developer Mode), and Codex (native CLI/IDE support). Same tools, same detection and humanization logic, three different setup flows. This post covers the actual config for all three, what's different about each, and why this is a genuinely interesting case study in MCP interoperability even if you don't care about Walter specifically.

Six months ago, this would've been a one-platform story. Walter's MCP server, which exposes AI text humanization and detection as callable tools, only worked inside Claude. If your team drafted in ChatGPT, or you were building internal tooling on top of Codex, you were stuck with the old copy-paste-detect-copy-paste-humanize loop that MCP exists specifically to kill.

That's no longer true, and the reason it's no longer true is a good, concrete example of what the M×N integration problem MCP was built to solve actually looks like when it's solved. One server. Three clients. Zero custom integration code written on Walter's side to support any of them.

Here's the setup for all three, the actual differences in how each client handles tool calling, and a few things that will save you time if you're setting this up yourself.

Why this is worth a post beyond "here's how to add a connector"

If you've built or used more than one MCP server, you already know the theory: implement the spec once, any compliant host can use it. What's actually interesting here is watching that promise hold up (or not) across three hosts with meaningfully different maturity levels.

Claude's MCP client implementation has been stable for a while. Tool selection is reliable, you don't need to over-specify a prompt, and the connector setup is entirely GUI-driven.

ChatGPT's MCP support (branded "Developer Mode," previously part of what OpenAI called "connectors" until a December 2025 rename to "apps") is newer and still in beta. Tool selection is noticeably less reliable, meaning you have to write more explicit prompts to guarantee it reaches for the right tool instead of falling back to something built-in like web search.

Codex has had MCP client support in the CLI and IDE extension for a while, configured through a shared config.toml, and it's the only one of the three with zero web UI involved in setup.

Same protocol. Three different levels of client maturity. If you're building your own MCP server and wondering how much you need to defensively prompt-engineer around client-side tool selection quirks, this is a useful real-world data point.

The server side, briefly

Walter's MCP server runs as a single remote, authenticated endpoint:

https://mcp-server.walterwrites.ai/mcp

It's a streamable HTTP server (not stdio), which is the relevant detail for Codex config later. It exposes two main tools relevant here, humanize and detect, both callable the same way regardless of which client is invoking them. Same server-side logic. The differences below are entirely client-side.

Setup 1: Claude (the baseline, simplest of the three)

If you've set up any MCP connector in Claude before, this is nothing new.

Settings → Connectors → click +
Select Add custom connector
Fill in:

Name: Walter Writes AI
Remote MCP Server URL: https://mcp-server.walterwrites.ai/mcp

Click Add, sign in with your Walter account, click Allow Access

That's it. No further prompt engineering required, in practice Claude reliably picks the right tool from a normal, unscaffolded prompt like:

Humanize this draft with Walter, then run detection on the result.

Setup 2: ChatGPT (beta, more moving parts)

This is currently gated to Pro and Plus accounts on ChatGPT web (plus Business/Enterprise/Education workspaces where an admin has enabled it). A few things to know before you start:

As of mid-December 2025, OpenAI renamed "connectors" to "apps." If you're looking at older docs or screenshots and can't find "Connectors" in settings, that's why.
Developer Mode gives ChatGPT full MCP client support, meaning both read and write tool calls, not the older fetch-only connector model.

Setup:

Settings → Apps → Advanced settings
Enable Developer mode
Click Create app
Fill in:

Name: Walter Writes AI
MCP Server URL: https://mcp-server.walterwrites.ai/mcp
Authentication: OAuth

Leave the Client ID/Secret fields blank, Walter's server handles the OAuth exchange automatically once you authenticate.

Check I trust this application → Create
Sign in to Walter when prompted
Confirm the app shows as connected

One more step before it's usable mid-conversation: in chat, click + → More → enable the Walter Writes connector.

The prompting gotcha

This is the part that actually matters if you want this to work reliably. Because Developer Mode is beta, ChatGPT does not consistently infer that it should call a custom tool over falling back to something built-in. A vague prompt like "make this sound more human" might silently just get ChatGPT's own rewrite instead of an actual Walter tool call.

Fix: be explicit. Name the connector, name the exact action, specify what to return, and tell it not to use web search.

Using the Walter Writes MCP connector, run the humanize action on the
draft below, then run the detect action on the result. Return the
readability score, AI score, and a short change summary. Do not use
web search.

[paste draft]

Verbose, yes. Necessary right now, also yes. Check the tool call preview in the response to confirm Walter's tools are actually what got invoked, not a built-in fallback.

Setup 3: Codex (fastest, zero UI)

If you're already comfortable in a terminal, this is the quickest of the three.

Option A, one command:

codex mcp add walterwrites --url https://mcp-server.walterwrites.ai/mcp

Option B, edit config directly. Codex stores MCP server definitions in ~/.codex/config.toml (global) or a project-scoped .codex/config.toml (only loads for directories Codex has marked trusted):

[mcp_servers.walterwrites]
url = "https://mcp-server.walterwrites.ai/mcp"

Authenticate (same OAuth flow as the other two, just CLI-triggered):

codex mcp login walterwrites

Verify:

codex mcp list

You should see walterwrites listed as active. Inside an interactive session, /mcp shows currently connected servers too.

Codex will reach for Walter's tools automatically once configured. If you want that to happen without a confirmation prompt every time, set an approval_mode on the tool (auto, prompt, or approve):

[mcp_servers.walterwrites]
url = "https://mcp-server.walterwrites.ai/mcp"
approval_mode = "auto"

For consistent behavior across a whole project without repeating instructions every session, drop a line into AGENTS.md:

Use Walter's humanize and detect tools automatically for any content
that needs AI-detection review or humanization before it's finalized.

This matters specifically for developer-facing content, README files, doc comments, CHANGELOG entries, anything written inline in a repo that might read as obviously AI-generated and would benefit from a pass before it ships.

stdio vs streamable HTTP, since it comes up

Quick clarification since this trips people up in Codex specifically: stdio servers run as a local process, spawned and piped to directly by the client. Streamable HTTP servers (what Walter uses) are remote, accessed by URL, and support OAuth or bearer token auth. That's why Walter gets added with --url in Codex rather than a local command, it's not a process Codex spawns, it's a remote endpoint Codex calls over HTTP.

Where each one actually makes sense

Not trying to force a false equivalence here, each of the three genuinely fits a different workflow:

Claude for long-form content pipelines. Tool selection just works, so it's the lowest-friction option if you're doing this regularly and don't want to think about prompt scaffolding.

ChatGPT if your team is already standardized there and switching tools just for humanization isn't worth the context switch. Budget for more explicit prompts and occasional manual tool-call confirmation until Developer Mode matures.

Codex specifically for anything developer-facing that lives inside a repo, docs, comments, generated changelogs. It's also just the fastest to set up if you're not touching a browser at all.

Common failure modes

ChatGPT: connector doesn't show up after creating it. Start a new chat. Developer Mode changes sometimes don't reflect in an existing conversation's tool list.
ChatGPT: keeps using web search instead of Walter. Prompt wasn't explicit enough, see the gotcha section above.
ChatGPT: Developer Mode isn't in Settings at all. Confirm you're on web (not mobile) and on a Pro/Plus account or a workspace where an admin enabled it.
Codex: tool call times out. Default timeout is 60s. Bump tool_timeout_sec in the server's config block if a specific call needs more.
Codex: project-level config not loading. Only loads for directories Codex has explicitly marked trusted, check that first.
Any client: OAuth won't complete. Usually a pop-up blocker or browser extension eating the redirect. Check that before assuming the server's broken.

Closing thought

The interesting part of this isn't really "Walter now works in three places." It's that it required zero server-side changes to get there, that's the actual point of MCP as a spec. What differs entirely is client-side maturity: Claude's implementation just works, ChatGPT's needs more explicit handholding right now because it's newer, and Codex trades a GUI for two terminal commands. If you're building your own MCP server, that maturity gap across hosts is worth planning around, because your users are going to hit it regardless of how well you've built your server.

Docs for all three setups: docs.walterwrites.ai. Server: walterwrites.ai.

FAQ

Does the same account work across all three?
Yes, all three authenticate against the same Walter account via OAuth. Word balance, settings, and history carry over.

Is Codex MCP support free?
The MCP client functionality itself has no separate cost, you need an active Codex/ChatGPT account with the right access tier, plus a Walter account for the humanization credits the actual tool calls consume.

Do I need a paid ChatGPT plan?
Yes, currently. Developer Mode requires Pro or Plus individually, or a Business/Enterprise/Education workspace where an admin has turned it on.

Why does ChatGPT need more explicit prompts than Claude?
Claude's MCP implementation has been stable longer and reliably infers the right tool from context. ChatGPT's Developer Mode is newer and still beta, tool selection isn't as consistent yet, so explicit naming of the connector and action is currently required for reliable behavior.

5 Real-World Use Cases for Walter MCP in Claude

Mohab Abdelkarim — Fri, 26 Jun 2026 15:05:59 +0000

Most MCP tool breakdowns stop at "here is what it does." This one goes further.

Walter MCP is an MCP server that connects Walter Writes AI directly inside Claude, bringing AI humanization, detection, and batch processing into your conversations without switching tools. If you have seen it mentioned but never understood why someone would actually build a workflow around it, this article is for you.

Below are five use cases that are working in production right now, with the logic behind each one and the prompts that make them run.

What Walter MCP Actually Adds to Claude
Quick Setup
Use Case 1: SEO Content Pipeline with Keyword Lock-In
Use Case 2: Agency QC Before Client Delivery
Use Case 3: Programmatic SEO at Scale
Use Case 4: Content Repurposing Across Formats
Use Case 5: Brand Voice Consistency Across a Team
Adding Walter Skills for Repeatable Workflows
Installing the Skills Library
Conclusion
FAQs

What Walter MCP Actually Adds to Claude

Before the use cases, a quick orientation on what the connector provides.

When you connect Walter MCP to Claude, three tools become available in every conversation:

humanize rewrites AI-patterned text to remove the statistical signatures that detection tools flag: uniform sentence rhythm, predictable transitions, vocabulary predictability. Keywords, links, brand names, and heading structure stay intact when you specify them.

detect scores text from 0 to 100 and returns a verdict (likely_human, mixed, likely_ai) with paragraph-level feedback. It tells you which specific paragraphs triggered the score and the pattern that caused it, not just a single document number.

batch_humanize processes up to 25 items in one call, each with optional individual settings. Built for content operations running at volume.

These tools run inside Claude conversations through the Model Context Protocol. Claude makes the call, the tool returns the result, and the workflow continues in the same thread. No copy-paste. No tabs.

Quick Setup

Three minutes, no developer configuration.

1. Open Claude, go to Settings > Connectors.

2. Click + then Add custom connector.

3. Fill in:

Name: Walter Writes AI
Remote MCP Server URL: https://mcp-server.walterwrites.ai/mcp

4. Click Add, then connect your Walter account and click Allow Access.

Done. Walter is now available in every Claude conversation.

Use Case 1: SEO Content Pipeline with Keyword Lock-In

The problem: You are drafting blog posts with Claude and the output is solid structurally, but it scores 90+ on AI detection and the humanizer you use keeps paraphrasing your target keyword.

Why this matters: For SEO content, the exact phrasing of your target keyword is not interchangeable. "Best CRM for small business" and "top CRM for small businesses" are different strings with different search behavior. Any humanizer that treats your content as a blob will rewrite those phrases without awareness of what it is costing you.

The Walter MCP approach:

Run detection first to identify which sections are actually flagging, then humanize only those with explicit constraints.

Step 1 — Diagnostic:
"Use Walter to detect which paragraphs in this draft are flagging as
AI-generated. Do not rewrite anything yet. Show me the paragraph-level
feedback."

Step 2 — Targeted humanization:
"Humanize only the flagged sections. Apply these constraints:
- Keep 'best CRM for small business' exactly as written in every occurrence
- Do not change any anchor text or URLs
- Preserve all statistics
- Keep the heading structure intact"

Step 3 — Verify:
"Run Walter detection on the humanized version and show me the
before/after scores."

What you get: A detection compliance report showing the score drop, a preservation compliance report confirming every keyword survived, and a humanized draft ready to review. All in one conversation.

Typical result: Raw Claude drafts that score 90 to 98 on detection consistently land in the 20 to 30 range after one targeted pass. Keyword survival rate is 100 percent when constraints are specified.

Use Case 2: Agency QC Before Client Delivery

The problem: You run an agency. Content goes through writers, gets AI-assisted, gets edited, and then goes to a QC step before client delivery. The QC step is currently manual and inconsistent: different reviewers catch different things, some keyword checks get missed, and the turnaround before delivery is longer than it should be.

Why this matters: An inconsistent QC process is a client relationship risk. If one client's content goes out with a paraphrased brand name or a detection score that surprises them, that is a credibility problem.

The Walter MCP approach:

Load this as your QC prompt at the start of each review session:

"I am going to paste a client article below. Run the following QC pipeline:

1. Use Walter to detect the full article and return the score, verdict,
   and paragraph-level breakdown.
2. For any paragraph scoring above 40, humanize just that paragraph.
3. After humanizing, run detection again on the full article.
4. Return: original score, final score, list of changed paragraphs,
   and a preservation report confirming the following survived:
   [client brand name], [target keyword], [specific product names],
   [all links].

Here is the article: [paste]"

What you get: A structured QC report for every article. Original detection score, final score after targeted humanization, list of specific changes made, and confirmation that every protected element is still intact. That report is also your documentation if a client ever asks what QC looks like on their content.

Reality check: This workflow is faster than manual QC but it is not a replacement for a final human read. Detection and preservation are mechanical checks. Whether the article makes a good argument and is factually accurate is still on you.

Use Case 3: Programmatic SEO at Scale

The problem: You are generating location pages, product description pages, or any other template-driven content at volume. You have 50 city pages to generate, humanize, and verify before they go live.

Why this matters: Programmatic SEO content produced at volume tends to have two failure modes. Either it is too uniform (detection tools treat similar pages as a pattern) or the humanization step introduces enough variation that the target keyword changes across pages. Both are problems.

The Walter MCP approach:

This is where batch_humanize becomes the key feature. One call handles up to 25 items simultaneously.

"I have a list of city-and-service combinations for local landing pages.
For each one:

1. Write a 300-word local landing page targeting '[service] in [city]'.
2. Humanize each page with Walter.
3. Preserve the exact phrase '[service] in [city]' in the H1 and
   first paragraph of every page.
4. Return a per-page detection score and preservation confirmation.
5. Flag any page that scores above 30 for my review.

Here are the first 25 city-service combinations: [list]"

Run this in batches of 25. Review flagged pages individually. Export the compliant ones.

For developers building content pipelines: The Walter MCP batch tool through Claude is a useful prototyping layer before you commit to direct API integration. You can validate your keyword constraints and output format on real content without writing any code.

The SK-03 Local SEO Machine skill from the Walter Skills library automates this exact pattern as a project-level instruction, so every chat in a project runs it without re-specifying the workflow each time.

Use Case 4: Content Repurposing Across Formats

The problem: You have a 2,000-word pillar article that took real research and effort to produce. You want to get a LinkedIn post, an email newsletter intro, a Twitter/X thread hook, and a short blog summary out of it without rewriting each format manually from scratch.

Why this matters: Content repurposing is one of those tasks that sounds simple and is actually tedious. Each format has different length expectations, different tone conventions, and different structural requirements. And if the source article was AI-assisted, every format you derive from it inherits those AI patterns.

The Walter MCP approach:

"Take the article below and produce the following four formats:

1. LinkedIn post (200 to 250 words, professional but conversational)
2. Email newsletter intro (150 words, direct, first-person)
3. Twitter/X thread hook (first post only, under 280 characters,
   strong opening)
4. Blog summary (100 words, third-person, for a related article
   roundup)

After generating all four:
- Humanize each one with Walter independently
- Run detection on each and return the score
- Preserve these data points in every format that uses them:
  [specific stat 1], [specific stat 2]
- Preserve these brand mentions: [brand name]

Here is the source article: [paste]"

What you get: Four formats, each humanized to the appropriate tone for its platform, with detection scores confirming each one reads as human-written. The data points and brand mentions you care about carry across all four.

Note on format: LinkedIn and email copy humanizes differently than blog content. The Walter humanization engine adjusts for length and register. Short-form content in particular benefits from the balanced mode rather than enhanced, which can over-engineer very short pieces.

Use Case 5: Brand Voice Consistency Across a Team

The problem: You have three writers using Claude to draft content for the same brand. Each writer prompts differently. Each gets slightly different output. The content is technically fine but does not sound like it came from the same company. The brand guidelines document exists but nobody reads it before every prompt.

Why this matters: Brand voice inconsistency compounds. The longer a team produces inconsistent content, the harder it is to establish the coherent brand identity that drives recognition and trust.

The Walter MCP approach:

This use case is best handled through a Walter Skill rather than a per-conversation prompt, specifically SK-08 Brand Voice Adapter. But you can also build a version of it inline:

"You are writing for [Brand Name]. Apply the following brand voice rules
to every piece of content in this conversation:

Brand voice: [direct / warm / technical / casual / formal]
Always use: 'platform' not 'tool', 'team' not 'staff'
Always capitalize: [Brand Name], [Product Name]
Avoid: passive voice, hedge words like 'perhaps' and 'possibly',
       sentences longer than 25 words in CTAs

After drafting any piece of content:
1. Run Walter detection and return the score
2. Humanize if the score is above 35
3. Apply the brand voice constraints above to the humanized version
4. Confirm all capitalization rules are intact before returning output"

Every writer on the team pastes this at the start of their session. Every Claude conversation in the project applies the same rules. Detection and humanization are baked in.

For consistent team use: Load the SK-08 Brand Voice Adapter skill into a Claude project's instructions once. Every writer who opens a chat in that project gets the brand voice rules and the Walter workflow applied automatically, without pasting anything.

Adding Walter Skills for Repeatable Workflows

All five use cases above work as one-off prompts. But if you are running any of them regularly, you do not want to re-specify the workflow every time you start a new conversation.

Walter Skills solve this.

A skill is a markdown file you paste once into a Claude project's instructions. Every chat in that project then applies the full workflow automatically. No re-prompting. No forgotten constraints. No inconsistent output because someone used a slightly different version of the prompt.

The full library has 12 skills:

SK-01 SEO Content Writer
SK-02 Agency QC Pipeline
SK-03 Local SEO Machine
SK-04 Content Repurposer
SK-05 E-commerce Engine
SK-06 Newsletter Writer
SK-07 Programmatic SEO
SK-08 Brand Voice Adapter
SK-09 Documentation Writer
SK-10 Lead Magnet Creator
SK-11 Social Media Suite
SK-12 Content Refresh Engine

The repo is at: github.com/walterwritesai/walter-skills

Installing the Skills Library

The Walter Skills library is on the skills.sh registry, Vercel Labs' npx CLI ecosystem for agent skills.

npx skills add walterwritesai/walter-skills

That installs the full library. Each install also counts toward the leaderboard ranking on skills.sh, which drives discovery in the registry. If you are building with Claude Code or another agent environment, this is the fastest way to get the skills locally.

For a community-maintained guide covering all 65 prompts across 12 workflow categories, waltermcp.com is the most comprehensive reference available (community-run, not an official Walter resource).

Conclusion

MCP connectors are only useful if there are real workflows to run through them. These five cover the use cases that show up most often in production content operations: SEO pipelines with strict keyword requirements, agency QC before client delivery, programmatic SEO at volume, multi-format content repurposing, and brand voice consistency across teams.

The common thread across all of them is that the workflow runs inside one Claude conversation. Detection, humanization, keyword protection, and compliance reporting all happen in the same thread where the draft was written.

If you are already using Claude for content work and spending time on the manual cleanup afterward, the connector is worth the three-minute setup. Start at walterwrites.ai.

FAQs

What is Walter MCP?
Walter MCP is the MCP server for Walter Writes AI. It exposes humanization, AI detection, and batch processing as callable tools inside Claude through the Model Context Protocol. Workflows that previously required multiple separate tools run inside a single Claude conversation.

Do I need coding experience to set this up?
No. Setup is three steps in Claude's Settings panel: add the connector URL, sign in to Walter, click Allow Access. No API keys, no configuration files, no terminal.

What is the difference between detect and humanize?
detect is the diagnostic. It scans text and returns a score with paragraph-level feedback on what is flagging and why. humanize is the fix. It rewrites the flagged patterns. Running detect first, then humanizing only the flagged sections, produces better results than running humanize blindly on the full document.

Can Walter MCP preserve exact keyword phrases?
Yes, when you specify them as constraints before the humanization runs. You name the exact phrases, brand names, links, and data that must survive. Walter returns a preservation compliance report confirming every protected element made it through the rewrite.

What is batch_humanize and when should I use it?
batch_humanize processes up to 25 items in a single call, each with optional individual settings. Use it for programmatic SEO pages, product description catalogs, or any workflow where you are processing multiple pieces of content simultaneously.

What are Walter Skills and how do they relate to MCP?
Walter Skills are markdown files you paste into a Claude project's instructions once. They encode the workflow: which detection threshold to use, which humanization mode, how to handle keyword constraints, what the output format should be. The MCP connector provides the tools. The skill provides the workflow logic so you do not re-specify it every conversation. Install them with npx skills add walterwritesai/walter-skills.

What detection scores should I expect?
Raw Claude drafts typically score 90 to 98. After one targeted Walter humanization pass using the detect-first approach, scores consistently land in the 10 to 20 range, classified as likely_human. Word limits per call depend on your Walter plan.

Where can I find more prompts for these workflows?
The community guide at waltermcp.com covers 65 prompts across 12 workflow categories. Community-maintained, not an official Walter resource, but comprehensive and regularly updated.

Walter Writes AI Humanizer MCP in Claude: How to Set It Up

Mohab Abdelkarim — Thu, 11 Jun 2026 23:40:03 +0000

If you use Claude to draft content, you probably know the annoying part.

Claude can write fast.

But when the draft is done, you still end up doing the same manual loop:

Copy the text.
Paste it into a humanizer.
Check it with an AI detector.
Go back to Claude.
Edit again.
Repeat.

That is not really a workflow. It is tab-switching.

This is where Walter MCP is interesting.

Walter Writes connects to Claude through MCP, so you can humanize AI text, run AI detection, and batch-process content without leaving the same Claude conversation.

In this guide, I’ll walk through how to set it up, how to test it, how to use it with Walter Skills, and how I would structure a real content workflow around it.

TL;DR

Walter MCP lets Claude call Walter Writes directly as a tool.

Once connected, Claude can use Walter to:

humanize AI-generated drafts
run AI detection
process multiple pieces of content
preserve important keywords and entities
reduce copy-paste between tools

For developers, agencies, and SEO teams, the main benefit is not just “better rewriting.”

The real benefit is workflow control.

Instead of treating humanization and detection as separate browser steps, you can make them part of the Claude workflow itself.

What is MCP?

MCP stands for Model Context Protocol.

The simple explanation:

MCP is a standard way for AI assistants to connect to external tools.

Instead of every tool needing a custom integration with every AI app, MCP gives tools a more standard way to expose functions that an assistant can call.

So in this case:

Claude is the AI assistant.
Walter Writes is the external tool.
MCP is the bridge between them.

Once Walter is connected, Claude can call Walter’s tools when your prompt needs them.

That is the difference between asking Claude:

“Make this sound more human.”

and asking Claude to use a dedicated humanization/detection workflow through Walter.

The second approach is more repeatable.

What Walter Adds Inside Claude

Walter’s MCP connector adds three useful actions inside Claude:

Humanize
This rewrites AI-patterned text into more natural writing while trying to preserve the meaning, structure, keywords, links, and important entities.

Detect
This checks text for AI-writing patterns and gives feedback on where the text still looks too AI-generated.

Batch Humanize
This is for processing multiple pieces at once, which is useful for agencies, content teams, and programmatic SEO workflows.

The important part is that these tools live inside the same Claude workflow.

You can draft in Claude, humanize with Walter, detect the result, and revise again without copying the text between multiple apps.

Before You Start

You will need:

A Claude account
Access to Claude connectors
A Walter Writes account
The Walter MCP server URL
A draft or sample text to test with

The Walter MCP server URL is:

https://mcp-server.walterwrites.ai/mcp

I would also keep these open while setting things up:

Official Walter Claude/MCP guide:
https://walterwrites.ai/humanize-ai-text-inside-claude/

Walter Skills GitHub repo:
https://github.com/walterwritesai/walter-skills

Community guide, not official:
https://waltermcp.com/

Important note: WalterMCP.com should be treated as a community guide, not the official Walter documentation.

Step 1: Open Claude Connectors

In Claude, go to:

Settings → Connectors

This is where you manage external tools that Claude can connect to.

Look for the option to add a custom connector.

Depending on your Claude interface, this may appear as a plus button or an “Add custom connector” option.

Step 2: Add Walter as a Custom Connector

Create a new connector with a clear name.

For example:

Walter Writes AI

Then paste the MCP server URL:

https://mcp-server.walterwrites.ai/mcp

Save the connector.

Claude should now know that Walter exists as an external MCP tool.

If Claude asks for permissions or approval when using the connector, approve the relevant actions when you actually want Walter to run.

That approval step is a good thing. MCP tools can perform actions, so you should stay aware of what Claude is calling.

Step 3: Test the Connection

Do not start with a full article.

Start with a small test.

Paste a short AI-written paragraph into Claude and ask:

Use Walter to detect whether this text sounds AI-generated.

Text:
[Paste your paragraph here]

If the connector is working, Claude should call Walter’s detection tool and return a result.

Then test humanization:

Use Walter to humanize this paragraph while preserving the meaning and keeping the keyword "AI image detector" unchanged.

Text:
[Paste your paragraph here]

This test matters because it checks three things:

Claude can access Walter.
Walter can process your text.
Claude understands your constraints.

Do not skip this step.

A lot of MCP setups technically connect but fail when you ask the tool to do real work.

Step 4: Try a Full Draft Workflow

Once the basic test works, try a real workflow.

Here is a prompt I would use:

I’m writing an article for Medium.

Please do this workflow:

1. Review the draft for AI-sounding sections.
2. Use Walter to humanize the sections that feel too robotic.
3. Preserve all keywords, brand names, links, headings, and factual claims.
4. Run detection again after humanizing.
5. Give me a short summary of what changed.

Draft:
[Paste draft here]

This is where Walter MCP becomes useful.

You are not just asking Claude to rewrite everything.

You are asking Claude to run a process.

That is a big difference.

Step 5: Use Walter Skills for Repeatable Workflows

The Walter Skills repo is useful if you do not want to rewrite the same workflow prompt every time.

A Claude Skill is basically a reusable instruction file.

Instead of telling Claude the same rules in every chat, you add the skill once to a Claude project. After that, the project knows how to behave for that type of work.

The Walter Skills repo includes skills for things like:

SEO content writing
agency QC
local SEO
content repurposing
e-commerce product writing
newsletters
programmatic SEO
brand voice adaptation
content refreshes
lead magnets
social media
docs writing

The basic install flow is simple:

Open the Walter Skills GitHub repo.
Pick the skill folder that matches your workflow.
Open the SKILL.md file.
Copy the full markdown.
Paste it into your Claude project instructions.
Make sure Walter MCP is connected so Claude can actually call Walter’s tools.

For example, if you are producing SEO articles, start with the SEO content skill.

If you are reviewing content for clients, the agency QC skill may be a better starting point.

If you are updating old articles, use the content refresh skill.

The skill gives Claude the repeatable workflow.
The MCP connector gives Claude the tool access.

You need both if you want the workflow to feel automatic.

A Simple Developer Mental Model

I think about it like this:

Claude = reasoning layer
Walter MCP = tool layer
Walter Skills = workflow layer

Claude decides what needs to happen.

Walter performs the humanization and detection actions.

Walter Skills tell Claude how to behave in a specific workflow.

That combination is more powerful than a one-off prompt.

Without a skill, you have to explain the workflow every time.

Without MCP, Claude can only rewrite with its own general writing ability.

With both, you can create a more repeatable process:

Draft → detect → humanize → preserve keywords → detect again → final review

That is the workflow most SEO teams and content teams actually want.

Example: SEO Article Workflow

Here is a practical prompt for SEO content:

You are helping me prepare an SEO article for publishing.

Use Walter where needed.

Workflow:
1. Check the draft for AI-sounding paragraphs.
2. Humanize only the sections that need it.
3. Keep the target keyword exactly as written.
4. Preserve all internal links, brand names, headings, and statistics.
5. Do not change the search intent.
6. After humanizing, run detection again.
7. Give me the final version plus a short change summary.

Target keyword:
[insert keyword]

Draft:
[paste draft]

This is better than saying:

Make this sound human.

That prompt is too vague.

The better prompt gives Claude constraints and tells it when to use Walter.

Example: Batch Humanization Workflow

For agencies, batch processing is where this becomes more interesting.

Imagine you have 10 short product descriptions or 20 local SEO pages.

Instead of processing each one manually, you can ask Claude to use Walter’s batch flow.

Example:

I have a batch of short AI-generated descriptions.

Use Walter Batch Humanize to process them.

Rules:
- Keep product names unchanged.
- Keep location names unchanged.
- Keep all prices and specifications unchanged.
- Do not add new claims.
- Return the results in the same order.
- After processing, flag any description that still sounds too AI-generated.

Items:
1. [text]
2. [text]
3. [text]

For programmatic SEO or e-commerce, this can save a lot of repetitive work.

The main thing is to be strict about preservation rules.

Any workflow that touches SEO content should protect:

target keywords
product names
brand names
locations
URLs
prices
statistics
factual claims

Humanization is useful only if it does not break the information.

Example: Detection-Only Workflow

Sometimes you do not need to humanize immediately.

You just need to check what needs work.

For that, use a detection-first prompt:

Use Walter to detect AI-writing patterns in this draft.

Do not rewrite yet.

Return:
1. Overall detection result
2. The sections most likely to be flagged
3. What writing patterns caused the issue
4. A recommended edit plan

Draft:
[paste draft]

I like this approach because it avoids over-editing.

Not every paragraph needs to be rewritten. Sometimes only the intro, conclusion, or transition-heavy sections are the problem.

Detection first helps you edit more carefully.

Common Setup Issues

Here are the problems I would check first if Walter does not work in Claude.

The connector URL is wrong

Double-check the URL:

https://mcp-server.walterwrites.ai/mcp

A small typo is enough to break the connection.

Claude has not been restarted or refreshed

After adding a connector, refresh Claude or start a new conversation.

Sometimes the connector is added, but the current chat does not pick it up cleanly.

You are asking Claude too vaguely

This prompt may not trigger the tool:

Make this better.

This is clearer:

Use Walter to humanize this text and then run AI detection on the result.

Be direct.

You forgot the preservation rules

If you care about exact keywords or entities, say that.

Example:

Preserve the exact keyword "AI image detector" and do not change brand names, URLs, or statistics.

The text is too long for the workflow

If you are testing for the first time, start small.

Use one paragraph first. Then one section. Then a full article.

Debugging a 3,000-word article is annoying if you do not know whether the connector works yet.

Security Notes for MCP

MCP is powerful because it lets AI assistants call external tools.

That also means you should treat it carefully.

A few basic rules:

only connect MCP servers you trust
review what a connector can do before using it
do not paste sensitive client data unless you are allowed to
keep API keys and private credentials out of prompts
approve tool calls intentionally
use separate Claude projects for separate client workflows

For Walter specifically, the workflow is mostly about text humanization and detection, but the general MCP rule still applies:

Do not connect random tools blindly.

MCP gives AI assistants more reach. That is useful, but it also means you need better habits.

Where Walter MCP Fits Best

Walter MCP is most useful when the content workflow already starts in Claude.

For example:

writing SEO articles
rewriting AI-generated drafts
checking content before publishing
reviewing agency content
humanizing product descriptions
preparing newsletters
refreshing old blog posts
batch-processing programmatic SEO content
checking whether a draft still sounds too AI-generated

It is less useful if you only need to humanize one short paragraph once.

For that, a normal web tool may be enough.

But if you use Claude every day for content work, the MCP setup makes more sense because it removes a lot of copy-paste friction.

Why Walter Writes Stood Out to Me

Based on my testing and comparison, Walter Writes is one of the best Claude MCP workflows right now for AI humanization and AI detection.

The main reason is that it solves a real workflow problem.

Most tools make you leave the writing environment.

Walter brings humanization and detection into Claude.

That means the draft, edit, detection, and revision loop can happen in one place.

For developers and technical content teams, that matters because the best AI workflow is not always the tool with the most buttons.

It is the workflow with the fewest unnecessary steps.

Final Workflow

Here is the setup I would use:

Claude Project
  → Walter Skill in project instructions
  → Walter MCP connector enabled
  → Draft content in Claude
  → Detect with Walter
  → Humanize with Walter
  → Detect again
  → Final manual review

That gives you a repeatable system instead of a messy copy-paste process.

MCP is not magic.

But for this use case, it is genuinely useful.

If you already write inside Claude, Walter MCP is worth setting up.

Useful Links

Official Walter Claude/MCP guide:
https://walterwrites.ai/humanize-ai-text-inside-claude/

Walter Skills GitHub repo:
https://github.com/walterwritesai/walter-skills

Community guide, not official:
https://waltermcp.com/

Walter Writes:
https://walterwrites.ai/

DEV Community: Mohab Abdelkarim

Best AI Detector APIs in 2026: A Developer's Comparison (With Working Code)

Table of Contents

1. What an AI Detector API Actually Returns

2. The Evaluation Criteria That Matter

3. Proofademic API

4. GPTZero API

5. Copyleaks API

6. Accuracy vs Consistency: The Metric Most Comparisons Get Wrong

7. Integration Patterns That Work

8. Handling False Positives Without Building a Support Nightmare

9. Verdict

10. FAQs

Setting Up Walter MCP in Cursor and Windsurf: The Complete Guide

Table of Contents

1. Two Pieces, Not One

2. Installing Walter Skills in Cursor and Windsurf

3. Connecting the Walter MCP Server

4. Verifying the Connection

5. Installing a Single Skill Instead of All 12

6. A Note on waltermcp.com

7. Troubleshooting

8. Conclusion

9. FAQs

How to Add AI Content Detection to Your App With an API (Developer Guide)

Table of Contents

1. What You're Building

2. Getting an API Key

3. Making Your First Request

4. Understanding the Response

5. Wiring It Into Your App

6. Handling False Positives Properly

7. Common Integration Patterns

8. Pricing and Scaling

9. Conclusion

10. FAQs

Walter MCP vs. Traditional AI Humanizer Workflows: Why Developers Are Switching

The traditional workflow

The MCP workflow

What actually changed, structurally

Side-by-side

Where the traditional API approach still wins

Migrating an existing integration

FAQs

How Walter MCP Handles Keyword Preservation at Scale (With Real Prompts)

Why this breaks by default

How Walter's preservation mechanism actually works

The basic single-article prompt

Scaling it: batch preservation across many items

Verifying preservation programmatically

Where this still breaks

Reusable templates

FAQs

One MCP Server, Three Assistants: Running Walter Across Claude, ChatGPT, and Codex

Why this is worth a post beyond "here's how to add a connector"

The server side, briefly

Setup 1: Claude (the baseline, simplest of the three)

Setup 2: ChatGPT (beta, more moving parts)

The prompting gotcha

Setup 3: Codex (fastest, zero UI)

stdio vs streamable HTTP, since it comes up

Where each one actually makes sense

Common failure modes

Closing thought

FAQ

5 Real-World Use Cases for Walter MCP in Claude

Table of Contents

What Walter MCP Actually Adds to Claude

Quick Setup

Use Case 1: SEO Content Pipeline with Keyword Lock-In

Use Case 2: Agency QC Before Client Delivery

Use Case 3: Programmatic SEO at Scale

Use Case 4: Content Repurposing Across Formats

Use Case 5: Brand Voice Consistency Across a Team

Adding Walter Skills for Repeatable Workflows

Installing the Skills Library

Conclusion

FAQs

Walter Writes AI Humanizer MCP in Claude: How to Set It Up

TL;DR