MCP Apps: How We'll Build Software in the AI Era

Think about the last application your team built. Count the layers. A frontend framework. A backend language. A database. An ORM to mediate between the backend and the database. An API layer to mediate between the frontend and the backend. Authentication. Authorization. A deployment pipeline to get it all running. Monitoring to know when it breaks. The application itself, the thing that actually does something useful for the business, sits buried under six layers of infrastructure that exist for one reason: humans need interfaces.

AI agents do not need interfaces. They need tools.

The Claim

The traditional application stack was not designed for applications. It was designed for humans who use applications. The frontend exists because humans need visual representations of data. The backend exists because humans need somewhere to park business logic that runs on a server. The database exists because humans need data to persist between sessions. The API layer exists because the frontend and backend are separate programs that need a communication protocol. The entire stack is an elaborate answer to the question: how do humans interact with software?

MCP apps answer a different question: how do AI agents compose capabilities into useful systems?

The answer requires none of the traditional stack. An agent does not need a React frontend to display a dashboard. It reads structured data directly. It does not need an Express backend to process business rules. It follows skills written in plain language. It does not need a REST API to connect the two. It calls MCP tools through persistent connections. The six layers collapse into a composition layer: a manifest that declares which MCP servers provide the tools, which schemas define the data, and which skills encode the logic.

This is the architectural leap that REST Is Dead implied but did not finish. If MCP replaces REST as the application protocol, then MCP servers replace microservices as the building blocks. And if MCP servers are the building blocks, then applications become compositions of servers, not codebases you write from scratch.

Upjack is the first framework built entirely on this premise. An Upjack app is a manifest file, a set of JSON schemas, a collection of markdown skills, and a list of MCP server connections. No backend. No frontend. No database migration. No deployment pipeline for business logic. The agent reads the manifest, connects to the servers, loads the schemas and skills, and the application is running.

NimbleBrain has built dozens of applications this way across client engagements. Lead qualification systems. Invoice processing workflows. Customer onboarding flows. Competitive intelligence dashboards. Each one was built in days, not months. Each one runs in production on Kubernetes. Each one gets better as the underlying AI model improves, without anyone changing a line of code, because there is no code to change.

The application layer is dissolving. What replaces it is composition.

The Evidence

What an MCP app actually looks like

Forget the abstractions for a moment. Here is what sits on disk when you build an MCP app with Upjack.

A manifest file (manifest.json). This is the application’s identity and wiring diagram. It declares the app’s name, version, the entities it works with, the skills it follows, and the MCP servers it connects to. A lead qualification app’s manifest lists four entity schemas, six skills, and three MCP server connections. The entire application topology fits in about forty lines of JSON.

Entity schemas (JSON Schema). These define what the application knows about. A lead schema defines fields: name, company, title, score, stage, notes, source. A campaign schema defines: name, target criteria, status, active outreach sequences. Standard JSON Schema, the same format used across the software industry for API contracts and data validation. No ORM. No migration files. The agent reads the schema and understands the data model.

Skills (Markdown). These are the application’s behavior. A skill called qualify-lead.md contains the criteria for scoring an inbound lead: which signals increase the score, which signals disqualify, what thresholds trigger automatic progression versus human review. A skill called draft-outreach.md contains the rules for composing a personalized email: tone, length, which entity fields to reference, when to follow up. Skills are not prompts. They are persistent, versioned documents that encode domain expertise in natural language.

MCP server connections. The manifest lists the MCP servers the app uses: a CRM server for lead and contact management, an email server for outreach delivery, an enrichment server for company data lookup. Each server exposes tools that the agent discovers at runtime. The CRM server offers search_contacts, create_lead, update_deal_stage. The email server offers send_email, get_thread, create_draft. The agent does not need to know the implementation details of any of these tools. It discovers them, reads their descriptions, and uses them.

Total lines of backend code: zero.

The agent is the runtime. It reads the manifest to know the application’s shape. It loads the schemas to understand the data. It follows the skills to execute the logic. It calls MCP tools to interact with external systems. The application is a composition of existing capabilities, not a new codebase.

A concrete example: lead qualification

A client needed a system to qualify inbound leads, score them against documented criteria, and route qualified leads to the right sales rep with a personalized outreach email. Here is the traditional approach and the MCP app approach, side by side.

