delete_draft
Deletes a saved Naver Mail draft by draft ID, helping AI agents remove unwanted drafts and keep mailboxes clean.
Instructions
Deletes a draft.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| draftId | Yes |
Deletes a saved Naver Mail draft by draft ID, helping AI agents remove unwanted drafts and keep mailboxes clean.
Deletes a draft.
| Name | Required | Description | Default |
|---|---|---|---|
| draftId | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is known. The description adds nothing beyond that: it does not say whether the deletion is permanent, whether the draft is recoverable or moved to trash, or what authorization is required — all valuable context for a destructive operation.
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?
It is front-loaded and completely free of waste, but it is under-specified rather than concise: one four-word sentence leaves no room for scope, consequences, or parameter notes.
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?
For a destructive, irreversible-sounding mutation with no output schema and no annotation-level detail about permanence, the description should confirm what happens to the draft and whether recovery is possible. Neither is covered, so an agent cannot fully predict the effect of calling it.
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 single required parameter draftId is undocumented everywhere. The description does not mention the identifier at all, leaving the agent to infer its meaning and format entirely from the property name.
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 with a specific resource ("Deletes a draft"), so the operation itself is unambiguous. However, it offers nothing to separate it from the many sibling mutation tools such as trash_message, update_draft, or delete_label, and the title is null so no extra signal exists.
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 statement of when to use this versus update_draft, trash_message, or any other removal path. The only implied guidance is the obvious mapping of "delete" to "draft"; no prerequisites, alternatives, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.