Superseded listing, not a dead server. This entry was imported from an early Glama registration under com.moltlinestudio.mcp; the same server is listed under its official MCP Registry name — use com.moltlinestudio/humanizer. Endpoint unchanged: https://mcp.moltlinestudio.com/humanizer — still live, still free on the free tier. Only this duplicate entry is deprecated.
An instrumented editing loop for AI drafts: ai_tell_scan scores how human a draft reads with quoted evidence, burstiness_report maps sentence rhythm, voice_fingerprint profiles a real person's writing numerically, and the premium humanize_plan / verify_rewrite pair produces a rewrite brief and proves the result moved toward the target voice.
Scored across 5 tools
Each tool occupies a distinct stage of the edit pipeline (scan → plan → verify) plus two supporting analyzers, and the descriptions explicitly cross-reference siblings with 'Not for X' clauses. The only soft overlap is ai_tell_scan vs burstiness_report, since the scan also reports sentence-rhythm/burstiness metrics and flat rhythm; the boundary is stated but not fully clean.
All names are snake_case and short, with verb_noun used for the action tools (ai_tell_scan, humanize_plan, verify_rewrite). Two tools break the verb-first pattern with noun-first names (burstiness_report, voice_fingerprint), a minor but noticeable inconsistency in an otherwise predictable set.
Five tools is tight and each earns its place: two free diagnostics, one profiling tool, and two premium pipeline steps. No redundancy or filler, and the count matches a focused single-purpose editor.
The surface covers the full lifecycle: detect tells, profile a target voice, generate a rewrite brief, and verify the result against the original. Gaps are minor — no built-in rewrite tool (delegated to the agent by design), and the two most useful steps are license-gated, which leaves free users with analysis only.
Scan a draft for the measurable tells of AI-generated prose. FREE.
Flags stock phrases (with exact quotes), structural reflexes, uniform sentence rhythm, em-dash overuse, and hedging boilerplate. Every flag cites the actual text. Typical input {"text": ""} returns {"reads_human_score": 0-100, "metrics": {"burstiness": ..., "avg_sentence_len": ..., ...}, "evidence": [{"type": "stock_phrase", "quote": "..."}], "note": "..."}.
Use for a first read on whether a draft carries machine-writing signals. Reports measurable patterns, not a verdict on who wrote the text, and must not be used to accuse a person of anything. Not for rhythm detail (burstiness_report) or for a rewrite brief (humanize_plan). Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""} (for example {"error": "empty text"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The draft to scan, at least one full sentence of plain text. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, and the description adds genuinely new behavior: no protocol error is ever raised, errors come back as {"error": ...} with fix guidance, and retry-after-correction is safe. It also discloses the cost model ('FREE') and what the score means and does not mean.
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?
Front-loaded with purpose and cost, then evidence model, then examples, then exclusions. The embedded request/response sketches are the bulkiest part and partially duplicate the output schema, but nothing is truly wasted.
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 one-parameter read-only tool with an output schema, this covers purpose, evidence format, score interpretation, error contract, retry safety, and sibling routing. An agent has everything needed to select and invoke it correctly.
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 coverage is 100%, so the single text parameter is already documented; the description goes further by showing a concrete input shape ({"text": "<draft>"}) and the shape of the response. It adds modest value over the schema rather than new semantic detail about the parameter.
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?
States a specific verb+resource ('Scan a draft for the measurable tells of AI-generated prose') and immediately enumerates what it detects: stock phrases, structural reflexes, sentence rhythm, em-dash overuse, hedging. It also names the sibling tools it is not (burstiness_report, humanize_plan), so an agent can distinguish it without opening schemas.
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?
Explicit when-to-use ('first read on whether a draft carries machine-writing signals') and explicit when-not, naming both alternatives and their distinct purposes. It also constrains scope ethically ('must not be used to accuse a person'), which is a real usage boundary an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Map a draft's sentence rhythm and find where it goes flat. FREE.
Reports per-sentence lengths, the burstiness coefficient, and runs of similar-length sentences. Typical input {"text": ""} returns {"sentence_lengths": [12, 14, 13, 5, 28], "burstiness": 0.52, "flat_runs": [{"sentences": "1-3", "lengths": [12, 14, 13]}], "tip": "..."}.
Use when prose reads flat and sentence-length pattern is the suspect. Not for a full inventory of tells (ai_tell_scan). Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""} (for example {"error": "need 3+ sentences"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The draft to analyze; needs at least 3 sentences. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, but the description adds important context beyond them: it is free, it shows the error-object contract instead of raising protocol errors, and it gives a concrete invalid-input example. It also confirms retry safety after correcting input. This is richer than the annotations alone.
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 front-loads the purpose and usage guidance, and the example output and error contract are useful. It is slightly longer than strictly necessary because it includes both return-value and error examples, but the structure is clear and most content earns its place.
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?
The tool has an output schema, annotations covering safety, and a fully documented single parameter, so the description does not need to carry those burdens alone. It still adds the critical usage distinction from ai_tell_scan and the non-protocol-error behavior, making the definition complete for correct selection and invocation.
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?
There is only one parameter, and schema coverage is 100%, with the schema already stating that 'text' needs at least 3 sentences. The description shows a typical input shape and an error example, but adds little semantic detail beyond the schema's existing documentation of the parameter. The baseline of 3 is appropriate.
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 states a specific verb and resource: 'Map a draft's sentence rhythm and find where it goes flat.' It also names the concrete outputs, sentence lengths and burstiness coefficient, and explicitly distinguishes itself from the sibling ai_tell_scan. An agent can identify the tool's role without inspecting the schema.
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?
It explicitly says when to use it: 'Use when prose reads flat and sentence-length pattern is the suspect.' It also says when not to use it and names the alternative: 'Not for a full inventory of tells (ai_tell_scan).' This is explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Produce a precise rewrite brief that de-AIs a draft, with numeric targets. PREMIUM (license).
Lists every flagged tell with its fix and sentence-rhythm surgery targets; when a voice_fingerprint result is supplied, adds numeric targets to hit that person's voice. Apply the brief with your agent, then confirm with verify_rewrite. Typical input {"text": "", "fingerprint": <voice_fingerprint result>} returns {"current_score": 0-100, "edit_list": ["..."], "numeric_targets": {...}, "process": ..., "integrity_note": ...}.
Use after a scan has identified what to fix; returns a brief, not rewritten prose. Not for checking whether a rewrite worked (verify_rewrite). Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""}. Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The AI draft to plan a rewrite for. | |
| fingerprint | No | Optional voice profile object exactly as returned by voice_fingerprint; omit for a style-only pass. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, but the description adds context annotations cannot: a PREMIUM license gate, and that invalid input never raises a protocol error — it returns {"error": ...} so retry after correction is safe. It also discloses that supplying a fingerprint changes the output (adds person-specific numeric targets), which is real behavioral information.
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?
Front-loaded with the one-sentence purpose, then scope, then workflow, then errors — a sensible order. It loses a point because the 'typical input/returns' JSON sketch partly restates a return shape the output schema already carries, and the license note is wedged mid-paragraph rather than flagged up front.
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 two-parameter, nested-object tool with an output schema, this covers everything an agent needs: precondition, what it returns conceptually, what it does not do, the retry/error contract, and the next step in the pipeline. Nothing material is left to inference.
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 coverage is 100% and the fingerprint parameter is already documented as a voice_fingerprint output, so the baseline would be 3. The description goes further by explaining the consequence of passing it — 'when a voice_fingerprint result is supplied, adds numeric targets to hit that person's voice' — which the schema does not state. Marginal but genuine added meaning.
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?
States a specific verb and artifact — 'produce a precise rewrite brief that de-AIs a draft, with numeric targets' — and immediately disambiguates with 'returns a brief, not rewritten prose.' It also separates itself from verify_rewrite by name, so an agent can pick it out of a sibling set that includes ai_tell_scan and voice_fingerprint without opening any schema.
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?
'Use after a scan has identified what to fix' gives the precondition, and 'Not for checking whether a rewrite worked (verify_rewrite)' gives an explicit exclusion with the alternative named. The follow-on workflow ('Apply the brief with your agent, then confirm with verify_rewrite') tells the agent where this sits in the sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a rewrite actually improved: score delta, meaning check, voice distance. PREMIUM (license).
Compares reads-human score before/after, a meaning-preservation proxy, and (with a fingerprint) numeric distance to the target voice. Typical input {"original": "", "rewrite": ""} returns {"score_before": N, "score_after": N, "score_delta": N, "content_word_retention_pct": N, "remaining_tells": [...], "verdict": "Improved: ship it" | "Marginal: ..."}.
Use only when both the before and the after text are available. Not for scoring a single draft (ai_tell_scan). Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""} (for example {"error": "both texts must be non-empty"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| rewrite | Yes | The same content after the humanize_plan edits. | |
| original | Yes | The draft before editing. | |
| fingerprint | No | Optional voice profile object exactly as returned by voice_fingerprint, to measure distance to the target voice. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real context beyond the annotations: a non-throwing error contract with a fix-it message, an explicit retry-safety statement, verdict string values, and a PREMIUM/license gate. The license gate is the one soft spot — it flags that something is restricted but never says what happens if the license is absent.
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?
Front-loaded claim, then inputs, then return shape, then usage rule, then error behavior — a deliberate and efficient order with no filler. The inline JSON examples are dense but productive, though the compressed parenthetical style takes slightly more parsing than plain prose would.
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 3-parameter premium tool with a nested optional object, the description covers selection, input shape, return fields, verdict values, and failure/retry behavior. The return-value restatement is partially redundant with the output schema, but it does no harm and leaves no gap an agent would have to guess at.
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 coverage is 100%, so the baseline is 3; the description goes further by showing a typical {original, rewrite} payload and by explaining what the optional fingerprint parameter unlocks ('numeric distance to the target voice'), which the schema only gestures at with a pointer to voice_fingerprint.
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?
States a concrete verb and resource (verify a rewrite) and enumerates the exact outputs (score delta, meaning check, voice distance), which distinguishes it immediately from ai_tell_scan and burstiness_report.
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?
Explicitly names the precondition ('Use only when both the before and the after text are available') and the exclusion with the sibling to use instead ('Not for scoring a single draft (ai_tell_scan)'). Nothing about tool selection is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a measurable voice profile from samples of a person's real writing. FREE.
Feed it 2+ samples (emails, posts, essays; 150+ words total) and use the result with humanize_plan / verify_rewrite. Typical input {"samples": ["", ""]} returns {"label": "my-voice", "target_metrics": {"avg_sentence_len": ..., "burstiness": ..., ...}, "favorite_words": [...], "signature_habits": ["..."], "words_analyzed": N}.
Use on samples the person actually wrote, to build a target profile. Not for scoring an unknown draft (ai_tell_scan) and not on text the person did not write. Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""} (for example {"error": "need 150+ words of real writing across the samples"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | Optional name for this voice profile. Default "my-voice". | my-voice |
| samples | Yes | List of real writing samples by the same person; 150+ words combined across all samples. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful behavioral context beyond annotations: invalid input returns an error object instead of a protocol error, and retrying after correction is safe. It does not deeply discuss permissions or rate limits, but those appear low-risk for this local analysis tool.
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 core purpose and constraints are front-loaded, and most sentences add useful selection or invocation guidance. The response example and error-handling paragraph are somewhat long, especially because an output schema exists, but they still reduce ambiguity for an agent.
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 rich annotations, full schema coverage, and an output schema, the description is complete for selecting and invoking the tool. It covers the minimum sample requirements, intended use, exclusions, downstream use, error behavior, and retry safety.
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 coverage is 100%, so the schema already documents both parameters clearly. The description still adds practical meaning by specifying at least 2 samples, 150+ combined words, real writing by the same person, and a typical input shape. It does not add much about the optional label beyond what the schema says.
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 states a specific operation: build a measurable voice profile from a person's real writing samples. It distinguishes the tool from sibling ai_tell_scan and explains how its output connects to humanize_plan and verify_rewrite. An agent can identify the resource, action, and downstream role without ambiguity.
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?
It gives explicit inclusion criteria: use samples the person actually wrote, with 2+ samples and 150+ words total. It also names exclusions and alternatives: not for scoring an unknown draft, which belongs to ai_tell_scan, and not for text the person did not write.
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.
ai_tell_scan1 field changedInput schema / properties / text / descriptionPrevious value: -"The draft to scan — at least one full sentence of plain text."New value: +"The draft to scan, at least one full sentence of plain text."ai_tell_scanburstiness_reporthumanize_planverify_rewritevoice_fingerprint
Add one secure layer between your agents and this server.