Create labeled local drafts from self-contained text using translate, summarize, rewrite, extract, or classify modes. Read-only output for drafting, not for facts or operational work.
Create a labeled local draft from self-contained user-provided text only; never use for facts, high-stakes or operational work.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | ||
| input | Yes | ||
| instruction | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does add useful context: the result is a draft, it is local, and it should not be used for authoritative or operational purposes. However, it does not mention side effects, persistence, output format, or failure behavior, leaving meaningful transparency gaps.
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 is a single sentence with no filler and places the core action first, followed by an important exclusion. It earns its length, though the phrase 'labeled local draft' is somewhat opaque and could have been clarified without much additional cost.
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 3 parameters, no per-parameter schema descriptions, no output schema, and no annotations. The description only sketches scope and exclusions; it leaves the semantics of the five modes, the optional instruction, and the expected return value undefined. This is not enough for an agent to invoke the tool confidently beyond the simplest case.
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 description coverage is 0%, so the description must compensate, but it does not explain `mode`, `input`, or `instruction`. 'User-provided text' loosely maps to `input`, yet it adds no meaning about the mode enum or how `instruction` modifies behavior.
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 clearly states a specific action ('Create a labeled local draft') and resource ('self-contained user-provided text'), which makes the tool's core function identifiable. It does not enumerate the processing modes or clarify what 'labeled' means, but it is still substantially clearer than a tautology or vague purpose.
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?
The description provides an explicit negative usage boundary: 'never use for facts, high-stakes or operational work.' It also implies appropriate use through 'local draft' and 'self-contained user-provided text only.' There are no sibling tools to compare with, so the lack of alternative names is not a gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.