Skip to main content
Glama

humanizer_voice_profile

Analyze sample documents in a voice folder to measure sentence length, contractions, and dash usage, then generate a voice profile for matching an author's writing style. Needs at least 150 words of samples.

Instructions

Measure the author's writing habits from the samples in the voice folder.

Returns the folder path, files read, word count, measured habits (sentence length, contractions, dashes) and a short model-written description of the voice. At least 150 words of samples are needed.

Input Schema

NameRequiredDescriptionDefault
backendNo
refreshNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description carries the full burden and does a fair job: it discloses the inputs consumed (samples in a fixed voice folder), the 150-word minimum, and that a model-written description is produced (implying an LLM call with latency/cost). It does not say whether anything is written to disk or cached, whether the call is read-only, or how failures surface.

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?

Three short sentences, front-loaded with purpose followed by the return payload and then the constraint. No filler, though the return-value list is a flat enumeration that could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description compensates for the absent output schema by sketching the return payload, which is the right move. However, for a two-parameter tool with zero annotation and zero schema coverage, leaving 'backend' and 'refresh' undefined is a real completeness gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and neither parameter is mentioned in the description. 'Backend' is completely unexplained — an agent cannot tell what values are valid or what it selects. 'Refresh' is only obliquely inferable from the caching behaviour the tool implies, not stated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Measure the author's writing habits from the samples in the voice folder.' This is clearly distinct from the assess/lint/humanize siblings, though it never names or contrasts with any of them, leaving the agent to infer the division of labor.

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

Usage Guidelines3/5

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

The one hard precondition — 'At least 150 words of samples are needed' — is stated, which is genuinely useful. But there is no guidance on when to choose this over humanizer_assess_text or humanizer_learn_from_edit, and no note on what happens below the threshold (error vs empty profile).

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