humanizer_forget_phrase
Remove a phrase that was learned from the author's edits.
Instructions
Remove a phrase that was learned from the author's edits.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| phrase | Yes |
Remove a phrase that was learned from the author's edits.
Remove a phrase that was learned from the author's edits.
| Name | Required | Description | Default |
|---|---|---|---|
| phrase | Yes |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the full disclosure burden and does not meet it. It never says whether the removal is permanent or reversible, whether it errors on an unknown phrase, or how it affects future humanization or the voice profile. For a state-mutating removal tool this is a significant gap.
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?
A single short sentence with the action verb front-loaded and no filler. It is appropriately sized, though its brevity comes at the cost of the behavioral detail noted elsewhere.
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 is simple (one required string), but with no annotations and no output schema the description should say what success and failure look like and whether the phrase must already exist. Those essentials are absent, leaving the agent to guess at side effects.
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 one parameter with 0% schema description coverage, so the schema adds nothing beyond type string. The description partially compensates by indicating the value is a previously learned phrase rather than arbitrary text, but it does not specify exact-match requirements, case sensitivity, or source format.
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 pairs a specific verb ('Remove') with a specific resource ('a phrase that was learned from the author's edits'), which also implicitly distinguishes it from the sibling humanizer_learn_from_edit. It stops short of naming that counterpart explicitly, so an agent must infer the relationship.
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?
There is no explicit when-to-use guidance, no mention of checking humanizer_get_rules or humanizer_status first to see which phrases exist, and no stated behavior when the phrase was never learned. Usage is only inferable from the phrase 'learned from the author's edits'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.