A New Imperative for Developer-facing UIs
Last week I watched one of our customers spend 20 minutes setting up a new integration with superglue. They needed to click through our dashboard to set up the workflow, copy some credentials from the other system, switch back to test the connection, then finally into the codebase to wire everything up. The whole time I'm thinking: this is exactly the kind of tedious workflow that should just... not exist anymore.
Don't get me wrong. Superglue's UI is still miles faster than setting up a data integration & pipeline & transformation manually. But that's not the point. The point is that we're still making developers context-switch between their code and our UI.
But with MCP and agents like Cursor, developer tools don't need UIs anymore. Not better UIs, not simpler UIs, but no UIs at all.
Why Every UI is Broken by Design
The whole concept of developer tool UIs is fundamentally flawed. We built these interfaces because APIs felt too raw and CLIs felt too hard to learn. So we created this weird hybrid: Visual interfaces for people who think in code.
The result is universally awkward. You're mentally modeling your application architecture, then you have to translate that into clicking through forms and navigating menus. Take any developer tool you use regularly. I guarantee the workflow looks something like:
Open browser, navigate to dashboard
Click through forms to configure something
Copy-paste values into your codebase
Switch back to verify it worked
Realize you made a typo, repeat steps 1-4
Every single step breaks your flow. You lose context about what you were building. You introduce opportunities for mistakes. And you waste time on interface navigation instead of solving actual problems.
Cursor as the interface for everything
We launched our MCP server for Superglue this week, and the difference is startling. Instead of our engineers opening dashboards, they just describe what they need:
"Fetch all stripe payments of the day and sync them with our accounting system".
The agent handles everything through MCP: reads the documentation, configures the requests for Stripe, sets up the sync with the accounting system, and adds the call to the codebase. All without leaving the editor.
This isn't just "faster." It's a completely different category of interaction. Three things make it fundamentally better than any dashboard could ever be:
The agent knows your codebase. When it generates integration code, it matches your naming conventions, follows your error handling patterns, and fits into your existing architecture. No more copying boilerplate from docs and adapting it.
You never lose context. Your mental model of the system stays intact because you never leave the code. You're not translating between your implementation and some external interface.
You get API power with conversational simplicity. The agent can do anything the API can do, but you express what you want in natural language. It's much simpler than clicking through forms.
Where This Gets Really Interesting
Setup is one thing. Tedious, sure. But manageable. It gets more interesting when you extend this paradigm and let your agent monitor and manage your infra. High load? Add another instance. Suspicious behavior? Ban the account. Increased error rates after a deployment? Roll back automatically.
The agent becomes your development partner, your 24h on-call assistant, and if (!) you can trust it to do the right thing and not screw up monumentally, then this could be a really interesting development.
The tools that thrive in this environment won't be the ones with the prettiest dashboards. They'll be the ones that understand how to work well with agents and their capability-based approach.
Supabase could absolutely nail this. Their feature set maps perfectly to high-level capabilities like "make sure only the authenticated user can access their rows” (=> set up the rules as row level security). But they need to design for agent interaction, not just expose their existing API.
However, if your tool's differentiation is in how you present information rather than what you actually do, you're in trouble.
The Hard Part
Building good MCP servers is legitimately difficult. It's not just wrapping your API in a different protocol. You have to think like an agent - what context do you need? What use cases do I want to serve? What happens when requirements don’t fit in a predefined box?
Most tool vendors are going to screw this up initially, just like most companies botched their first API releases. This is fine, the great thing about an agent interface is that it can be much more dynamic and you don’t need to maintain 31 versions once you release them (looking at you, Salesforce).
My prediction: within 18 months, developer tools without solid MCP servers will feel as outdated as tools without APIs felt in 2015. The productivity difference will be too large to ignore.
Developers will stop evaluating tools based on their dashboards and start evaluating them based on how well they work with agents. The best tools will be the ones you never have to leave your editor to use.
The transition is already happening. Every week we talk to developers who can't go back to clicking through dashboards. Once you've experienced having your infrastructure respond to natural language requests while staying in your codebase, everything else feels primitive.
The age of developer-facing UIs is ending. And honestly, it’s about time.
We're building this future at Superglue. If you want to try our MCP server or discuss how this applies to your toolchain, send me a note.