Skip to main content
Glama
alexstockman1

autoMessage MCP Server

by alexstockman1
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

send_imessage

Destructive

Sends an iMessage from the user's Mac via Messages.app, returning a draft ID for delivery confirmation; queues messages when the new-outreach limit is reached.

Instructions

Send an iMessage from the user's Mac. Creates a draft that the user's Mac agent picks up and dispatches via Messages.app. Returns the draft id; use get_draft_status to confirm delivery. The recipient must be a valid phone number in E.164 format (+14155551234) or an email address that the recipient uses for iMessage. If the user's new-outreach limit is reached (N unreplied conversations messaged in a rolling 24-hour window), the message is STILL ACCEPTED and queued: the response carries meta.queued (reason, limit, used, resumesAt = earliest moment a slot frees) and the draft's status is "held" until earlier sends age out of the window or the user raises the limit in Settings — tell the user it is queued, not failed. A 403 recipient_opted_out means the recipient texted STOP: do not retry.

Input Schema

NameRequiredDescriptionDefault
toYesRecipient phone (E.164, e.g. "+14155551234") or email address.
bodyYesMessage body. Max 4096 characters.
response_webhook_urlNoOptional. HTTPS URL that will receive POST notifications when the recipient replies in this conversation. Persists across the conversation thread, not just the single send.
response_webhook_eventsNoOptional. Subset of events the webhook subscribes to. Defaults to all events. Common values: "message_received".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.2

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing that sending creates a draft, that messages are still accepted and queued when the outreach limit is reached, what meta.queued contains, and that held drafts remain until capacity frees. It also explains the 403 STOP behavior, which is critical context for a destructive, open-world send operation.

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 description is front-loaded with the core action and draft mechanism, then moves through delivery confirmation, recipient format, queue semantics, and opt-out handling. Every sentence carries operational value for a tool with non-obvious queuing and error behavior.

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?

With no output schema, the description still explains what is returned (a draft id) and how queued responses differ (meta.queued and status 'held'). It covers the main edge cases an agent needs: invalid recipient format, outreach limit, and STOP opt-out.

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 the schema already documents recipient format, body limits, and webhook parameters. The description reinforces the E.164/email recipient requirement but does not add meaning beyond the schema for the webhook parameters; baseline 3 is appropriate.

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: 'Send an iMessage from the user's Mac.' It immediately explains the draft-based mechanism, distinguishing it from sibling tools like get_draft_status and cancel_pending_draft.

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?

Explicitly directs the agent to use get_draft_status to confirm delivery, states the required recipient format, explains the queued-limit case, and specifies that a 403 recipient_opted_out must not be retried. This leaves little ambiguity about when and how to use the tool versus alternatives.

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

Deploy Server

Other Tools