Traditional approach. Two to three developers. Three months. A React frontend for the sales team to see lead scores and statuses. A Node.js backend to run the scoring algorithm and manage state. A PostgreSQL database for lead storage. REST API integrations with HubSpot (CRM), Apollo (enrichment), and Gmail (outreach). OAuth flows for each integration. A deployment pipeline with staging and production environments. Ongoing maintenance for API version changes, database migrations, and frontend updates. Conservative cost: $80,000-120,000 in development, plus $4,000-6,000 per month in infrastructure and maintenance.

MCP app approach. One person. Four days.

Day one: documented the qualification criteria as entity schemas and skills. Four schemas (lead, company, campaign, outreach sequence). Six skills (score lead, qualify lead, enrich company, draft outreach, manage campaign, escalate to human). The VP of Sales reviewed every skill and made edits in plain English.

Day two: connected three MCP servers. HubSpot for CRM operations, Apollo for enrichment, Gmail for outreach. Each server was installed from mpak.dev in minutes. Authentication configured. Tools verified.

Day three: ran the first batch of fifty leads through the system. Two skills needed refinement based on the output. The VP of Sales made one of those edits herself. She opened the markdown file, changed a scoring threshold from 70 to 65, and saved. The agent’s behavior changed immediately.

Day four: processed the full backlog. The system qualified 340 leads, generated personalized outreach for the top 85, and flagged 12 edge cases for human review. The sales team started working the qualified pipeline that afternoon.

Same functionality. Three months collapsed to four days. $100,000 collapsed to a fraction of that. And the VP of Sales can modify the business logic without filing a ticket.

How composition scales

The compounding advantage of MCP apps becomes obvious when you need to add a capability.

The client from the lead qualification example later wanted to add LinkedIn enrichment to the scoring process. In the traditional architecture, this means: research the LinkedIn API, build an OAuth integration, write a new microservice to handle enrichment calls, update the scoring algorithm to incorporate LinkedIn data, add new database columns, update the frontend to display the new fields, deploy, test, iterate. Two to four weeks of engineering work.

In the MCP app: install the LinkedIn enrichment MCP server from mpak.dev. Add one line to the manifest. Update the enrich-company.md skill to mention that LinkedIn data is now available for enrichment. Done. The agent discovers the new server’s tools at runtime and incorporates them into its enrichment workflow. Elapsed time: forty-five minutes.

This is the fundamental difference between coded applications and composed applications. In a coded application, every new capability requires new code, new endpoints, new database tables, new UI components, new tests. In a composed application, every new capability is an MCP server connection. The agent handles the orchestration. The composition layer absorbs the complexity.

We have watched this pattern repeat across every engagement. A client starts with three MCP server connections. Within a month, they have seven. Within a quarter, twelve. Each new connection expands what the application can do without changing its architecture. The Recursive Loop in action: the app improves through iteration, not through engineering sprints.

Engagement examples

The lead qualification system is not an outlier. Here is what we have built with MCP apps across recent engagements:

Invoice processing. Entity schemas for invoices, vendors, line items, approval workflows. Skills for extraction, validation, routing, and exception handling. MCP servers for the accounting system, document processing, and email. Built in five days. Replaced a manual process that took one full-time employee twenty hours per week.

Customer onboarding. Entity schemas for accounts, contacts, onboarding milestones, training modules. Skills for welcome sequence orchestration, milestone tracking, escalation on stalled accounts. MCP servers for CRM, email, calendar, and the client’s internal knowledge base. Built in six days. Onboarding completion rate improved from 62% to 91% in the first quarter.

Competitive intelligence. Entity schemas for competitors, product features, pricing tiers, market signals. Skills for monitoring, change detection, briefing generation, and alert routing. MCP servers for web scraping, news aggregation, CRM, and Slack. Built in four days. Replaced a weekly manual process with real-time competitive monitoring.

Each of these is a folder of schemas, skills, and a manifest. Each runs on the NimbleBrain Platform with full production governance. Each was built by one person in under a week.

The Counterarguments

”This is just microservices with a new name.”

It looks similar on the surface. Both involve composing capabilities from separate services. But the similarity ends there.

Microservices require you to write the orchestration layer. You build the service, then you build the code that calls the service, handles failures, manages state between calls, and chains multiple services together. The orchestration logic is often more complex than the services themselves. This is why microservices architectures generate so much accidental complexity, the hard part is not the services, it is the glue.

