How do I use humanizer-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@humanizer-mcp Analyze this paragraph for AI detection risk: 'The quick brown fox jumps over the lazy dog.'" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

humanizer-mcp

by aousabdo

Overview Schema Related Servers Score Discussions

Python

Hybrid

humanizer-mcp

PyPI version npm version Python versions License: MIT

An MCP (Model Context Protocol) server that measures AI-detection risk in a piece of text and tells you — line by line — what to change. Works with Claude Code, Claude Desktop, and any MCP-compatible client.

Just want to use it? Go to humanizer.analyticadss.com — copy the URL, paste it into Claude's Connectors, done. The rest of this README is for developers and people self-hosting.

Rather than running your prose through a black-box "humanizer," this server analyzes it against known detection signals (vocabulary, burstiness, contraction usage, paragraph uniformity, em dashes, first-person voice) and returns a structured report with a 0–100 risk score and a concrete rewrite plan. The actual rewriting is left to the LLM that's driving the conversation — which is the point: a planner, not a laundering service.

Tools

Tool	What it does
`humanizer_humanize_text`	Returns the rewritten text. Applies vocabulary swaps, phrase removal, contractions, em-dash cleanup, plus before/after scores. The LLM caller polishes for context.
`humanizer_analyze_ai_tells`	Full analysis with risk score, fix recommendations, and a mechanical rewrite as a starting point.
`humanizer_quick_vocab_scan`	Fast word- and phrase-level scan with replacement suggestions.
`humanizer_get_rewrite_instructions`	Step-by-step rewrite plan, tailored to text type (blog / business / academic / email / general).
`humanizer_compare_before_after`	Side-by-side metrics for an original and a rewrite, with a PASS / IMPROVED / NEEDS MORE WORK verdict.
`humanizer_get_banned_words`	The full vocabulary and phrase ban list, for reference.

Related MCP server: AI Humanizer MCP Server

Three ways to use it

Path	Best for	What you do
Hosted URL (no install, deterministic)	claude.ai, Claude Desktop, Claude for Chrome — including Free plan	Paste one URL into Settings → Connectors → Add custom connector.
Skill (no install, no infra, estimated)	Same surfaces, plus people who don't want to use up their 1 free-tier connector slot	Upload the `skill/humanizer-mcp/` folder under Settings → Capabilities → Skills. See skill/README.md.
Local install (`uvx` / `npx`)	Claude Code on the terminal, Desktop with stdio	One command in a shell.

Sharing with non-technical users? Two PDFs in share/ — email either one, no further explanation needed:
share/humanizer-mcp-friends-guide.pdf — 2 pages. Truly non-technical: download a zip, upload it to Claude, done. No install.
share/humanizer-mcp-boss-guide.pdf — 3 pages. Semi-technical Windows users who can install an app and edit a config file. Sets up the full MCP server with Claude Desktop.

Path A — add as a Custom Connector (zero install)

Works in claude.ai (web), Claude Desktop, and Claude for Chrome — all four surfaces share the connector list once you're signed in. Available on every plan including Free (Free is limited to one custom connector).

A hosted reference instance is up — feel free to use it for casual evaluation:

https://humanizer-api.analyticadss.com/mcp

For production / privacy-sensitive use, deploy your own with the included Dockerfile (see Hosting below — Fly.io takes ~3 minutes). The hosted instance is on a free Fly tier with no SLA, no support, and no privacy guarantees — your text passes through it.

To add it to your Claude:

