Amazon Q Developer can read inboxes, send messages, manage approval queues, and tag emails — all within the same session where it writes and deploys your AWS code.
Amazon Q Developer integrates MCP servers into its IDE and terminal workflows, letting it call external tools alongside its built-in AWS and codebase context. Adding MultiMail as an MCP server gives Q Developer access to email infrastructure purpose-built for agents: inbound parsing, graduated oversight modes, and a formally verified authorization model.
Once configured, Q Developer can check a support inbox while reviewing a Lambda function, send a deployment notification from the terminal, or route an email to a human approver before acting — without switching tools or contexts.
MultiMail's MCP server exposes 44 tools over stdio or SSE transport. Amazon Q Developer supports both. The stdio path (via npx) is the lower-friction starting point; SSE is useful for persistent team setups where the server runs as a shared service.
All email actions are governed by the oversight mode you set on the mailbox. With `gated_send`, Q Developer can read freely but each outbound message queues for your approval before delivery — a practical default when you're still calibrating what the agent should send on your behalf.
Amazon Q Developer requires an AWS Builder ID or IAM Identity Center sign-in. Install the IDE extension (VS Code or JetBrains) or the terminal CLI. Then sign into MultiMail at multimail.dev and create an API key under Settings → API Keys. Copy the `mm_live_...` key — you'll add it to the MCP config in step 3.
Amazon Q Developer reads MCP server definitions from `~/.aws/amazonq/mcp.json` on macOS and Linux, or `%USERPROFILE%\.aws\amazonq\mcp.json` on Windows. Create the file if it does not exist. The top-level key is `mcpServers`, matching the same shape used by Claude Desktop and Cursor.
mkdir -p ~/.aws/amazonq
touch ~/.aws/amazonq/mcp.jsonEdit `~/.aws/amazonq/mcp.json` to register the MultiMail server. The stdio transport runs the server via npx on demand — no separate install step needed. Set `MULTIMAIL_API_KEY` to your live key. The `MULTIMAIL_DEFAULT_MAILBOX` env var is optional but saves you from specifying a mailbox on every tool call.
{
"mcpServers": {
"multimail": {
"command": "npx",
"args": ["-y", "@multimail/mcp-server"],
"env": {
"MULTIMAIL_API_KEY": "mm_live_your_key_here",
"MULTIMAIL_DEFAULT_MAILBOX": "[email protected]"
}
}
}
}Reload the IDE window or restart the Q Developer terminal session. Type a prompt that exercises the email tools — for example: "Check the inbox for [email protected] and summarize unread messages." If Q Developer lists tool calls to `check_inbox` and returns results, the server is connected. If it fails, confirm your API key is valid by running: `curl -H 'Authorization: Bearer $MULTIMAIL_API_KEY...' https://api.multimail.dev/v1/mailboxes`
Before using Q Developer to send email autonomously, configure an oversight mode on the mailbox. `gated_send` is the recommended starting point: reads are immediate, outbound messages queue for your approval. Set it via the MultiMail dashboard under Mailboxes → Oversight, or use the `create_mailbox` MCP tool with `oversight_mode: gated_send` when provisioning a new mailbox.
| Tool | Description | Example |
|---|---|---|
| check_inbox | Lists emails in a mailbox with optional filters for read/unread status, tags, sender, and date range. Returns message IDs, subjects, senders, and timestamps. | Q Developer checks for new support tickets in a shared inbox before generating a triage summary in a Markdown file. |
| read_email | Fetches the full content of a single email by ID, including headers, plain-text and HTML body, and attachment metadata. | After finding an unread message from an AWS cost alert, Q Developer reads the full email to extract the affected service and dollar amount. |
| send_email | Sends a new email from a MultiMail mailbox. Accepts to, cc, bcc, subject, body (plain or HTML), and reply-to fields. Subject to the mailbox's oversight mode. | Q Developer sends a deployment completion notice to a stakeholder list after a successful CDK stack update in the terminal. |
| reply_email | Sends a reply to an existing message, preserving the thread. Accepts the original message ID and a reply body. | Q Developer replies to a customer bug report with a diagnosis and estimated fix timeline after inspecting the relevant Lambda logs. |
| get_thread | Returns all messages in an email thread in chronological order, useful for understanding conversation history before composing a response. | Q Developer reads a full support thread before drafting a resolution email, avoiding repeated questions the customer already answered. |
| decide_email | Approves or rejects a message that is pending human approval in a `gated_send` or `gated_all` mailbox. Used to programmatically process the approval queue. | A separate automation reviews the approval queue and calls `decide_email` to approve messages that meet content policy rules. |
| list_pending | Returns all messages currently awaiting approval in the mailbox's oversight queue, with their content and metadata. | Q Developer surfaces pending outbound messages in the terminal so a developer can review them before approving from the dashboard. |
| tag_email | Applies one or more string tags to an email. Tags are queryable via `check_inbox` and useful for routing, triage, and analytics. | Q Developer tags inbound emails as `p0-bug`, `billing`, or `feature-request` after classifying them by content. |
| search_contacts | Searches the contact history associated with a mailbox by name, email address, or domain. Returns send/receive history and tags. | Q Developer looks up a sender's contact record to check prior support interactions before drafting a reply. |
| create_mailbox | Provisions a new mailbox with a specified address, oversight mode, and optional webhook URL for inbound events. | Q Developer creates a dedicated `[email protected]` mailbox as part of a CI/CD setup script. |
| cancel_message | Cancels a message that is queued but not yet delivered — either pending in an oversight queue or scheduled for future delivery. | Q Developer cancels a queued notification after detecting the underlying deployment it was tracking was rolled back. |
# Amazon Q Developer terminal prompt
Check the inbox for [email protected].
For each unread message:
1. Read the full email body.
2. Classify as: p0-incident, billing, bug-report, or feature-request.
3. Apply the matching tag via tag_email.
4. Add a one-line summary to TRIAGE.md with the sender, subject, tag, and message ID.
Do not send any replies. Mark each message as read after tagging.A Q Developer terminal prompt that reads unread messages, classifies them by urgency, and writes a triage summary to a Markdown file. Useful for teams that route support email to a shared inbox and want Q Developer to handle initial classification alongside code work.
"cm">#!/usr/bin/env bash
"cm"># Called from cdk-post-deploy.sh after `cdk deploy` exits 0
STACK_NAME=$1
RECIPIENT=$2
curl -s -X POST https://api.multimail.dev/v1/send \
-H "Authorization: Bearer ${MULTIMAIL_API_KEY}" \
-H "Content-Type: application/json" \
-d "{
\"from\": \"[email protected]\",
\"to\": \"${RECIPIENT}\",
\"subject\": \"[Deployed] ${STACK_NAME}\",
\"text\": \"CDK stack ${STACK_NAME} deployed successfully at $(date -u +%Y-%m-%dT%H:%M:%SZ).\"
}"Shell snippet that invokes the MultiMail REST API directly after a CDK stack deployment completes. Equivalent to what Q Developer does internally when you ask it to send a notification — useful if you want to wire this into a CI script instead.
import requests
import sys
API_KEY = "mm_live_your_key_here"
MAILBOX = "[email protected]"
BASE = "https://api.multimail.dev/v1"
HEADERS = {"Authorization": f"Bearer {API_KEY}"}
def main():
r = requests.get(f"{BASE}/pending", headers=HEADERS,
params={"mailbox": MAILBOX})
r.raise_for_status()
messages = r.json()["messages"]
if not messages:
print("No pending messages.")
return
for msg in messages:
print(f"\nTo: {msg[&"cm">#039;to']}")
print(f"Subject: {msg[&"cm">#039;subject']}")
print(f"Body preview: {msg[&"cm">#039;text'][:200]}")
choice = input("Approve? [y/n]: ").strip().lower()
action = "approve" if choice == "y" else "reject"
resp = requests.post(
f"{BASE}/decide/{msg[&"cm">#039;id']}",
headers=HEADERS,
json={"action": action}
)
resp.raise_for_status()
print(f" → {action}d")
if __name__ == "__main__":
main()Python script that lists pending outbound messages and prompts for approval interactively. Pairs with Q Developer's `gated_send` mode: Q Developer composes and queues messages, this script gives a human a clean approve/reject flow in the terminal.
import requests
import os
API_KEY = os.environ["MULTIMAIL_API_KEY"]
ENV = os.environ.get("DEPLOY_ENV", "dev")
BASE = "https://api.multimail.dev/v1"
overview_mode = "gated_send" if ENV != "prod" else "monitored"
resp = requests.post(
f"{BASE}/mailboxes",
headers={"Authorization": f"Bearer {API_KEY}"},
json={
"address": f"app-{ENV}@yourdomain.multimail.dev",
"oversight_mode": overview_mode,
"webhook_url": f"https://api.yourdomain.com/webhooks/email/{ENV}"
}
)
resp.raise_for_status()
mailbox = resp.json()
print(f"Provisioned: {mailbox[&"cm">#039;address']} (oversight={mailbox['oversight_mode']})")Creates a dedicated MultiMail mailbox as part of infrastructure provisioning. Run this once per environment (dev, staging, prod) so each stack has an isolated outbound identity with its own oversight mode.
Setting the `MULTIMAIL_DEFAULT_MAILBOX` environment variable in the MCP config means you can ask Q Developer to "check the inbox" without specifying the full address each time. Useful in solo setups. In multi-mailbox team environments, omit it and name the mailbox explicitly in prompts so Q Developer doesn't guess.
When you first give Q Developer email access, `gated_send` lets you observe what it tries to send without blocking its read capabilities. After a week of reviewing the approval queue and seeing consistent quality, switch to `monitored` — Q Developer sends immediately and you receive BCC-style notifications. This matches how you'd phase in autonomy for any new agent capability.
Ask Q Developer to call `tag_email` before writing any summary or report. Tags written now become filter keys for `check_inbox` later — so a follow-up prompt can retrieve only `p0-incident` messages without re-reading the full inbox. This compounds across sessions; untagged inboxes require re-classification from scratch each time.
MultiMail API keys can be scoped to specific mailboxes. Create a dedicated key for Q Developer that covers only the mailboxes relevant to your development workflow — not your billing or customer-facing addresses. If Q Developer's session is ever compromised or a prompt injection occurs via email content, the blast radius is limited to scoped mailboxes.
If your team runs a shared Amazon Q Developer environment or a centralized MCP proxy, configure the MultiMail server with SSE transport rather than stdio. SSE allows a persistent server process to serve multiple Q Developer clients, and lets you centralize API key management rather than distributing `mm_live_...` keys to individual developer machines.
Email infrastructure built for AI agents. Verifiable identity, graduated oversight, and a 38-tool MCP server. Formally verified in Lean 4.