>That distinction matters to us. Our long-term values include “Your data belongs to you” and “We are good stewards of your data”. The pattern we try to follow is: rather than continuously reworking our UI to follow every new trend, we give you the interfaces to use your data however it suits you. MCP continues that pattern. It’s there if you want it, and nothing changes if you don’t.
This is really refreshing and makes me feel like I made the right decision in moving off Gmail after 20 years to Fastmail last year
Kudos to the Fastmail team for keeping it classy. The MCP implementation may be a great way to leverage some local models to help clean up years of things I no longer need but don't want to waste the time on.
The three-tier scope split (read / write / send) is also a nice middle ground between god-mode tokens and OAuth granularity nobody actually configures.
Open question this raises: does every vendor need to hand-roll an MCP server, or does the ecosystem settle on REST→MCP auto-wrapping over OpenAPI specs? We've been exploring the latter (open source: github.com/ChronoAIProject/NyxID). Fastmail-specific nuances like JMAP pushing vs polling probably justify hand-rolling for now, but the pattern doesn't generalize.
> The OAuth consent screen will give you a choice of three levels of access: read-only (see emails, contacts, calendars), write (update emails, save drafts, edit contacts and events), and send (send emails).
using imap idle in our multiple helpdesks (i use for many different app supports)