Kit shipped their own MCP, so I deprecated mine
Kit shipped their own official MCP, so I deprecated my community one — and why being superseded by the first-party version is a good outcome, not a defeat.
I’d gone in to get more out of my mailing list. I run Kit for the newsletter, and I wanted a better read on who’s actually engaging — so I opened up the little MCP server I’d built for it a while back, planning to give it a security sweep and add a couple of things while I was in there.
What I found instead was that Kit had quietly shipped their own official MCP. So before touching mine, I spent a while testing theirs. It’s more full-featured than mine ever was, and it’s built and maintained by the Kit team — which is really what decided it. It’s the way they want people talking to their API.
Side by side, roughly:
| Capability | Mine (29 tools) | Kit’s official (~70) |
|---|---|---|
| Subscribers — list, create, update | ✓ | ✓ + bulk |
| Tags — create, assign, remove | ✓ | ✓ + bulk |
| Broadcasts — draft, edit, delete | ✓ | ✓ |
| Sequences | read + add subscribers | • author the sequence emails |
| Forms | read + add subscribers | ✓ + bulk |
| Custom fields | list only | create / update / delete |
| Webhooks | ✓ | ✓ |
| Analytics — opens, clicks, growth, link stats | — | ✓ |
| Commerce / purchases | — | ✓ |
| Segments | — | ✓ |
| Snippets & email templates | — | ✓ |
| Auth | your own API key | managed for you |
| Maintained by | me, in my spare time | the Kit team |
That made the call for me, and it wasn’t the one I’d sat down to make. Instead of extending my server, I deprecated it.
I didn’t delete it. It’s still up on GitHub for posterity, and I’m glad it existed and glad it got used. I just marked it deprecated, rewrote the README to point people at the official server, and explained why: this is the supported path now, go and use that.
And I want to be straight about this, because it would be easy to dress it up as some noble open-source gesture and it wasn’t. My server was never going to make money. It was a creative thing — a tool I built because I wanted it, then shared in case anyone else did. Its whole job was to show there was demand, and real use-cases, for talking to Kit this way. It did that for a little while, and then the people who own the API shipped the proper version. That was always going to happen, and it’s a good outcome rather than a defeat. I don’t have the scope to compete with a first-party tool, and I was never trying to.
So if you’ve built a thin wrapper around someone else’s service — an MCP, a CLI, a small integration — I think that’s worth doing. It proves the need and it scratches your own itch. But hold it loosely. When the official version lands, the useful move isn’t to defend your patch of ground; it’s to point your handful of users at the better-supported thing and tell them why. Knowing when your tool’s job is done is its own small skill.