Skip to main content
Glama
Sign In

MCPEmails

by com.mcpemails
OverviewDiscussionsAdmin

List Scheduled Sends

schedule_list
Read-onlyIdempotent

List pending scheduled email sends for the workspace. Returns all messages with status 'pending' or 'sending', ordered by scheduled send time (earliest first). Optionally filter by inbox. The returned id is what the schedule tool (action 'cancel') takes to stop a pending send before dispatch.

Input Schema

NameRequiredDescriptionDefault
inboxNoOptional. The same filter by email address.
limitNoResults per page.
inbox_idNoOptional. When provided, restricts results to scheduled sends for that inbox.

Output Schema

NameRequiredDescriptionDefault
notesNoServer notes about how this call was handled — for example an argument that was not applied because the selected action does not accept it. Written by MCPEmails, not taken from any message, and absent when there is nothing to report.
totalYes
scheduled_sendsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / notes / description
      Previous value: -"Server notes about how this call was handled — for example an argument that was not applied because the selected action does not accept it. Written by MCP Emails, not taken from any message, and absent when there is nothing to report."New value: +"Server notes about how this call was handled — for example an argument that was not applied because the selected action does not accept it. Written by MCPEmails, not taken from any message, and absent when there is nothing to report."
  2. Changed1 schema field changed
    • addedInput schema / properties / inbox
      Added value: +{
+  "description": "Optional. The same filter by email address.",
+  "type": "string"
+}
  3. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds real value beyond them: the status filter applied server-side, the sort order (earliest first), and the hand-off contract where the returned id is the cancel key. It does not discuss result volume or paging beyond the schema's limit parameter.

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 sentences, front-loaded with purpose and scope, then filtering, then the id contract. Every sentence carries information an agent needs and none is redundant.

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 read-only list tool with an output schema and full parameter coverage, the description supplies everything an agent needs: what is returned, in what order, how to narrow it, and how the result feeds the cancel path.

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 description coverage is 100%, so all three parameters are already documented and the baseline is 3. The description only says 'optionally filter by inbox' and does not disambiguate the two distinct filter parameters (email address vs. inbox_id UUID), so it adds little beyond the schema.

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?

States a specific verb and resource ('List pending scheduled email sends') along with the exact status filter ('pending' or 'sending') and the returned ordering. It also distinguishes itself from the write-side sibling by naming the schedule tool's 'cancel' action as the consumer of the returned id.

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?

Implies the use case clearly: fetch pending sends, optionally narrowed by inbox, and note that the returned id feeds the cancel action. It never states when NOT to use it or why one would pick it over bulk_cancel or draft_list, so it stops short of full alternative routing.

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

All MCPEmails toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources