alfred_ MCP for IT and security

Reviewing alfred_ before you allow it.

alfred_ connects an assistant to a person's own email, calendar and to-dos. This page is the detail a reviewer asks for: how people authenticate, what each permission grants, what the connector cannot do whatever is granted, what we record, and how to put it in front of a team.

How people sign in

Every person authorises alfred_ individually. There is no shared key, and no credential for an administrator to hold, distribute or rotate.

The flow

  1. The assistant requests the server URL and receives an OAuth challenge naming this server as the protected resource (RFC 9728). It needs no configuration to discover this.
  2. The assistant registers itself dynamically (RFC 7591), or identifies itself by a client metadata document. Neither requires anything from us in advance, which is why alfred_ works in a client we have never heard of.
  3. The person's browser opens on get-alfred.ai. They sign in as themselves and choose which permissions to grant, one by one. Authorisation code with PKCE; no password reaches the assistant.
  4. The assistant receives an access token that expires after one hour, and a refresh token it uses quietly. Tokens are bound to that one person and that one client.

What we do not have yet

Stated plainly, because a rollout is the wrong place to discover it.

Not available today

  • No SAML or OIDC federation to a company identity provider. People sign in to alfred_ with their own alfred_ account, not through Okta, Entra ID or Google Workspace SSO.
  • No SCIM. Accounts are not provisioned or de-provisioned from a directory.
  • No administrator console over other people's connections. You cannot centrally see, approve or revoke a colleague's connector from within alfred_; each person manages their own.
  • No org-wide permission policy inside alfred_. Which permissions a person grants is their choice at the consent screen. The controls you do have are on the assistant's side, described below.

If any of these would decide it for you, write to connor@get-alfred.ai and say which. That is how they get prioritised.

Every permission, and what it grants

A client that asks for nothing receives the three read permissions below and no others, so a connection can never quietly acquire write access it did not request.

work:read

Search your work

Granted by default

Find email threads across your connected accounts.

email:read

Read your email

Granted by default

Open a thread in full once it has been found.

calendar:read

See your calendar

Granted by default

Read events, calendars and free time.

tasks:read

See your to-dos

Asked separately

Read your task lists.

contacts:read

See your contacts

Asked separately

Look up names, addresses and companies alfred_ already knows.

email:draft

Write drafts for you

Asked separately, writes data

Save emails to your Drafts folder. Nothing is ever sent — you send it yourself.

tasks:write

Create and change your to-dos

Asked separately, writes data

Add tasks and reminders, and update existing ones. Your own lists only, never a team's.

calendar:write

Create and change events

Asked separately, writes data

Book, move and update events — including sending invitations to the people on them.

rules:write

Manage your email rules

Asked separately, writes data

See, create, edit and disable the standing rules that sort your mail. Rules can be disabled but never deleted from here.

email:organize

Tidy your inbox

Asked separately, writes data

Archive, move, label and mark mail read — one at a time or in confirmed sweeps. Never deletes anything, never sends anything.

email:send

Send email as you

Asked separately, writes data

Send new messages and replies from your connected accounts. These go out for real.

memory:read

See what alfred_ remembers about you

Asked separately

Read facts alfred_ has stored — preferences, stable facts, relationships, project context.

memory:write

Let alfred_ remember new facts

Asked separately, writes data

Save and update facts you tell it here, so alfred_ recalls them in chat and SMS too.

files:read

Find files in your cloud storage

Asked separately

Search and read files in the Google Drive, OneDrive and SharePoint accounts you have connected — and attach them to email you send.

The full tool surface

Every tool the server exposes, grouped. A permission is necessary but not sufficient: the confirmation rules below apply on top of it.

search_work, list_inbox, get_thread, get_email_body, list_folders, read_attachment

Find and read email

Searches every account you have connected to alfred_ (Gmail, Outlook, Microsoft 365, IMAP) in one query, then opens a thread in full: every message, who said what, and whether you already replied. Reads a PDF or an image attachment as text. Never fetches an attachment you did not point at.

create_draft, update_draft, send_email, reply_to_email, forward_email

Write, reply and send

Saves a message into your real Drafts folder for you to send yourself, or sends and replies from the account you choose. Anything that leaves your mailbox shows you the message first and waits for a yes, and that check runs inside alfred_ rather than in the assistant.

list_pending_drafts, get_pending_draft, update_pending_draft, dismiss_pending_draft

Pick up drafts alfred_ wrote

alfred_ drafts replies on its own in the background. These read that queue, revise a draft's wording or subject, and clear one you do not want. Editing a draft does not send it and is not approval to send it — it stays in the queue for you to decide. They never send one.

organize_email, bulk_organize_emails

Tidy the inbox

Archives, labels, moves and marks read. A single message acts on the one you pointed at. A bulk sweep always counts the matches, shows you the number, and waits for your yes before touching anything.