MCP apps eliminate the glue. The agent IS the orchestration layer. It reads the skills to know what to do, discovers the available tools, and composes them dynamically. You do not write orchestration code. You do not build a service mesh. You do not manage circuit breakers or retry logic or saga patterns. The agent handles all of that through reasoning, not through code.

Microservices are a deployment architecture. MCP apps are a composition architecture. The difference is who writes the wiring: in microservices, an engineer writes it. In MCP apps, the agent figures it out.

”Apps need backends. You can’t just wish them away.”

Correct. Apps need business logic, data persistence, authentication, and integration with external systems. All of those things exist in an MCP app. They just live in different places.

Business logic lives in skills, not in a Node.js codebase. Data persistence is handled by MCP servers connected to databases, the agent reads and writes data through tools, not through an ORM. Authentication is handled at the MCP server level. Each server manages its own auth with the system it wraps. Integration with external systems is the entire point of MCP, persistent, discoverable tool connections replace bespoke API clients.

The backend is not gone. It is decomposed into MCP servers that each handle one concern. The difference is that nobody had to write a custom backend to wire those concerns together. The agent does the wiring. The manifest declares the topology. The backend exists, but it is composed, not coded.

”Composition is fragile. What happens when an MCP server goes down?”

The same thing that happens when a microservice goes down in a traditional architecture: the dependent functionality degrades. The difference is how the system responds.

A coded application with a hard dependency on a crashed microservice usually throws an unhandled exception, returns a 500 error, or hangs. Someone gets paged. An engineer investigates. A fix is deployed.

An MCP app with a governance layer handles this through the agent’s reasoning. The agent detects that a tool is unavailable. It checks its skills for fallback instructions. If the CRM server is down, the agent can log the action for later retry, notify a human, or use cached data, whatever the skill documents specify. The failure mode is encoded in natural language, not in try-catch blocks.

This does not make MCP apps immune to failures. Nothing is. But it shifts failure handling from defensive coding patterns to operational documentation that anyone can read and update.

”This only works for simple CRUD apps.”

We hear this after every demo, usually from an architect who assumes that composition cannot handle real complexity. Then we show them the competitive intelligence system with twelve MCP server connections, twenty-three entity schemas, and forty-one skills spanning four business domains.

Complexity in a composed system scales differently than complexity in a coded system. In code, complexity grows through more code, more files, more functions, more dependencies, more tests. At some point the codebase exceeds what any single person can hold in their head, and you start building teams and processes to manage the complexity of the code itself.

In a composed system, complexity grows through more schemas and more skills. But schemas and skills are human-readable documents. A new team member reads the skills directory and understands what the application does. A domain expert reviews a skill and confirms whether the logic is correct. The complexity is visible and auditable in a way that code never is for non-engineers.

Are there applications too complex for composition? Sure. Real-time trading systems. Game engines. Operating systems. But those are not the applications that enterprises spend most of their budget on. The 80% of enterprise software that is business logic, workflow management, and system integration. That 80% is the composition layer’s domain.

The Conclusion

The application layer is being unbundled. The monolithic stack (frontend, backend, database, API, deployment pipeline) was the right answer for human-driven software. It is the wrong answer for agent-driven systems.

MCP provides the tool protocol. Business-as-Code provides the context layer, schemas for data, skills for logic. What was missing was the composition framework: a way to declare “this is my application” by listing the servers it connects to, the entities it manages, and the skills it follows.

Upjack is that framework. It is open-source. It runs on the NimbleBrain Platform in production. And it has replaced months of traditional development with days of composition work across every engagement we have delivered.

The applications we build this way are faster to create. They are easier to modify, a domain expert edits a skill document instead of filing an engineering ticket. They are easier to extend, adding a capability means adding an MCP server connection, not writing a new microservice. And they improve automatically as the underlying AI model improves, because the agent’s reasoning gets better without anyone changing the schemas or skills.

This is not a theoretical position. It is our production architecture. Every MCP app NimbleBrain deploys runs on Kubernetes with the same governance, observability, and security as any traditional application. The difference is how it got built and how fast it evolves.

If you are still coding backends for applications that qualify leads, process invoices, onboard customers, or route decisions, you are solving a problem that composition already solved. Stop writing the glue. Start composing the tools.

The servers exist on mpak.dev. The framework exists at upjack.dev. The MCP Trust Framework exists for security. The only thing missing is the decision to stop building from scratch and start composing.

We made that decision eighteen months ago. We have not looked back.