Skip to main content
Glama
alexstockman1

autoMessage MCP Server

list_drafts

Read-only

Retrieve outbound message drafts and filter by status to see what is queued for the Mac agent, held, sent, or failed.

Instructions

List outbound drafts. Useful for checking what's queued for the Mac agent, what is held by the new-outreach limit, what was recently sent, or what failed. By default returns drafts in any state; filter with status (preferred), or sent / send_error.

Input Schema

NameRequiredDescriptionDefault
sentNoFilter: true = delivered/cancelled, false = pending dispatch.
limitNoMax number of drafts (1-200). Default 50.
statusNoFilter on lifecycle status. "held" = parked by the new-outreach limit (resumes on its own); "blocked" = subscription_required / recipient_opted_out.
send_errorNoFilter: true = drafts that failed to send (held drafts are not failures and are excluded).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.2

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already establish this as a safe read-only operation. The description adds useful behavioral context—default returns drafts in any state, and status is the preferred filter—but does not cover ordering, pagination behavior, or return shape beyond what the schema implies.

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?

Three compact sentences, front-loaded with the core action and followed by use cases and default/filter guidance. No filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only list tool with full schema coverage and safety annotations, the description covers purpose, default scope, filter preference, and practical use cases. It lacks explicit detail on ordering or how filters combine, but no output schema exists to require return-value explanation.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds a small but meaningful preference signal by recommending 'status' over the boolean shorthand filters, which helps an agent choose among overlapping filter parameters.

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 opens with a specific verb and resource: 'List outbound drafts.' It immediately distinguishes the tool from siblings like get_draft_status and cancel_pending_draft by focusing on listing rather than status lookup or cancellation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete usage contexts—checking the Mac agent queue, held drafts, recently sent, or failed—and states the default behavior. It also expresses a filter preference ('status (preferred)') but does not explicitly name alternative tools or exclusion conditions.

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