> To be clear about what this isn’t: we have not integrated AI into Fastmail. There’s no chatbot bolted onto the inbox, and your mail isn’t being piped through a model in the background. The MCP server is simply another API endpoint for you to use, if you want to, with the AI client of your choice.
>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
I've been using Fastmail since late 2014 and have been happy with the lack of "features" they've chased. I still have a grandfathered Google Workspace account as well as a handful of Gmail addresses and the difference, at this point, is stark. All of the "convenience" features in Gmail amongst the dark patterns of user data collection is pretty atrocious.
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 restraint of shipping this as "an API endpoint you may or may not point an AI client at" is the right call. The alternative — every SaaS hand-rolls a bespoke MCP surface with its own auth model — scales terribly for anyone connecting five or ten tools to one agent.
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.
This is great, I built a manual integration based on JMAP and CalDav cli tooling, but this is neat. Especially:
> 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).
As someone who's immensely skeptical about AI, this is probably the best usecase I've seen for it after code reviews. I wish Thunderbird would get AI integration.
> To be clear about what this isn’t: we have not integrated AI into Fastmail. There’s no chatbot bolted onto the inbox, and your mail isn’t being piped through a model in the background. The MCP server is simply another API endpoint for you to use, if you want to, with the AI client of your choice.
>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
I've been using Fastmail since late 2014 and have been happy with the lack of "features" they've chased. I still have a grandfathered Google Workspace account as well as a handful of Gmail addresses and the difference, at this point, is stark. All of the "convenience" features in Gmail amongst the dark patterns of user data collection is pretty atrocious.
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 restraint of shipping this as "an API endpoint you may or may not point an AI client at" is the right call. The alternative — every SaaS hand-rolls a bespoke MCP surface with its own auth model — scales terribly for anyone connecting five or ten tools to one agent.
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.
This is great, I built a manual integration based on JMAP and CalDav cli tooling, but this is neat. Especially:
> 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).
As a note for those that use Fastmail, Fastmail stores all your data in the US, if that is important to you.
Does that mean they are in breach of Privacy Shield if I'm in the EU.
As someone who's immensely skeptical about AI, this is probably the best usecase I've seen for it after code reviews. I wish Thunderbird would get AI integration.
Yeah I think that was one of the vapourware features that Apple showed in an advert a couple of years ago, right?
I don't know, I'm not an Apple person. But I do hate (and suck at) writing emails, so anything that makes it easier is welcome for me.
I use Apple's AI Mail integration every day. The inbox summary is genuinely useful IMO.
i just use zoho, their email is $1 a month or something. Haven't felt need of jmap yet.
using imap idle in our multiple helpdesks (i use for many different app supports)
this is good, thanks!
[dead]