Skip to main content
Glama

ScriptGrain

Humanise text

humanize

Iteratively rewrite text (50 to 15,000 words), or an existing draft by generation_id, to remove the measurable machine-writing tells (evened-out sentence lengths, symmetric hedging, stock connective phrases) while preserving structure, tone and every factual detail — up to 3 rewrite+rescore passes against a target human_score (default 0.85). Costs credits by length: up to 5,000 words 1 credit, up to 10,000 words 2, up to 15,000 words 3. Up to 3,000 words, if the text already clears the target it returns skipped:true for free (pass force=true to rewrite anyway). Over 3,000 words it runs in the background, section by section: the call returns at once with status 'processing' and a job; call get_job until it has succeeded (its result holds the rewritten text). Otherwise returns the final text, before/after scores and remaining signals. Tension with polish: humanising drifts text off the measured voice profile, and a later polish pass can reintroduce the regularity detectors flag. If using both, run polish FIRST and humanize last, then verify the result with the free check_voice_match.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textNoThe text to humanise (50 to 15,000 words). Required unless generation_id is set.
forceNoRewrite even if the baseline already clears the target (still 1 credit).
target_scoreNoTarget human_score to reach (default 0.85).
generation_idNoHumanise this generation's draft instead of pasted text (it must be drafted, not 'outline' or 'generating').

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Discloses substantial behavior beyond the annotations: credit costs tiered by length, the free skip path, the >3,000-word background/async job flow with get_job polling, and the drift tension with polish. Annotations (non-read-only, non-idempotent) are consistent with a credit-charging mutating rewrite.

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?

Front-loads the core purpose, then layers cost, async behavior, and ordering guidance in one dense but well-ordered block. Nearly every clause carries distinct operational value, though the run-on structure could be split for readability.

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 complex tool with credit accounting, async jobs, and sibling interactions, and with no output schema, the description fully covers the return shapes (final text, before/after scores, remaining signals, or a job + status). Nothing essential 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?

Schema coverage is 100% so the baseline is 3, but the description adds real meaning — credit cost tied to text length, what force overrides, and the requirement that generation_id reference a drafted (not outline/generating) piece. It reinforces rather than merely repeats the schema.

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?

States a precise verb+resource (iteratively rewrite text to remove measurable machine-writing tells) and names the specific mechanisms (evened-out sentence lengths, symmetric hedging). An agent can immediately distinguish it from siblings like ai_detect, polish, and check_voice_match.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit routing: when to use force, when it free-skips (<=3,000 words already clearing target), and critically how to sequence against a sibling — 'run polish FIRST and humanize last, then verify with check_voice_match'. This is richer than most definitions.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources