Skip to main content
Glama

Moltline Humanizer

by com.moltlinestudio

Verify Rewrite

verify_rewrite
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rewriteYesThe same content after the humanize_plan edits.
originalYesThe draft before editing.
fingerprintNoOptional voice profile object exactly as returned by voice_fingerprint, to measure distance to the target voice.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds valuable behavioral context: the tool never raises a protocol error but returns an error object, and it provides a typical output example. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a bolded one-line summary, followed by detailed explanation, usage notes, and error handling. Every sentence adds value without redundancy.

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?

Given the tool has an output schema, the description adequately covers input format, usage constraints, error behavior, idempotency, and licensing. It also references the sibling tool for single-draft scoring, making the context complete.

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 description coverage is 100%, so a baseline of 3. The description adds meaning by showing the typical input format and clarifying that the optional fingerprint is used to 'measure distance to the target voice', which goes beyond the schema's static type description.

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 description states the tool 'Verify a rewrite actually improved: score delta, meaning check, voice distance', providing a specific verb and resource. It distinguishes from the sibling ai_tell_scan by explicitly noting this tool is not for scoring a single draft.

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?

The description gives explicit guidance: 'Use only when both the before and the after text are available. Not for scoring a single draft (ai_tell_scan).' It also notes that every call is safe to retry after correcting input, which guides on error recovery.

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

All Moltline Humanizer toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.8/5.0
Disambiguation5/5

Each tool has a clearly distinct role: ai_tell_scan is a broad AI-tell scanner, burstiness_report focuses on sentence rhythm, humanize_plan creates a rewrite brief, verify_rewrite checks a rewrite, and voice_fingerprint builds a voice profile. Cross-references in descriptions explicitly clarify boundaries between overlapping functions.

Naming Consistency3/5

Tool names are descriptive but follow mixed patterns: 'burstiness_report' and 'voice_fingerprint' are noun phrases, 'verify_rewrite' is an imperative verb phrase, while 'ai_tell_scan' and 'humanize_plan' are ambiguous combinations. There is no consistent verb_noun convention across the set.

Tool Count5/5

Five tools is well-scoped for a humanization server, covering scanning, rhythm analysis, planning, verification, and voice profiling without redundancy or bloat. Each tool earns its place in the workflow.

Completeness5/5

The tool surface covers the full intended workflow: scan for tells, analyze rhythm, generate a rewrite brief, verify the rewrite, and build a voice fingerprint for personalization. The only absent operation—actually rewriting—is intentionally delegated to the agent, so there are no dead ends.

Resources