Skip to main content
Glama

CreatorsCompanion

Discard a draft

discard_draft
Destructive

Removes a delivered draft the creator does not want from their drafts. It is not refunded (it was delivered) and cannot be brought back from chat. Use it for unsaved drafts; for items in the library use delete_library_item. Returns the id of the discarded draft. Uses no credits.

Input Schema

NameRequiredDescriptionDefault
draft_idYesThe draft id from generate_content or list_library.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true, but the description adds consequences annotations cannot express: the action is not refunded, the draft cannot be recovered from chat, and no credits are consumed. It also discloses the return value, which matters since no output schema exists.

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?

Four short sentences, front-loaded with the action and consequence, then the alternative routing, then the return value. Every sentence carries information, though 'It is not refunded (it was delivered) and cannot be brought back from chat' slightly overlaps with the irreversibility theme in two clauses.

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?

For a single-parameter destructive mutation with no output schema, the description covers purpose, sibling routing, irreversibility, cost, and return value. Nothing an agent needs to decide or call correctly is missing.

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

Parameters3/5

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

There is a single parameter at 100% schema coverage, and the schema already documents it as 'The draft id from generate_content or list_library.' The description adds nothing about the id format or sourcing beyond what the schema states, so the baseline applies.

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 names a specific verb and resource ('Removes a delivered draft... from their drafts') and immediately distinguishes the object class from library items, which is the nearest sibling. An agent can tell this apart from delete_library_item without opening either schema.

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?

It states the when-to-use condition ('Use it for unsaved drafts') and names the explicit alternative for the other case ('for items in the library use delete_library_item'). That is a complete routing rule with no inference required.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.