For many teams, the playbook still looks the same:
A new AI idea shows up, and the immediate reaction is to build a new app around it — new UI, new auth, new orchestration, new maintenance overhead, you name it.
That playbook is starting to crack.
Not because AI applications are useless. But because for many internal tools, PoCs, workflow automations, and company-specific AI capabilities, building a full AI product from scratch is no longer the best default move.
If this piece gives you something practical you can take into your own system:
👏 leave 50 claps (yes, you can!) — Medium’s algorithm favors this, increasing visibility to others who then discover the article.
🔔 Follow me on Medium and LinkedIn for more deep dives into agentic systems, LLM architecture, and production-grade AI engineering.
So, guys, in many cases, you can just build an MCP server.
That changes the economics quite a bit.
If the client already exists, and the agent already exists, then your real job is no longer to rebuild chat, prompts, tool wiring, and UX from zero every time. Your job becomes building the killer feature: the workflow, integration, policy layer, or execution capability that the client does not have out of the box.
And that is a much more focused engineering problem.
Claude already supports custom connectors via remote MCP, including custom connector setup with optional OAuth client configuration. OpenAI documents how to build and connect
That is the real shift:
AI apps are increasingly becoming the shell. MCP servers are becoming the product.
Instead of asking:
“How do we build another AI app?”
more teams should be asking:
“How do we expose this capability as a secure MCP server and let an existing well-known AI client do the rest?”
At this point, it is worth clarifying what the MCP capability layer actually consists of.
An MCP server does not expose only tools. It can provide three core primitives — Tools, Resources, and Prompts — each designed for a different interaction model.
The simplest way to understand them is through who controls their use.
Tools give the model additional functionality.
The model decides when a tool is required, chooses the appropriate tool, provides its arguments, and uses the result to continue the task.
Examples include:
Tools answer the question:
What can the model do?
Resources expose addressable data that an MCP client can read, such as documents, project context, reports, schemas, configuration, or database records.
The important distinction is that the host application typically decides what context enters the model request and when.
A user might explicitly attach a document, or the application might automatically load the current project context before calling the model.
Resources answer the question:
What context can the application provide to the model?
Prompts are reusable, parameterized message templates designed primarily for explicit user selection.
A client might expose them through a slash command, button, command palette, or menu option:
A prompt does not execute a workflow by itself. The client retrieves the prepared messages, may combine them with relevant Resources and available Tools, and then sends the assembled request to the model.
Prompts answer the question:
How can the user start a repeatable, well-defined task?
Together, the three primitives create a clean separation:
Tools define what the model can do. Resources define what context the application can provide. Prompts define how the user can start a repeatable task.
For example, when a user selects /analyze-rfi, the host application can retrieve the corresponding Prompt, load the relevant RFI documents as Resources, expose the required search and analysis Tools, and send the complete request to the model.
That is why an MCP server can represent much more than a collection of API wrappers. It can package capabilities, context, and reusable domain-specific ways of working.
A well-built MCP server can be much more than a thin wrapper around APIs.
It can include:
That makes MCP especially attractive for:
You are no longer forced to build the whole product surface just to validate one sharp capability.
This is where FastMCP becomes especially interesting.
FastMCP provides production-friendly patterns for building remote MCP servers, including HTTP deployment, authentication options, and support for providers that do not support Dynamic Client Registration out of the box. Its documentation explicitly covers AWS Cognito as a dedicated provider, and also documents OAuth/OIDC proxy patterns for providers such as GitHub, Google, Azure, AWS, Discord, Facebook, and most enterprise identity systems.
That means you can build an MCP server that is not toy infrastructure. It can authenticate through enterprise identity, expose tightly scoped tools, talk to databases and internal services, enforce policies, and run as a normal cloud backend.
FastMCP is not tied to one deployment model. You can run it as a simple HTTP server, expose it as an ASGI app, integrate it into existing web infrastructure, and even enable stateless HTTP mode for horizontally scaled deployments behind load balancers. In practice, that means you can build MCP servers for almost any architecture, from simple prototypes to production-grade distributed systems.
So your MCP server can live almost anywhere:
This is the part I find most important.
A lot of teams are still spending energy rebuilding the same surface area:
chat interface, prompt handling, tool routing, memory, approvals, auth screens, admin setup, and endless product plumbing.
But if users already live inside a strong AI client, especially one that their company is already paying for, then your leverage is somewhere else.
Your leverage is in building:
That is where the real differentiation lives. The UI is increasingly commoditized. The moat is in thecapability layer.
For internal products and scoped use cases, building MCP servers is often:
Instead of one giant “AI platform” that tries to do everything, you can build focused MCP servers for focused audiences:
That is often cleaner architecturally and better operationally.
Claude Web or ChatGPT is only one possible MCP host. Your own application can act as the host as well: connect to an MCP server, load its tools, and pass them to the agent and model provider you already use.
For example, connecting an MCP server to a custom Python agent can take only a few lines:
Or
For simplicity, this example loads only Tools. A complete MCP host can also discover Resources and Prompts, decide how they should appear in the application, and control how they are incorporated into the model request.
The model can come from Anthropic, OpenAI, Gemini, AWS Bedrock, Azure OpenAI, or another provider supported by your agent runtime. The MCP server itself does not need to change.
And this architecture is not Python-specific. The same MCP server can be consumed from TypeScript, Go, Java, C#, Rust, or another language through an MCP client.
That is the larger idea behind MCP:
Build the capability once, then connect it to existing AI clients, your own agents, different model providers, and different programming stacks.
This does not mean standalone AI applications disappear.
Consumer products, polished vertical experiences, highly opinionated multi-user workflows, and products with unique UX still absolutely justify full application development.
But for a very large class of internal tooling and applied AI work, the old default is no longer the obvious winner.
The winning move is often not:
“Let’s build another AI app.”
It is:
“Let’s build one sharp MCP server that gives an existing AI client a capability it didn’t have before.”
That is usually closer to where the real business value lives.
I do not think AI apps are dead.
I do think the center of gravity is shifting.
For many teams, the most practical path now is:
That is a very different way of thinking about AI product development. And in many cases, it is a better one. If you're curious about how to properly build production-ready MCP servers — welcome to Part #2.
Stop Building AI Apps for Every Idea. Start Building MCP Servers — Part #2
And that’s a wrap! If you’ve read this far, it probably means you found this article useful or insightful. If that’s the case, consider leaving a few claps or sharing it with your team, please. Thanks for reading! 🚀
Stop Building AI Apps for Every Idea. Start Building MCP Servers — Part #1 was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.