Skip to main content
Glama

Send the pending drafts

approve_batch
Destructive

SENDS REAL EMAIL. Approves every draft still pending in the batch and starts delivering them to real people, staggered over time. Show the drafts to the person first with list_pending_drafts and get their agreement. Discard anything they do not want before calling this. It cannot be undone.

Input Schema

NameRequiredDescriptionDefault
batchIdYesFrom list_pending_drafts. Confirms which batch is being sent.
workspaceIdYesWhich site to act on. Call get_status with no arguments to list them.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered, yet the description still adds real-world consequence: real email to real people, staggered delivery over time, and no undo. These are behavioral traits the annotations do not express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The critical warning is front-loaded in the first phrase, followed by what happens, then the required workflow, then the irreversibility clause. Four short sentences, every one load-bearing, no filler.

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 destructive action tool with no output schema, it covers the consequence, the prerequisite verification step, the cleanup action, and non-reversibility. Nothing an agent needs to decide whether and how to call it 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?

Schema coverage is 100% and both parameter descriptions already document batchId (from list_pending_drafts) and workspaceId (from get_status). The description only restates batch scope ('every draft still pending in the batch') without adding format or lookup detail beyond the schema, so the baseline 3 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 ('approves every draft still pending in the batch and starts delivering them'), and the leading 'SENDS REAL EMAIL' disambiguates it from read-only siblings like list_pending_drafts and skip_batch. An agent can tell exactly what this does without opening the 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 gives explicit ordering and preconditions: show drafts to the person with list_pending_drafts and get agreement first, discard unwanted items before calling. It names the sibling to consult and the action to take beforehand, and states the irreversible nature as a final caution.

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.