A
licenseC
qualityD
maintenanceHelps refine AI-generated content to sound more natural and human-like. Built with advanced AI detection and text enhancement capabilities.
1
28 npm
59
MIT
GoHumanize Open Humanizer MCP server
OfficialClick on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@GoHumanize Open Humanizer MCP serverRewrite this text to sound like a human wrote it."
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.
GoHumanize Open Humanizer MCP server
An MCP (Model Context Protocol) server that lets AI assistants call the GoHumanize Open Humanizer: a small open model (Qwen3-4B fine-tune, Apache-2.0) that rewrites AI-styled English text into more natural human prose.
Tools:
humanize_textrewrite a passage (50 to 400 words works best; longer texts are processed paragraph by paragraph, up to 1,500 words).about_open_humanizerwhat the model is and which endpoint is in use.
The model is educational and makes no claim about AI detectors. It is separate from the production models used by GoHumanize.ai.
Several rewrites, best one returned
On modern prose the model sometimes plays safe and hands the text back almost unchanged
(about one try in six). Each call asks the endpoint for five rewrites (generated in
parallel, so the wait is the same) and keeps the one that moved furthest from the input while
staying a sensible length. Set OPEN_HUMANIZER_SAMPLES=1 for a single request.
Related MCP server: Humanizer APIs MCP Server
Links
Resource | Link |
Project page and browser demo | |
GoHumanize (the product this research comes from) | |
Model weights and GGUF builds | |
Dataset, 3,257 pairs (CC-BY 4.0) | |
Code and full pipeline | |
Write-up: every step, service and result | |
Archived release, citable DOI | |
Python client and CLI | |
MCP server for AI assistants | |
Training runs, loss curves and config |
Use
{
"mcpServers": {
"gohumanize-open-humanizer": {
"command": "npx",
"args": ["-y", "gohumanize-open-humanizer-mcp"]
}
}
}Which endpoint
The model runs wherever you point the server. Running it yourself needs no key and is the recommended setup:
ollama pull hf.co/gohumanize/gohumanize-open-humanizer:Q4_K_M
export OPEN_HUMANIZER_URL=http://localhost:11434/v1
export OPEN_HUMANIZER_MODEL=hf.co/gohumanize/gohumanize-open-humanizer:Q4_K_MThe hosted endpoint sleeps when idle. The first request after a quiet period waits for a GPU cold start, measured at one to two minutes; afterwards a rewrite takes a second or two. MCP clients apply their own timeout, often 60 seconds, so the first call through a client may fail even with a valid key and succeed on retry. Running the model locally avoids this entirely.
The endpoint the server falls back to is the one behind the browser demo on
gohumanize.ai/open-model. It is rate-limited and
requires OPEN_HUMANIZER_API_KEY, so it is not open for general use; to try the
model without installing anything, use the demo on that page.
Any OpenAI-compatible server works:
"env": {
"OPEN_HUMANIZER_URL": "http://localhost:11434/v1",
"OPEN_HUMANIZER_MODEL": "gohumanize/open-humanizer"
}OPEN_HUMANIZER_API_KEY sets a bearer token when the endpoint needs one.
Licence
Apache-2.0.
Available Tools
2 toolsabout_open_humanizerAbout the Open HumanizerA
Describe the GoHumanize Open Humanizer: what it is, how it was trained, where the model, dataset and paper are published, and which endpoint this server is using.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It clearly communicates that the tool returns descriptive information about the model's background and the endpoint, implying a read-only informational operation with no side effects. It does not elaborate on output format, but for a simple informational tool the scope is adequately disclosed.
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 a single well-structured sentence that front-loads the core action and resource before listing the specific topics covered. Every clause contributes meaningful scope information, and there is no filler, repetition, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter informational tool, the description is largely complete: it tells the agent what the tool will explain and which endpoint detail is included. It does not mention an output format or explicitly distinguish itself from the sibling, but given the simple nature of an 'about' tool and no output schema, nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies. There is no parameter meaning to add because the schema is empty and the description correctly focuses entirely on what the tool does rather than trying to document nonexistent inputs.
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 uses the specific verb 'Describe' with a clear resource, 'the GoHumanize Open Humanizer', and enumerates the exact aspects covered: what it is, training, publication locations, and server endpoint. This makes the tool's purpose immediately distinct from the sibling 'humanize_text', which clearly performs a transformation rather than providing background information.
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 clearly frames this as an informational tool for learning about the model, which is a distinct context from using 'humanize_text' to actually rewrite text. However, it does not explicitly state when not to use this tool or name the sibling as the alternative for text humanization, so the routing is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
humanize_textHumanize textA
Rewrite a passage of AI-styled English prose so it reads more like a person wrote it, keeping the meaning, facts and order of ideas. Uses the GoHumanize Open Humanizer, a small open model (Qwen3-4B fine-tune) trained on public-domain prose. Best on passages of 50 to 400 words; longer inputs are processed paragraph by paragraph. Educational model: no claim about AI detectors.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to rewrite (English) | |
| temperature | No | Sampling temperature, default 0.9; lower is more literal |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well. It discloses the underlying model ('GoHumanize Open Humanizer, a small open model (Qwen3-4B fine-tune)'), its training data ('public-domain prose'), processing behavior for long inputs, and a key limitation ('Educational model: no claim about AI detectors'). This is rich behavioral context beyond a simple action statement.
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?
Three sentences with no filler: the first states the core purpose, the second provides model and length details, and the third clarifies the educational limitation. Every sentence contributes actionable information and the most important content is front-loaded.
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 two-parameter tool with no output schema and no annotations, the description covers purpose, model, usage constraints, and limitations. An agent has everything it needs to decide whether and how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning to the 'text' parameter by specifying the ideal length range ('50 to 400 words') and how longer inputs are handled ('processed paragraph by paragraph'). This goes beyond the schema's bare 'The text to rewrite (English)'.
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 states a specific verb ('Rewrite'), resource ('a passage of AI-styled English prose'), and the transformation goal ('reads more like a person wrote it'). It also specifies what is preserved ('meaning, facts and order of ideas'), making the tool's function unambiguous and distinct from the sibling 'about_open_humanizer', which is clearly informational.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'Best on passages of 50 to 400 words; longer inputs are processed paragraph by paragraph.' This tells the agent when the tool is appropriate and how it handles longer inputs. It does not explicitly state when not to use it or name alternative tools, but the context is sufficient for typical selection.
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.
2 tool updates
v0.1.12- First observed
about_open_humanizer - First observed
humanize_text
TDQS
A4.4/5.0
Scored across 2 tools
Disambiguation5/5
The two tools have clearly distinct purposes: one performs the core humanization task, the other provides metadata and background information. There is no overlap or ambiguity between them.
Naming Consistency4/5
Both tool names are readable and descriptive, but they follow slightly different patterns: 'humanize_text' uses a verb_noun structure, while 'about_open_humanizer' uses a preposition_noun structure. Minor inconsistency but still predictable.
Tool Count3/5
With only two tools, one functional and one informational, the server feels thin. However, the purpose is narrowly defined as humanizing text, so the count is acceptable but at the lower boundary of reasonable scope.
Completeness4/5
The server's domain is a single operation (humanize text), which is fully covered by the humanize_text tool. No obvious missing core functionality, though options like batch processing or tone control are absent, but these are not required for the stated purpose.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
Transform AI-generated text into natural, human-sounding content that bypasses AI detectors.
Text generation over MCP: prose, emails, blog outlines, SQL, humanizing, text diffs, fake data.
Build a voice from your own texts, measure whether a text still sounds like you, then write in it.
AI humanizer for MCP clients. Rewrites AI text so it reads naturally and sounds human.
Related MCP Servers
- AlicenseCqualityDmaintenanceEnables access to Humanizer APIs for text humanization with multiple models including basic, easy-use, and multi-language support. Requires API key authentication.3MIT
- AlicenseNot gradedqualityNot gradedmaintenanceProvides 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.1-
- AlicenseNot gradedqualityBmaintenanceProvides psycholinguistic, lexical, structural, and discourse-level rules to help writing sound human-authored. Includes reference readers and a compliance checker.MIT