alfred_

Mint a one-tap link to alfred_'s account setup page — for connecting a NEW email/calendar account (users can have up to 6), reconnecting one whose access expired, or granting alfred_ broader permissions. Call this whenever you would otherwise tell the user to 'go to Settings': send the returned url exactly as given, never invent an alfred_ URL or describe steps instead. For reconnect and change_permissions, email must be one of the user's own connected addresses, copied exactly from list_accounts. The link only works for the person you are talking to, signed in as themselves — you cannot make one for anyone else, so never offer to. To REMOVE an account, mint a connect link and tell the user to use Disconnect on the settings page it opens — disconnecting is deliberately not possible from here. PERMISSIONS: this connection currently CANNOT write and send email by voice. Tools for those are not available to you at all — they are not hidden behind an error, they are absent, so do not claim to have tried them. If the user asks for one, say plainly which permission is missing, and tell them the fix is to disconnect and reconnect alfred_ from this app's own connector/MCP settings — the consent screen will then offer the missing permissions as checkboxes. Do NOT offer a change_permissions link for this: that link manages the user's connected email/calendar accounts, not this connection's permissions.

get_account_setup_link

List the user's calendar events across every calendar they have connected to alfred_ for a date range (default: now to +7 days), in the user's own timezone. Each event carries a human-readable `when`, attendees with response status, and self_response — self_response:'needs_action' is an invite the user has not answered; 'declined' is not a commitment. Use for 'what's on my calendar', 'am I free Thursday', 'when is my next meeting', 'any invites I haven't replied to'.

get_schedule

List the replies alfred_'s background worker drafted on the user's behalf and parked for review — 'what did alfred_ draft overnight?'. Each row has a draft id, recipient, subject and a one-line gist. Read one in full with get_pending_draft; clear one with dismiss_pending_draft. SENDING from this queue is not possible on this surface — to send, tell the user to review it in alfred_.

list_pending_drafts

List every calendar the user has connected to alfred_, grouped by account, with which one is primary. Call this BEFORE creating an event when the user has more than one connected account, or when they name a calendar ('put it on my work calendar'), so you can pass the right calendar_id instead of guessing. Also the honest answer to 'which calendars do you see?'.

list_calendars

List every email and calendar account the user has connected to alfred_, with each account's address, provider, what it can do, and health (healthy/degraded/broken — broken names the cause, e.g. AUTH_REVOKED). The result's slots show how many of the 6 available account slots are used — users can connect up to 6 accounts (Gmail, Outlook, IMAP). Call this whenever the user names an account, has more than one and the target is ambiguous, asks 'which accounts do you see?' or 'why can't you read my Outlook?', and BEFORE passing from_account on any other tool. If an account shows broken or degraded, offer get_account_setup_link to fix it.

list_accounts

List the user's saved contacts — name, email, phone, company, note. Use for 'who are my contacts', or to browse rather than look up one person by name (that's lookup_contact).

list_contacts

List the standing rules that sort the user's mail (archive/label/move/notify/protect/no_draft and more), with each rule's id, match and enabled state. ALWAYS call this before creating a rule (avoid duplicates) or before any archive sweep (protected senders). There is no name/action filter — the server only supports enabled_only; filter the returned list client-side.

list_email_rules

List messages in a mailbox folder — the 'what's in my inbox / what needs me' view, newest first, across every connected account. Use for triage ('what came in today?', 'any unread from clients?'); use search_work when hunting for something specific. Filters: folder (inbox/sent/drafts/trash/spam/all), is_unread, from/to/subject, has_attachment, since/until. Pass the result's next_page_token back VERBATIM as page_token to continue — never an id. A row with is_draft:true is an UNSENT draft.

list_inbox

List custom folders/labels across the user's connected mailboxes, so you can name a real move/label target instead of guessing. Off by default: system buckets (Inbox, Sent, Trash, Spam) — pass include_system:true for a full audit.

list_folders

List the user's tasks and reminders, filterable by status, list, priority, tag or due date. A row with suggested:true is an AI PROPOSAL derived from an email, not a task the user created — never report one as an existing to-do. A row with reminder_fired:true has already been sent; say it went out, not that it is coming.

list_todos

Find a person alfred_ already knows — name, email address(es), company — from the user's mail history and saved contacts. Use before drafting/sending when you have a name but not an address.

lookup_contact