Open Claude → Settings → Connectors.
Click Add custom connector.
Paste the URL above (or your own hosted instance's /mcp URL).
Save. The five humanizer_* tools become available in any chat.

That's the whole install for non-technical users — they never touch a terminal.

Path B — install locally (Claude Code / Desktop with stdio)

# Claude Code, one line
claude mcp add humanizer -- uvx humanizer-mcp

For Claude Desktop with a local stdio server, add this to claude_desktop_config.json:

{
  "mcpServers": {
    "humanizer": {
      "command": "uvx",
      "args": ["humanizer-mcp"]
    }
  }
}

Config location:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json

Other ways to launch the local binary if you don't want uvx:

pip install humanizer-mcp && humanizer-mcp     # pip
npx humanizer-mcp                              # npm launcher (delegates to uvx/pipx/python3)

Try it with the MCP Inspector

npx @modelcontextprotocol/inspector uvx humanizer-mcp

Hosting

To create the URL in Path A, deploy the included Dockerfile. The repo ships with a Render Blueprint and a Fly config:

Render — easiest, free tier, auto-deploys from the GitHub repo:

Fly.io — always-on free tier:

fly launch --copy-config --name humanizer-mcp
fly deploy

Anywhere else — the Dockerfile reads PORT from the environment and binds to 0.0.0.0, so it runs on Railway, Heroku, Cloud Run, ECS, or your own box:

docker build -t humanizer-mcp .
docker run -p 8000:8000 humanizer-mcp

Cloudflare Tunnel from your laptop — zero hosting cost, only up while your machine is on:

brew install cloudflared
pipx install humanizer-mcp        # or: pip install humanizer-mcp
humanizer-mcp --http --port 8000 &
cloudflared tunnel --url http://localhost:8000
# copy the trycloudflare.com URL it prints

The MCP endpoint is at /mcp (streamable HTTP). The server is stateless and unauthenticated — anyone with the URL can call the tools, but there are no secrets and no destructive operations to abuse.

Run the HTTP server locally

humanizer-mcp --http --port 8000
# point a client at http://127.0.0.1:8000/mcp

Verify it works

Once installed by any path, in any Claude chat ask:

"What humanizer tools do you have available?"

Claude should list five: humanizer_analyze_ai_tells, humanizer_quick_vocab_scan, humanizer_get_rewrite_instructions, humanizer_compare_before_after, humanizer_get_banned_words.

Then try the canonical test:

"Score this for AI tells: 'In today's rapidly evolving digital landscape, it's important to note that businesses must leverage cutting-edge solutions to navigate the multifaceted challenges they face.'"

You should get a score in the HIGH bucket (≥ 60), the signals that fired, and a line-by-line fix list.

Troubleshooting

Symptom	Likely cause	Fix
`claude mcp list` shows server but no tools	`uvx` isn't on `$PATH` for the Claude Code subprocess	`which uvx`; add `~/.local/bin` to `$PATH` in your shell rc
`humanizer-mcp: command not found` after `pip install`	pip user-install bin not on `$PATH`	Use `python3 -m humanizer_mcp` instead — always works
Claude Desktop has no hammer icon	Config JSON syntax error	`python3 -m json.tool < claude_desktop_config.json` to validate
`npx humanizer-mcp` hangs ~30s on first run	Launcher is shelling to `uvx`, which downloads deps on first use	Wait it out; subsequent runs are instant
Render-hosted: 406 spam in logs	Health Check Path is `/mcp`; should be `/health`	Settings → Health & Alerts → set to `/health`
Render-hosted: `pip install` killed during build	OOM on free tier (512MB) — `pydantic-core` native compile spikes	Switch to Fly free tier or upgrade Render to Starter
Custom Connector add fails on claude.ai Free	Already at the 1-connector limit	Remove an unused connector; or upgrade plan

Example prompts

With the server connected to Claude, you can say things like:

"Analyze this blog post for AI tells and tell me what to change."
"Run a quick vocab scan on this paragraph."
"Give me rewrite instructions for this academic abstract — keep it formal but fix the burstiness."
"Compare these two drafts. Did my edit actually lower the detection risk?"

Claude picks the right tool automatically.

How the risk score works

The 0–100 score combines eight signals:

AI vocabulary hits — words statistically overrepresented in LLM output (delve, crucial, leverage, myriad, …).
AI phrase hits — cliché structural tells (it's important to note, in the ever-evolving, at the end of the day, …).
Burstiness — coefficient of variation of sentence lengths. AI writing clusters around a single length; humans mix short fragments and long digressions.
Contractions — expanded forms (it is, do not) read as AI-formal; contractions read as conversational.
Paragraph uniformity — AI tends to produce paragraphs of similar size.
Rhetorical questions — near-absent in AI prose above 200 words.
First-person voice — AI avoids I, we, my, our unless prompted.
Em dashes — a ChatGPT signature; heavy use is a strong signal.

Each signal adds to the score independently; the total is clamped to 100 and bucketed into LOW (≤ 20), MEDIUM (21–50), or HIGH (51+).

Development

git clone https://github.com/aousabdo/humanizer-mcp
cd humanizer-mcp
pip install -e ".[dev]"
pytest

See CONTRIBUTING.md for more.

License

MIT — see LICENSE.

Available Tools

6 tools

humanizer_analyze_ai_tellsA

Read-onlyIdempotent

Analyze text for AI-generated patterns and compute a detection risk score.

Scans for AI-associated vocabulary, structural patterns, burstiness, contraction usage, paragraph uniformity, rhetorical questions, first-person voice, and em dash frequency. Returns a comprehensive report with a 0–100 risk score and specific recommendations.

Args: params (AnalyzeTextInput): Contains the text to analyze.

Returns: str: JSON report with risk score, detected patterns, and fix recommendations.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and no destruction. The description adds details about the analysis process, risk score range (0-100), and output contents (patterns, recommendations), which goes beyond annotations.

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

Conciseness4/5

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

The description is front-loaded with the main purpose, lists patterns, and explains output briefly. It is concise without unnecessary detail, though slightly verbose with 'Args:' and 'Returns:' sections.

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

Completeness4/5

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

Despite the lack of output schema, the description explains that the return is a JSON report with risk score, detected patterns, and recommendations. This is sufficient for a simple input tool with one parameter.

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

Parameters3/5

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

The input schema provides a description for the 'text' parameter. The description's 'Args' section only reiterates that 'params' contains the text, adding no new meaning beyond the schema. Baseline 3 is appropriate given schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Analyze text for AI-generated patterns and compute a detection risk score.' It lists specific patterns scanned and returns a score, which distinguishes it from siblings like humanizer_humanize_text or humanizer_compare_before_after.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for detecting AI-generated text, but does not explicitly state when to use this over sibling tools. However, the context of analysis vs. rewriting is clear enough for effective selection.

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

humanizer_compare_before_afterA

Read-onlyIdempotent

Compare detection metrics between original and rewritten text.

Use after humanizing to verify improvement. Shows side-by-side metrics for burstiness, vocabulary tells, structure, and risk scores.

Args: original (str): The original AI-generated text. rewritten (str): The humanized version.

Returns: str: JSON comparison of detection metrics for both versions.

ParametersJSON Schema

Name	Required	Description	Default
`original`	Yes
`rewritten`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, etc. The description adds detail on what metrics are shown (burstiness, vocabulary tells, structure, risk scores), which goes beyond annotations.

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

Conciseness5/5

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

Very concise with purposeful sentences. Front-loaded with purpose, followed by usage guidance, then structured parameter and return descriptions. No wasted words.

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

Completeness4/5

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

With annotations and output schema present, the description covers purpose, usage, parameters, and return type. Could mention that the rewritten text should be from humanizer_humanize_text, but it's implied by context.

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

Parameters4/5

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

Input schema has 0% description coverage, but the 'Args:' section in the description provides clear, human-readable explanations for both parameters, compensating well for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool compares detection metrics between original and rewritten text. It distinguishes itself from siblings like humanizer_humanize_text and humanizer_analyze_ai_tells by focusing on side-by-side comparison.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use after humanizing to verify improvement', providing clear when-to-use context. Does not specify when not to use or alternatives, but sibling tools provide implicit differentiation.

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

humanizer_get_banned_wordsA

Read-onlyIdempotent

Return the complete list of AI-associated words and their human replacements.

Use as a reference when manually editing text. Includes both single words and multi-word phrases that trigger AI detection.

Returns: str: JSON with vocabulary ban list and phrase ban list.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so safety is clear. The description adds that it returns a JSON with two lists (vocabulary and phrase ban lists), which is useful behavioral context beyond annotations.

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

Conciseness5/5

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

The description is very concise at four sentences, each serving a purpose: stating the function, suggesting usage, detailing content, and specifying return type. No wasted words.

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

Completeness5/5

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

For a simple read-only tool with no parameters and rich annotations, the description fully covers purpose, usage context, and output format. The existing output schema provides additional detail, making the description complete.

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

Parameters4/5

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

No parameters exist, and schema coverage is 100%. The description adds no parameter information, but none is needed. Baseline score of 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns the complete list of AI-associated words and their human replacements, distinguishing it from sibling tools that analyze, compare, or rewrite text.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises using the list as a reference when manually editing text, providing clear context. However, it does not explicitly exclude alternatives or specify when not to use this tool.

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

humanizer_get_rewrite_instructionsA

Read-onlyIdempotent

Analyze AI text and return detailed, step-by-step rewrite instructions.

This tool does NOT rewrite the text itself — it provides a structured action plan that an LLM or human editor can follow to humanize the text. The instructions are tailored to the text type and specific patterns found.

Args: params (HumanizeTextInput): Contains text, text type, and voice preferences.

Returns: str: JSON with analysis results and step-by-step rewrite instructions.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

Annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true) already indicate non-destructive behavior. The description adds that it returns instructions, not rewritten text, and that output is a JSON string with analysis and instructions, aligning with and complementing the annotations.

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

Conciseness5/5

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

The description is concise, front-loaded with purpose, and structured with Args/Returns sections. Every sentence adds value without redundancy.

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

Completeness5/5

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

Given the presence of an output schema (though not shown), the description's explanation of return value as 'str: JSON with analysis results and step-by-step rewrite instructions' is sufficient. The tool is well-contextualized among siblings and parameters are defined in schema.

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

Parameters3/5

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

Schema description coverage is 0% as the description does not detail parameters, but the schema itself is rich with descriptions for each property (text, text_type, preserve_meaning, voice_notes). The description's mention of 'text, text type, and voice preferences' is a high-level summary, adding little beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Analyze AI text and return detailed, step-by-step rewrite instructions' and explicitly distinguishes itself by noting 'This tool does NOT rewrite the text itself — it provides a structured action plan.' This differentiates it from sibling tools like humanizer_humanize_text.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly guides usage by stating it provides instructions rather than rewriting, and mentions tailoring to text type and patterns. However, it does not explicitly list when to use this tool vs alternatives, though the sibling context helps.

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

humanizer_humanize_textA

Read-onlyIdempotent

Rewrite AI-generated text to sound human, returning the humanized version.

Applies a deterministic mechanical pass (vocabulary swaps, AI-phrase removal, contraction injection, em-dash cleanup) and returns the rewritten text plus a list of remaining issues that the LLM caller should refine for context.

IMPORTANT — for the model calling this tool: the humanized_text field in the response is a starting point, NOT the final answer. After receiving it, YOU must:

Read the polish_instructions field.
Refine the text to fix burstiness (vary sentence length aggressively), add first-person voice if missing, and smooth any awkward edits the mechanical pass introduced.
Present the FINAL polished version to the user as your reply, along with the before/after risk scores so they can see the improvement.

Args: params (HumanizeTextInput): Text, text type, and voice preferences.

Returns: str: JSON with humanized_text (mechanical rewrite), original_score, rewrite_score, applied_changes, and polish_instructions.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior5/5

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

Discloses deterministic mechanical pass, lists exact transformations (vocabulary swaps, AI-phrase removal, contraction injection, em-dash cleanup), and notes the returned polish_instructions. Aligns with annotations (readOnlyHint, idempotentHint) without contradiction.

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

Conciseness4/5

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

Front-loaded with purpose and process; includes necessary post-call instructions. Slightly verbose due to instructions, but every sentence adds value. Could be trimmed slightly.

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

Completeness5/5

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

Given the tool's single parameter and presence of output schema, the description covers the two-step workflow (tool call then agent refinement) and explains the return fields. Sufficient for correct usage.

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

Parameters3/5

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

Schema has good per-property descriptions; description merely summarizes 'text, text type, and voice preferences'. Does not add significant meaning beyond the schema, but coverage is high, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description states 'Rewrite AI-generated text to sound human', using specific verb-resource pairing. Differentiates from siblings like humanizer_analyze_ai_tells by focusing on rewriting rather than analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit post-call instructions for the agent (refine the text). Does not explicitly mention when to avoid this tool or compare to alternatives, but the context is clear enough.

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

humanizer_quick_vocab_scanA

Read-onlyIdempotent

Fast scan for AI-associated vocabulary only — no structural analysis.

Use this for a quick check when you just want to find and replace AI words without running the full analysis pipeline.

Args: params (VocabCheckInput): Contains the text to scan.

Returns: str: JSON with found AI words, their positions, and replacement suggestions.

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already indicate read-only, non-destructive, and idempotent behavior. The description adds valuable context by stating 'no structural analysis' and detailing the output format ('JSON with found AI words, their positions, and replacement suggestions'). This complements the annotations without contradiction.

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

Conciseness5/5

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

The description is concise and well-structured: a clear one-line purpose, a usage paragraph, and structured Args/Returns sections. Every sentence adds value with no wasted words.

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

Completeness5/5

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

Given the tool's simplicity, the existence of an output schema, and annotations, the description sufficiently explains what the tool does, when to use it, and what it returns. It distinguishes from sibling tools and covers all necessary aspects.

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

Parameters3/5

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

The description adds the note 'Contains the text to scan' for the 'params' argument, but the input schema already defines 'text' with a description. With schema description coverage at 0%, this minimal addition provides some clarification, but not enough to fully compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it's a 'fast scan for AI-associated vocabulary only — no structural analysis.' This specifies the verb (scan), resource (AI-associated vocabulary), and scope (quick, no structural analysis), distinguishing it from sibling tools like humanizer_analyze_ai_tells.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises using this tool 'for a quick check when you just want to find and replace AI words without running the full analysis pipeline.' It provides clear context for when to use it and implies alternative usage (full analysis), though it does not explicitly name the alternative tool.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.1.0May 28, 2026
- First observedhumanizer_analyze_ai_tells
- First observedhumanizer_compare_before_after
- First observedhumanizer_get_banned_words
- First observedhumanizer_get_rewrite_instructions
- First observedhumanizer_humanize_text
- First observedhumanizer_quick_vocab_scan

Install Server

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

TDQS

A4.5/5.0

Disambiguation5/5

Each tool serves a uniquely defined purpose: analyzing AI tells, comparing before/after, retrieving banned words, getting rewrite instructions, rewriting text, and quick vocab scanning. No two tools overlap in functionality.

Naming Consistency5/5

All tools follow a consistent 'humanizer_verb_noun' pattern, e.g., humanizer_analyze_ai_tells, humanizer_compare_before_after, humanizer_humanize_text. The naming convention is uniform and predictable.

Tool Count5/5

With 6 tools, the set is well-scoped for the domain of humanizing AI-generated text. It covers analysis, rewriting, comparison, reference, and quick scanning without unnecessary bloat or scarcity.

Completeness5/5

The tool set provides a complete workflow: analyze AI patterns, get rewrite instructions, rewrite text, compare before/after, and reference banned words. The quick scan adds a lightweight option. No obvious gaps for the stated purpose.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Moltline Humanizer A
com.moltlinestudio
Find AI-isms with evidence and fingerprint a writing voice from samples. 3 of 5 free.
AI & Machine Learning
51
Zero Slop A
io.github.manavmishra
Score and rewrite AI-assisted prose while preserving names, numbers, quotes, links, and facts.
1199
humanizer
io.github.GPTHuman-ai
Transform AI-generated text into natural, human-sounding content that bypasses AI detectors.
AI & Machine Learning
2
Moltline Code Review A
com.moltlinestudio
Risk-scan a diff, flag AI-generated-code tells, find secrets. 5 of 7 tools need no account.
Code Analysis Developer Tools Testing & QA Tools
71

Related MCP Servers

AI Humanizer MCP Server
Text Summarization App Automation
Text2Go
A
license
C
quality
D
maintenance
Helps refine AI-generated content to sound more natural and human-like. Built with advanced AI detection and text enhancement capabilities.
Updated 2 years ago (2024-12-27 09:12 UTC)
1
50
59
MIT
AI Humanizer MCP Server
Text Summarization Developer Tools
chongzixuan-ai
A
license
C
quality
D
maintenance
Detects AI-generated content and transforms robotic text into natural, human-like writing while improving grammar, readability, and preserving key terminology.
Updated 10 months ago (2025-11-10 02:41 UTC)
1
50
3
MIT
Natural Voice MCP
Developer Tools Text Summarization Content Management Systems
Protogenus
A
license
Not graded
quality
Not graded
maintenance
Provides tools and resources to detect AI-generated writing patterns and refine text for more authentic, human-like communication. It enables users to analyze phrasing via a scoring system and apply conversational guides tailored for platforms like Twitter and LinkedIn.
Updated 7 months ago (2026-02-10 03:18 UTC)
1
-
AI Content Detector MCP Server
AI & Machine Learning Research & Data
zhaohongyuziranerran
F
license
Not graded
quality
C
maintenance
Detects AI-generated content by analyzing 24 writing patterns, provides style analysis, plagiarism check, text humanization suggestions, and offers batch detection and version comparison tools.
Updated 4 months ago (2026-04-30 08:07 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aousabdo/humanizer-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server