humanpen-mcp

Official

Overview Schema Source Related Servers Discussions Admin

Humanize a document

humanize_document

Rewrites .docx or .pptx files to read as human-written and lower AI detector scores while preserving layout and citations. Targets only flagged passages when given a Turnitin/iThenticate report.

Instructions

Rewrite a .docx or .pptx so it reads as human-written and scores lower on AI detectors, keeping meaning, citations, tables and layout. Optionally pass a Turnitin/iThenticate AI report to rewrite only the passages it flagged. If a fresh report still flags the result, run this tool again on the rewritten file with that new report - only the still-flagged passages are touched, and balanced remains the right strategy for the second pass. Saves the result next to the source and returns its path. COSTS CREDITS at 100 per 1,000 words processed (10 minimum) - say so and get agreement first.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "document_path": "<document_path>"
    },
    "name": "humanize_document"
  }
}

Input Schema

Name	Required	Description
`segments`	No	Per-passage word control (optional): each item is a flagged passage plus its own min_words/max_words. Get the passage texts from read_detection_report and pass report_path alongside so the report defines scope. Experimental, same caveat as min_words. Cannot combine with the whole-document min_words/max_words.
`strategy`	No	Rewriting intensity; balanced is the usual first choice, aggressive rewrites more heavily
`max_words`	No	Upper word bound for the rewritten document (optional; omit for no limit). Same experimental caveat and exclusivity as min_words.
`min_words`	No	Lower word bound for the rewritten document (optional; omit for no limit). Experimental - a word limit noticeably weakens AI-rate reduction, so omit unless the user requires a length. Cannot combine with report_path or segments.
`output_path`	No	Where to write the result; defaults to beside the source
`report_path`	No	Path to a Turnitin/iThenticate AI report PDF; only its flagged passages are rewritten
`instructions`	No	Extra requirements for this job
`wait_seconds`	No	How long to wait before returning a job id (default 55)
`document_path`	Yes	Absolute path to the .docx or .pptx to rewrite

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv1.4.0Aug 12, 2026

addedInput schema / properties / max_words

Added value: +{
+  "description": "Upper word bound for the rewritten document (optional; omit for no limit). Same experimental caveat and exclusivity as min_words.",
+  "exclusiveMinimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / min_words

Added value: +{
+  "description": "Lower word bound for the rewritten document (optional; omit for no limit). Experimental - a word limit noticeably weakens AI-rate reduction, so omit unless the user requires a length. Cannot combine with report_path or segments.",
+  "exclusiveMinimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / segments

Added value: +{
+  "description": "Per-passage word control (optional): each item is a flagged passage plus its own min_words/max_words. Get the passage texts from read_detection_report and pass report_path alongside so the report defines scope. Experimental, same caveat as min_words. Cannot combine with the whole-document min_words/max_words.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "max_words": {
+        "description": "Upper word bound for this passage once rewritten",
+        "exclusiveMinimum": 0,
+        "type": "integer"
+      },
+      "min_words": {
+        "description": "Lower word bound for this passage once rewritten",
+        "exclusiveMinimum": 0,
+        "type": "integer"
+      },
+      "text": {
+        "description": "The exact flagged passage text to bound",
+        "minLength": 1,
+        "type": "string"
+      }
+    },
+    "required": [
+      "text"
+    ],
+    "type": "object"
+  },
+  "minItems": 1,
+  "type": "array"
+}

changedInput schema / properties / strategy / description

Previous value: -"Rewriting intensity; balanced is the usual first choice"New value: +"Rewriting intensity; balanced is the usual first choice, aggressive rewrites more heavily"

changedInput schema / properties / strategy / enum

Previous value: -[
-  "conservative",
-  "balanced",
-  "aggressive",
-  "balanced_v2",
-  "aggressive_v2"
-]New value: +[
+  "balanced",
+  "aggressive"
+]

First observedv1.0.0Aug 2, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only say destructiveHint=false and readOnlyHint=false; the description adds the substantive behavior: 100 credits per 1,000 words (10 minimum) with a requirement to disclose and get consent, the result saved beside the source with a returned path, and the iterative second-pass semantics. That is far beyond what the annotations convey.

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 core action and preserved invariants are front-loaded, and the credit warning is capitalized and placed where it will be read. It is longer than typical but each sentence carries operational information, with only mild redundancy between the description and the schema on word-limit caveats.

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 paid, iterative mutation tool with no output schema, the description covers cost and consent, result location and return value, the report-scoped mode, and the rerun workflow. An agent has everything needed to call it and set expectations 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 baseline is 3, but the description adds meaning the schema doesn't: 'balanced' remains correct for a second pass, and report_path scopes rewriting to flagged passages. It doesn't add syntax detail for output_path, instructions, or wait_seconds, keeping it at 4.

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 opening sentence names a specific verb (rewrite), the exact resource types (.docx/.pptx), the goal (lower AI-detector scores) and the invariants preserved (meaning, citations, tables, layout). An agent can distinguish this from condense_document or translate_document without opening the schema.

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?

It gives explicit when-to-use detail: optionally pass a Turnitin/iThenticate report to scope rewriting, and rerun with a fresh report if the result is still flagged. It also mandates getting user agreement before spending credits. It stops short of naming alternatives like free_rehumanize for the free path, so not a full 5.

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

Deploy Server