Archive, move, mark read/unread, or restore-from-Trash across many messages — specific ones via message_refs (exact message_ids you just showed the user), or an open-ended sweep via filter (from/query/is_unread/older_than_days). There is NO delete on this surface. COUNT-THEN-CONFIRM: the first call (no confirmed) returns a per-account COUNT PREVIEW and a preview_id — nothing changes. Show the human the counts, get their explicit yes, then call again with confirmed:true AND that exact preview_id (the server replays the approved sweep; never rewrite the filter on confirm). If the preview says requires_scale_confirmation, state the exact count, get a yes to that magnitude, and add scale_acknowledged:true. If count_incomplete:true, counting timed out on an account — that is NOT zero matches; say so. The preview count is an estimate of what will be queued, never a completed result — report progress only from a fresh re-count.

bulk_organize_emails

Tidy a single message: archive, move to a folder, apply/remove a label, mark read/unread, star/unstar. message_ref is a message_id from list_inbox or search_work. This tool CANNOT delete — there is no delete action on this surface. For many messages at once use bulk_organize_emails instead of looping this. CONFIRMATION: this may return `requires_confirmation: true` with a preview of what WILL happen. That is not an error and nothing has happened yet — do NOT retry it and do NOT report a failure. Show the preview to the user, and only once they agree, call again with the identical arguments plus `confirmed: true`.

organize_email

Read the CONTENT of a file attached to an email — text files decode directly; PDFs and images are transcribed (extracted:true, minor OCR errors possible); xlsx/docx extract in-process. Pass message_ref plus attachment_id or attachment_filename from get_thread's attachments list. unsupported:true means the file could not be read — report that honestly and NEVER fabricate contents from the filename. Output caps at 50KB (truncated:true means there is more).

read_attachment

Return every message in an email thread with full body text, per-message to/cc, and is_self_send / is_draft, so you can see what was actually said, who is on the thread now vs earlier, and which messages came from the user. Use before summarising a conversation, answering 'what did they say back' or 'who else is on this', or checking whether the user already replied (an outbound message with is_draft:true was NEVER sent). thread_ref is a thread or message id from search_work — never a subject line and never a calendar event id.

get_thread

