MCP enables a new way of building applications: the MCP server is the primary interface, and everything else (the web dashboard, the mobile app, the CLI) is an afterthought. Not "AI-enhanced" or "AI-assisted" but genuinely MCP-first, where natural language through an LLM client is how users interact with your application.
To be clear, I'm not talking about the local MCP servers that developers have been wiring up to their code editors. I'm talking about remote MCP servers, hosted over HTTP, that end users connect to from any MCP client.
I tried building an application with this approach and it has some interesting implications for how we think about application development.
The UI Is Lossy Compression
For many applications, the UI is a lossy compression of what the user actually wants to do. When someone opens a CRM and clicks through 4 screens to log that they had coffee with a friend, what they actually wanted to express was:
"Had coffee with Mike yesterday at Blue Bottle, he mentioned he's switching jobs next month."
The UI is just an intermediary, and often a bad one, between human intent and structured data.
On top of that, if you're building with LLM-assisted coding, the UI layer is notably harder to iterate on than business logic. It's a long tail of minor changes: tweaking layouts, fixing edge cases, polishing interactions. Visual nuances and interaction details are hard to communicate in a prompt. Even multimodal models can typically only comprehend a single frame, so things like animations, transitions, and multi-step interactions are difficult to convey.
MCP Removes the Intermediary
MCP (Model Context Protocol) gives us a standardized way to expose application functionality as tools that LLMs can call. When you build an MCP server, you're essentially building an API that's designed to be operated by a language model on behalf of a user. The practical upshot is that you can skip the entire UI layer for your core interaction loop. No React components, no form validation, no CSS battles, no "should this be a modal or a drawer?" debates. The LLM handles the translation from human intent to structured API calls, and it's remarkably good at it.
What you're left building is:
- A data model
- Business logic
- An API surface (your MCP tools)
- Auth
That's the whole application.
Case Study: Mob CRM
To put this idea to the test, I built Mob CRM, a personal CRM that you interact with almost entirely through natural language via MCP.
I've been a longtime user of Monica CRM and always liked the concept of a personal CRM. The problem was data entry. Logging a social interaction meant clicking through multiple forms: find the contact, create an activity, pick a type, fill in notes, associate other contacts. It's death by a thousand clicks, and the friction meant I'd fall behind and eventually stop using it.
Mob takes a different approach. There is no form. You just talk:
"I met with John today, and he introduced me to his friend from work Jane.
We all talked about our shared obsession with slurpees."
Behind the scenes, the LLM breaks this down into the appropriate MCP tool calls: creating contacts, establishing relationships, logging the activity with notes. What would have been 30 clicks in a traditional UI becomes one natural sentence.
The entire server is a Node.js application with SQLite storage. It supports contacts, relationships, activities, life events, reminders, notes, gifts, debts, and tags. It took a fraction of the time to build compared to what a traditional full-stack CRM would have required.
The key realization: the data model and business logic were the same amount of work regardless of whether I built a UI or an MCP server. But by choosing MCP, I got to skip everything else. The LLM is the interface.
Why This Is Compelling for Developers
If you've built CLI tools with AI-assisted coding, you know they're among the easiest things to ship: simple input/output, text-only, easily testable. MCP server development shares these same properties. Your tools accept structured input, return structured output, and the whole thing is testable like any other API.
This means you can go from idea to working product fast, because you're building the domain logic without the interface.
When MCP-First Makes Sense
Not every application should be MCP-first. It works best when:
- The core interaction is data entry or retrieval: CRMs, note-taking, bookkeeping, inventory management, journaling
- Natural language maps well to the domain: if you can describe what you want to do in a sentence, an LLM can probably figure out the right tool calls
- The UI would be mostly forms and tables: if your app is primarily about structured data rather than rich visual interaction, MCP can replace most of it
- Cross-service orchestration adds value: when combining data from multiple MCP servers makes the experience better than any single app could be
It makes less sense for:
- Highly visual applications (design tools, video editors, maps)
- Real-time collaborative experiences
- Applications where spatial interaction is the point (games, drawing)
The Composability Angle
The other thing that makes MCP-first development interesting is composability. When your application is an MCP server, it automatically plays well with every other MCP server. A user can connect your CRM alongside their calendar, email, and task manager, and suddenly cross-application workflows just work:
- "Check if I have any meetings with Sarah next week, and if not, remind me to reach out to her"
- "Log that dinner with the team last night and add it to my expenses"
- "Who haven't I talked to in a while? Draft a quick message to catch up with them"
You get this for free. No integrations to build, no partner APIs to negotiate, no OAuth dances between services. The LLM orchestrates across MCP servers naturally.
Where MCP Falls Short (For Now)
MCP is still young and there are some real gaps if you're building a user-facing application.
Push notifications don't really exist. MCP has a concept of "notifications" but they only work while the connection is alive, which isn't practical on a mobile device. There's no mechanism for GCM/APNs-style push delivery. Mob CRM works around this by having the server provide a URL where users can register for push notifications via the web browser, but it's clunky.
You can't send files through tool parameters. If you need users to upload a file, MCP doesn't have a way to handle that today. Mob CRM hits this with Monica imports and has to fall back to a web page. There's an draft proposal to address this, but it's not landed yet.
These are solvable problems and the protocol is actively evolving, but they're worth knowing about if you're considering MCP-first development today.
Rich UI When You Need It: MCP Apps
On the flip side, the protocol does have an answer for when plain text isn't enough. MCP Apps (sometimes called MCP-UI) allow a server to return HTML/JS/CSS that gets rendered as an iframe within the conversation. This means your MCP server can provide rich interactive controls, charts, or custom input forms right inline with the chat, without the user ever leaving their MCP client.
It's a nice middle ground: you get the simplicity of MCP-first development for the 90% case, and can drop into a full UI when the interaction genuinely needs it.
The Access Problem (And Where It's Heading)
The main friction point right now is that connecting to remote MCP servers isn't easy for regular users. The big players are still gating it:
- Claude: remote MCP only for paid subscribers
- ChatGPT: MCP via developer mode or paid Apps
- Gemini: no MCP support for chat users as of writing
This will change. The protocol is open, the value proposition is clear, and the technical implementation is just HTTP. It's a matter of when, not if.
In the meantime, if you want MCP access on mobile, Joey is an open-source MCP client I built that connects to any remote MCP server and lets you pick from hundreds of LLMs via OpenRouter. It runs on iOS, Android and macOS. It's written in Flutter so it can really support Windows and Linux, I just haven't tested those platforms yet.
Building for Tomorrow
Mob CRM took me a fraction of the time that a traditional full-stack CRM would have, and the result is arguably a better user experience for the core use case of logging interactions. I didn't have to compromise on features, I just didn't have to build the forms. If you're starting a new project and the core interaction is fundamentally about data, consider building the MCP server first. You might find that's all you need.
