This server integrates Rephrasy's text humanization and AI detection into your editor or agent workflow.
Humanize text: Rewrite AI-generated content to sound natural and human-like, preserving meaning. Specify a model (default: v3), a custom writing style from your account, and an output language hint. Returns the humanized text and the word count charged.
Detect AI-written text: Score how likely a text is to be flagged as AI-written. Returns an overall AI-likelihood score (lower = more human-like). Supports up to 15,000 characters, with optional per-sentence scoring.
Chain both tools: Humanize a draft, then run detection to verify it passes AI checks.
Click 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., "@Rephrasy Humanize this paragraph, then run detect on the result to verify 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.
Use Rephrasy from Claude, Cursor, or any MCP client: humanize AI-generated text and check AI-detection scores without leaving your editor or agent workflow.
Two tools, one API key:
Tool | What it does |
| Rewrites AI-generated text in a natural, human style while preserving meaning |
| Scores how likely a text is to be flagged as AI-written (overall + optional per-sentence) |
1. Get an API key — sign in at rephrasy.ai → Account → API. Both tools bill against your Rephrasy plan.
2. Add the server to your client:
claude mcp add rephrasy -e REPHRASY_API_KEY=<your-key> -- npx -y @rephrasy/mcpAdd to claude_desktop_config.json (Settings → Developer → Edit Config):
{
"mcpServers": {
"rephrasy": {
"command": "npx",
"args": ["-y", "@rephrasy/mcp"],
"env": { "REPHRASY_API_KEY": "<your-key>" }
}
}
}Add to .cursor/mcp.json (project) or ~/.cursor/mcp.json (global):
{
"mcpServers": {
"rephrasy": {
"command": "npx",
"args": ["-y", "@rephrasy/mcp"],
"env": { "REPHRASY_API_KEY": "<your-key>" }
}
}
}Until the package is on npm you can run it straight from GitHub: replace
"args": ["-y", "@rephrasy/mcp"]with"args": ["-y", "github:rephrasyai/rephrasy-mcp"].
Related MCP server: humantext-mcp-server
humanizeParameter | Type | Required | Description |
| string | yes | The text to humanize |
| string | no | Rephrasy model, default |
| string | no | Writing-style ID from your account to mimic a specific voice |
| string | no | Output language hint (e.g. |
Returns the rewritten text plus the number of words charged.
detectParameter | Type | Required | Description |
| string | yes | The text to score (max 15,000 characters) |
| boolean | no | If |
Returns JSON with scores.overall (lower = more human-like) and, in per-sentence mode, sentences.
"Humanize this paragraph, then run detect on the result to verify it."
"Rewrite my draft with the humanize tool using my writing style <style-id>."
"Check which sentences of this post read as AI-written."
npm install
npm run build
REPHRASY_API_KEY=<key> node dist/index.js # runs on stdioMIT © Rephrasy
Score a text with Rephrasy's AI detector. Returns an overall AI-likelihood score (lower = more human-like) and, optionally, per-sentence scores. Useful to verify a draft before publishing. Max 15,000 characters.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to score. | |
| per_sentence | No | If true, also return a score per sentence ("depth" mode). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and adequately discloses key behaviors: returns an overall score (with direction), supports optional per-sentence scores, and imposes a 15,000-character limit. It lacks details on error handling or rate limits, but is sufficient for the tool's simplicity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, each adding essential information: action, return values, use case, and limit. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description effectively explains the return values and their meaning. It also covers the maximum input length and provides a practical use case. The tool is simple, and the description covers all necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, giving a baseline of 3. The description adds value by explaining the score interpretation ('lower = more human-like') and referring to per-sentence mode as 'depth mode', which goes beyond the schema's wording.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scores text for AI-likelihood using Rephrasy's AI detector, with a specific verb ('Score') and resource. However, it does not explicitly differentiate from the sibling tool 'humanize', so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('verify a draft before publishing') and implies when to use it, but it does not mention when not to use it or explicitly name the alternative 'humanize' tool. This is a clear context without exclusions, scoring a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rewrite AI-generated text with Rephrasy so it reads in a natural, human style — varying sentence rhythm, structure and word choice while preserving meaning. Returns the rewritten text. Costs words/credits on the connected Rephrasy plan.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The text to humanize. | |
| model | No | Rephrasy model to use. Default "v3" (current best). | v3 |
| style | No | Optional writing-style ID from your Rephrasy account to mimic a specific voice. | |
| language | No | Optional output language hint, e.g. "en", "de". Defaults to input language. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return value ('Returns the rewritten text') and the cost implication ('Costs words/credits on the connected Rephrasy plan'). It does not mention failure modes or rate limits, but the key behavioral facts are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, followed by return info and cost. There is no redundancy or filler; every sentence provides necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema, the description covers the core purpose, return value, and cost. It includes the prerequisite that a Rephrasy plan is connected. It does not explain edge-case behaviors like error handling or input limits, but given the simplicity of the tool, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of all parameters with descriptions (text, model, style, language). The tool description does not add any extra parameter-level detail beyond what the schema already states. Baseline of 3 is appropriate since the schema fully covers parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Rewrite AI-generated text'), the method ('with Rephrasy'), and the outcome ('reads in a natural, human style — varying sentence rhythm, structure and word choice while preserving meaning'). It is distinguished from the sibling 'detect' by focusing on rewriting rather than detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context: it is for AI-generated text that needs to be humanized. However, it does not explicitly contrast with the sibling 'detect' tool or provide when-not-to-use guidance. There is clear context but no exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0detecthumanizeScored across 2 tools
Humanize and detect have clearly distinct purposes: one modifies text to sound human, the other analyzes text for AI-likelihood. There is no overlap or ambiguity between them.
Both tool names are single, lowercase verbs that directly describe their action (humanize, detect). The naming pattern is simple, consistent, and predictable.
With only two tools, the set feels thin but is appropriately scoped for a niche server focused on AI text rewriting and detection. It is borderline but not egregiously under-populated.
The two tools cover the full intended workflow: rewrite text to human style and verify it with a detector. There are no obvious missing operations for the stated purpose.
Read and write your Fresh Jots notes from Claude, Cursor, and any MCP client.
Text generation over MCP: prose, emails, blog outlines, SQL, humanizing, text diffs, fake data.
The OpenRouter MCP server plugs OpenRouter into the AI tools you already use. Once connected, your assistant can pull live OpenRouter data (models, prices, your credits, rankings, and docs) and send quick test messages, all without leaving your editor.
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