Fetch a message by ref with its full body, to/cc/bcc, and attachment metadata — without pulling the rest of the thread. When you need more than one body, pass them together in message_refs (up to 5) in ONE call rather than calling this once per message; results[] comes back in the same order with a per-row ok, so one bad id does not fail the others. Prefer get_thread when the human is asking about a conversation ('what did they say back', 'who's on this'); use this for already-identified messages.

get_email_body

Read the full body of one pending draft from list_pending_drafts, so the human can judge it before deciding. Never present a pending draft as sent — it has not gone anywhere.

get_pending_draft

Persist a fact the user has explicitly told you, so alfred_ recalls it in chat and SMS too. Use scope='identity' for who they are, 'preference' for how they like things done, 'fact' for stable world facts (kids' names, anniversaries), 'relation' for who they know, 'context' for current-project state. Key is a stable identifier like 'preferred_name' or 'project.acme.status'. A concept alfred_ tracks as a structured setting (timezone, name, location, default account, ...) is refused here with the right tool to use instead — that is expected, not an error.

remember_fact

Send a reply in ONE specific conversation, threaded to the message being answered, with the subject forced to 'Re: <original>'. Use ONLY when you can identify the exact received message (a message_id from search_work or get_thread) — if you cannot pin it, use send_email instead. Do not pick a message merely because it is recent. Prefer reply_all:true on a multi-party thread when the reply is coordination the others are part of. To park the reply in Drafts instead, use create_draft with reply_to_message_ref. This sends for real once confirmed. CONFIRMATION: this may return `requires_confirmation: true` with a preview of what WILL happen. That is not an error and nothing has happened yet — do NOT retry it and do NOT report a failure. Show the preview to the user, and only once they agree, call again with the identical arguments plus `confirmed: true`.

reply_to_email

Revise an AI-suggested draft from list_pending_drafts in place, keeping it in the review queue. Send ONLY what you are changing — body, subject, or both — anything you omit keeps its current value, so "tighten the second paragraph" is update_pending_draft({draft_ref, body}). You do NOT need to replay the rest. The edited text is what will be sent if the user later approves it. This does NOT send the draft and is NOT approval to send it — it stays in the queue for the human to decide.

update_pending_draft

Replace the contents of an existing draft, in place, keeping the same draft id (no duplicate). IMPORTANT: this REPLACES rather than patches — send the COMPLETE email (to, subject, body), not just the part that changed, or you will wipe the fields you left out. Read the draft first if you do not have it. Recipients are objects: [{ email, name? }]. Still never sends.

update_draft

Save an email into the user's real Gmail/Outlook DRAFTS folder, unsent, for them to review and send themselves. Use whenever the ask names their drafts, or wants to see it before anything goes out ('draft a reply', 'set it up so I can review it', 'hold it for me'). For a reply, pass reply_to_message_ref (a message_id from search_work or get_thread) and the draft stays threaded. Recipients are objects: [{ email, name? }]. This never sends. If the user wants the message to actually go out, that is send_email or reply_to_email.

create_draft

Search calendar events by title, attendee, or location — 'do I have a Team Touchpoint today', 'find my meeting with Pat'. Without account_id, fans out across every connected calendar. For a windowed listing ('what's on my calendar Friday') use get_schedule instead. If the query matches nothing, the result may carry window_events — same-window candidates ('no Team Touchpoint, but you have Team Chat at 5pm — that it?'); relay those rather than saying the user has nothing.

search_events

Search, browse and read the user's connected Google Drive, OneDrive and SharePoint — across every connected storage account at once. Use action:'search' when the user refers to a document that would live in their storage ('the Acme contract', 'my Q3 deck'); it matches file NAMES and file CONTENTS and returns a `ref` for each hit. Use action:'browse' with a folder's ref to see what is inside it, or with no parent_ref for the top level of every account. Use action:'read' with a ref to extract a file's text. Use action:'sites' to list SharePoint sites. The `ref` is also what attaches a file: pass it as an attachment with source:'storage' on send_email, reply_to_email or forward_email — that is how you send someone a file from the user's Drive. Never invent a ref, and never claim SharePoint was searched when the result lists the account under accounts_onedrive_only.

cloud_files

Search tasks/reminders by keyword when list_todos' filters aren't enough — 'do I have a to-do about the passport renewal'. Personal tasks only. If nothing matches, the result may carry window_tasks — same-status candidates ('no exact match, but you have these open — one of these?'); offer those rather than saying there are no tasks about it.

search_todos

Search the user's work across every email account they have connected to alfred_ (Gmail, Outlook, IMAP) in parallel. Use this for 'what did X say about Y', 'find the thread about Z', 'did anyone email me about …', or to locate a thread before reading it. Matching is LITERAL keyword matching, not semantic: every additional term NARROWS the result, so a long descriptive query returns FEWER hits than a short one. Search the fewest distinctive words (a name, an invoice number) and pass up to two alternate phrasings in alt_queries — they run in the same call and the results merge, deduplicated. Paraphrases and synonyms do not match, so a single query never establishes absence; for structured sweeps ('everything from this sender', 'mail since Monday') use list_inbox's from/since/until filters instead of guessing keywords. Returns messages with sender, subject, snippet, folder and is_draft. A row with is_draft:true is an UNSENT draft — never describe it as sent or 'already replied'. To read a full conversation, call get_thread with the returned thread_ref.

search_work

Read facts alfred_ has stored about the user — identity, preferences, stable world facts, relationships, current-project context. Pass query to search fact CONTENT when you don't know the exact key ('what do they take in coffee', 'who owns billing'). Pass scope to list a category, or scope+key for one fact. Pass nothing to list everything (use sparingly). Before telling the user alfred_ doesn't know something about them, search here first.

search_facts

Send a NEW email — a fresh thread with a subject you set. Use for 'email X', 'reach out to Y', 'tell Z that …'. To continue a conversation the user received, use reply_to_email instead; to park something for review, use create_draft. Recipients are objects: [{ email, name? }]. alfred_ handles the signature and threading. This sends for real once confirmed. CONFIRMATION: this may return `requires_confirmation: true` with a preview of what WILL happen. That is not an error and nothing has happened yet — do NOT retry it and do NOT report a failure. Show the preview to the user, and only once they agree, call again with the identical arguments plus `confirmed: true`.

send_email

Update an existing fact. Same shape as remember_fact — the prior version is preserved, not deleted.

update_fact

Update a task by task_ref (its id, or its name) — change fields, complete it with status:'done', adjust its reminder, or change how it repeats. A repeating to-do is ONE row that reopens itself at its next occurrence, so completing it creates nothing — never make a follow-up copy. To stop it repeating, send recurrence_enabled:false; that keeps the to-do and only drops the repeat. A 'suggested:<…>' ref DISMISSES that AI proposal rather than completing a task; say you dismissed a suggestion. When you change a reminder, confirm the new time from the result's remind_at_local. Also manages the task's subtasks — add one, or tick one off by its id or its exact text. Ticking off a STEP is update_todo on the PARENT with complete_subtask; it is never status:'done', which would close the whole task. This tool cannot DELETE a to-do. If the user wants one gone rather than done, say that deleting is only available in the alfred_ app, and offer status:'done' instead — do not keep trying. CONFIRMATION: this may return `requires_confirmation: true` with a preview of what WILL happen. That is not an error and nothing has happened yet — do NOT retry it and do NOT report a failure. Show the preview to the user, and only once they agree, call again with the identical arguments plus `confirmed: true`.

update_todo