I would really appreciate opening the beta a bit more widely, as there is strong interest from many makers in this community in pushing the MCP to discover new use cases, which, in the end, will benefit the team from a broader set of eyes.
3 Likes
I would like to have access to the MCP too!
1 Like
I don’t see any upside to slow-rolling the MCP beta. The data and examples published show it’s stable, safe, and very few bugs.
1 Like
It drives me f…ing crazy seeing how an organisation like “Superhuman” hasn’t yet pulled its pants up to show greater momentum in innovation (if we can even call it that).
Like, I cannot understand why things are rolling sooo slow. Other products have had an MCP for way, way longer, while we have the MCP in beta, which will be 4 months old, and the product will still be bare-bones.
It’s all about the culture of keeping things “closed“ and working “on something big“ that never materializes.
4 Likes
I would love to try the MCP! How do I get involved?
Hey Elise! Let me check with the team today and I’ll follow up!
I really appreciate the passion in this thread. The fact that people care enough to be frustrated tells us we’re building something that matters.
It’s fair to want broader access. It’s fair to want momentum. And it’s fair to compare timelines. These are reasonable instincts from people who are invested. Let me share a bit of context on how we’re thinking about this:
There’s a real difference between a private beta and a public beta, even when something looks stable on the surface. A private beta isn’t just about bug counts. It’s about:
- Stress-testing real use cases across different workflows
- Understanding edge cases that don’t show up in our internal testing
- Watching how things perform and scale in controlled waves
- Learning how people actually push the boundaries
MCP touches the foundational layers of how Coda works. When something operates that close to the core, we hold ourselves to a higher bar. Not because we want to gate-keep, but because we’re committed to getting this right. Once it’s broadly available, we can’t easily walk it back.
I hear the frustration around the perceived “slow roll.” From the outside, caution can look like stagnation. But we’re moving deliberately, not slowly. We’re making sure that when access expands, it’s built to last, not something we’ll need to pull back or fix later.
On the “why not just open it up?” question, even stable systems behave differently at scale. Expanding in waves gives us real signal, not just noise. It lets us learn and adapt before we hit a point where changes would be disruptive.
Broader access is coming. The goal isn’t to keep things closed, it’s to expand in a way that builds trust and delivers on what we’re promising.
The level of experimentation and edge-case pushing that some of you want to do? That’s exactly what we’re building for. We’re widening the circle, just doing it in a way that sets everyone up to succeed.
Keep the feedback coming. It genuinely influences how we think about access, pacing, and communication.
6 Likes
I’d like access too please.
1 Like
Great news! MCP will definetely help reducing config efforts for me and my clients. Super interested in being part of the beta.
1 Like
Understood. I have counted fewer than eight Makers in the community who are waiting for access. That was my context for “open it up”.
This is the only thing of interest to me in this whole thing. All I want is a faster, better way to talk to my Coda docs.
! rant:
The current API is not fit for purpose. Packs were a mistake, slow and cumbersome, intended to foster a third party marketplace that never took off.
I want to write custom formulas that run in my browser. I want in-browser row change events that I can hook into with action formulas. I want to declare my Sync table’s schema right there in my doc and have it call my API directly from my browser instead of waiting for the next doc snapshot and round tripping to your servers on the other side of the world.
Who this “I” is becomes increasingly irrelevant. It could be me, it could be my agent. Both options should be open, documented, and run locally.
Coda’s decision to gate-keep the “real” browser-side API in the past years was a mistake (you know, the one that @Paul_Danyliuk uncovered and was politely told to get lost). Coda’s decision today to gate-keep this new “client-side execution framework” to only its MCP is another mistake.
In the end, all of these SaaS apps will need to adapt or die: Your app will be just an API. How our personal agents choose to talk to it is secondary. Coda chose MCP, but the rest of the community has long moved on to CLI based tools, and in a few months everyone will be on Claws or who knows what. All that will matter in the long run is a good, open, fast, unrestricted API.
! rant over
6 Likes
They tend to schedule intakes for new beta cohorts in waves. I believe that by today, all those interested in participating in the beta will have access.
2 Likes
Just got access–thank you so much! Excited to play and build.
1 Like
Hello,
I would quite like to try it out to make some documentation please.
I hesitated but seems like the MCP access will make a nice difference.
Thanks for the work and have a nice day 
1 Like
@Ruggy-Joesten can you please provide me with beta access to Coda MCP?
1 Like
Hi hi! Just sent you a DM.
1 Like
Ah, it’s been three years… 
1 Like