GoHumanize Open Humanizer MCP server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OPEN_HUMANIZER_URL | No | The base URL of an OpenAI-compatible server. Recommended for local/custom endpoints. Example: http://localhost:11434/v1 | |
| OPEN_HUMANIZER_MODEL | No | The model name to use on the server. Example: hf.co/gohumanize/gohumanize-open-humanizer:Q4_K_M | |
| OPEN_HUMANIZER_API_KEY | No | API key for the hosted endpoint (required when using the fallback endpoint). Sets a bearer token when the endpoint needs one. | |
| OPEN_HUMANIZER_SAMPLES | No | Set to '1' to request a single rewrite instead of five. Optional. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| humanize_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. |
| about_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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
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.
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.
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.
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.