Agent Apps Docs

How Agent Apps compare to traditional MCP servers, and why the Gateway bridges both worlds.

MCP is the tool layer. Agent Apps is the application layer.

The positioning

MCP servers give your agent tools. Agent Apps give your agent tools + interfaces + lifecycle + events + storage + app-to-app communication.

MCP (Model Context Protocol) solved an important problem: it gave AI agents a standard way to call functions. But MCP servers are stateless tool providers — they expose functions, and that's it. No install flow, no authentication, no visual interfaces, no lifecycle management, no persistence, no way for apps to talk to each other.

Agent Apps builds on top of MCP. It uses MCP as its tool-calling protocol (via Gateway MCP), but adds everything else an application needs:

Interfaces — visual UI: cards, tables, charts, forms, images
Lifecycle — install, configure, authenticate, start, stop, health checks
Events — real-time notifications from the app to the agent
Storage — platform-provided persistence
App-to-app communication — one app can invoke another's capabilities
Runtime management — instance spawning, routing, scaling, idle teardown
Permissions — granular grants approved by the user

Think of it this way: an MCP server is a function library. An Agent App is a full application.

Feature comparison

Feature	Plain MCP Server	Agent App via Gateway
Tools	✅	✅
Interfaces (visual UI)	❌	✅
Lifecycle (install, start, stop)	❌	✅
Events (real-time notifications)	❌	✅
Storage (persistence)	❌	✅
App-to-app communication	❌	✅
Permissions	Basic	Advanced (granular grants)
Runtime management	❌	✅
Authentication (OAuth, API keys)	Manual	Built-in
Multi-tenancy	❌	✅
Scaling (cluster, on-demand)	❌	✅
Health monitoring	❌	✅
Works with MCP clients	✅	✅ (via Gateway MCP)

How they work together

Agent Apps doesn't replace MCP — it uses it. The Gateway MCP bridge translates between the Agent Apps protocol and MCP, so Agent Apps work in any MCP-compatible client:

MCP Client (Claude Code, Cursor, ...)
  │
  │  MCP protocol (stdio)
  │
  ▼
Gateway MCP (protocol bridge)
  │
  │  Agent Apps protocol (HTTP)
  │
  ▼
Station
  │
  │  lifecycle, routing, secrets, auth
  │
  ▼
Agent Apps (Gmail, Slack, GitHub, Playwright, ...)

Your AI client sees MCP tools. It doesn't need to know about Agent Apps at all. But behind those tools, there's a full application runtime handling authentication, persistence, events, and scaling.

When to use what

Use a plain MCP server when:

You need a single, stateless tool (e.g. "search this API")
You don't need authentication, persistence, or UI
You're building a quick prototype or internal tool
You want zero infrastructure

Use Agent Apps when:

You're building a real application with multiple tools
You need OAuth or API key authentication
You want visual interfaces (cards, tables, charts) rendered in the client
You need persistent storage
You want apps to communicate with each other
You need multi-tenancy or scaling
You want a managed lifecycle (install, configure, start, stop, health checks)
You want your tools to work across all MCP clients without rewriting

Do I need to rewrite my existing MCP servers?

No. Existing MCP servers continue to work as-is in any MCP client. You can:

Keep using them — they work fine for simple, stateless tools
Wrap them — expose an MCP server as an Agent App to get lifecycle, auth, and storage
Rewrite them — use the @agentapps/sdk to build a native Agent App with interfaces, events, and app-to-app communication

The Agent Apps SDK is designed to be as simple as writing an MCP server, but with the full application layer included.

Try it with your MCP client

If you already use Claude Code, Cursor, Windsurf, VS Code, or Zed, you can try Agent Apps right now:

→ Quickstart — install your first Agent App in 60 seconds

Agent Apps vs MCP servers