list_email_rules, create_email_rule, update_email_rule

Set up inbox rules

Creates and edits the standing rules alfred_ applies to new mail, like archiving a newsletter or flagging a client. You see what a rule would and would not have caught before it is saved.

get_schedule, list_calendars, search_events, find_free_time, check_free

Read the calendar

Reads events from your connected calendars for a day or a range, in your timezone, with attendees and locations. Finds genuinely open slots, so a proposed time is one you are actually free for.

create_event, update_event

Book and move meetings

Creates and updates events on the calendar you choose, adds a Google Meet or Teams link, and invites people. You see exactly what will be sent, and to whom, before any invitation goes out.

list_todos, search_todos, create_todo, update_todo, bulk_update_todos

Track to-dos

Reads your task lists and adds tasks, due dates and reminders, using the same timing and quiet-hours rules as the rest of alfred_. Changes several to-dos at once when you ask it to — completing, rescheduling or re-prioritising a whole batch in one step, and telling you plainly if any of them could not be changed. It cannot delete a to-do; that stays in the app. Your own lists only, never a team workspace.

lookup_contact, list_contacts

Look up a person

Resolves a name to the address you actually use for them, with the company and history alfred_ already holds. This is what stops a reply going to last year's address.

cloud_files

Read a file from cloud storage

Searches and reads Google Drive, OneDrive and SharePoint, extracting text only and never raw file bytes. A separate permission from email: connecting alfred_ for your inbox does not grant this.

search_facts, remember_fact, update_fact

Use and update what alfred_ knows

Reads the working notes alfred_ keeps about your work, and records a new one when you tell it something worth keeping. Yours alone, and visible to you in alfred_.

list_accounts, get_account_setup_link

See and fix your accounts

Shows which email and calendar accounts you have connected (up to 6) and whether each is healthy, and hands you a one-tap link to connect another or reconnect one that lost access. It cannot connect or remove an account itself; that stays a signed-in click in alfred_.

What it cannot do, whatever is granted

  • Nothing is sent, and no invitation goes out, until you have seen it and said yes.
  • Cannot delete anything: not an email, not an event, not a to-do.
  • Tidying (archive, move, mark read) acts on messages you pointed at; a bulk sweep always shows you a count first and waits for your yes.
  • Cannot disconnect an account. Connecting and removing accounts stays a signed-in click in alfred_ itself.
  • Cannot touch a team workspace. Your own lists and accounts only.
  • You choose what to allow when you sign in. Reading is the default; writing, and sending, are separate permissions you grant on purpose.
  • Never sees your provider passwords or OAuth tokens. Every call runs through alfred_, as you.
  • Only the accounts you connected to alfred_. Nothing else on your machine.

These are enforced in alfred_, not in the assistant. An assistant cannot argue its way past them, and neither can a message in someone's inbox that is trying to.

What we record, and what we do not

Recorded for every call

  1. Which tool ran, for which connection, at what time, how long it took, and whether it succeeded.
  2. The failure code when one fails, so we can fix it.

Not recorded

  1. The search terms, the message bodies, the attachments, the calendar contents.
  2. Provider passwords and OAuth tokens for the mailbox itself. alfred_ holds its own grant to the mail provider; the assistant never sees it.

Content passes through to answer the request and is not retained for the connector. Full detail, including sub-processors and retention, is in Security and the Privacy policy.

Rolling it out to a team

The server URL is the only thing shared. Each person still authorises as themselves, so nothing in a committed file grants access to anything.

Claude Code, per project

  1. Commit this as .mcp.json at the repository root. Everyone who opens the project is offered alfred_ and signs in individually.
{
  "mcpServers": {
    "alfred": {
      "type": "http",
      "url": "https://get-alfred.ai/api/mcp"
    }
  }
}

Claude Code, per person

  1. Run once. It registers alfred_ for that user across every project.
claude mcp add --transport http alfred https://get-alfred.ai/api/mcp

Everywhere else

  1. Give people the server URL and point them at the guide for their assistant on the connector page. There is nothing else to configure.
  2. If your organisation restricts which connectors are permitted, that control lives in the assistant's own administration, not in alfred_. Allow the server URL above.

Ending access

By the person

  1. In alfred_, Settings, then Privacy and Security, revoke the entry under Connect AI assistants. Access stops immediately, not at the end of the token hour.
  2. Removing the connector on the assistant's side stops it being offered there as well.

When someone leaves

  1. Revoking alfred_'s access to the mailbox at the mail provider (Google Workspace or Microsoft 365 admin) ends what the connector can reach, because every call runs through alfred_'s own grant to that mailbox.
  2. To close the alfred_ account itself, write to connor@get-alfred.ai. There is no self-serve admin action for someone else's account today; see the section above.