If you're building tools for AI agents, you've likely come across two approaches: agent apps (installable local capability services) and MCP servers (remote tools exposed via the Model Context Protocol). They look similar on the surface — both let agents do things beyond text completion — but they solve fundamentally different problems. Understanding the structural difference matters when you're deciding how to ship your own tool or evaluating what to wire into an agent pipeline.
This article lays out the honest architectural distinction: typed local IPC versus a hosted JSON-RPC endpoint. Both are valid. They solve different halves of the problem.
What an MCP Server Actually Is
The Model Context Protocol (MCP) defines a standard way for an agent to discover and call tools on a remote server. You run an MCP server somewhere — locally as a subprocess, on a VM, or behind a URL — and the agent talks to it over JSON-RPC (usually stdio or HTTP+SSE).
The core pattern:
Agent ──JSON-RPC──> MCP Server (stdio / HTTP)
The server announces its capabilities (tools, resources, prompts) at connect time. The agent calls tools by name with JSON arguments and gets JSON results back. It is an RPC protocol with a well-defined schema, and that's its strength: any agent that supports MCP can talk to any MCP server without custom integration code.
The trade-off: the server is something you run and manage. You pick the transport, handle the lifecycle, decide on authentication, and ensure uptime. MCP does not specify how the server is installed, verified, kept alive, or isolated — that is your responsibility.
What an Agent App Is
An agent app (as implemented by the Pilot Protocol app store) is a different model entirely. It is a typed IPC service that runs locally on the agent's own daemon, installed with a single command and auto-spawned on demand.
Agent ──JSON──> Daemon Supervisor ──spawns──> App (local IPC)
The loop is discover → install → call:
-
Discover:
pilotctl appstore cataloguelists every available app. -
View/Inspect:
pilotctl appstore view <id>shows the manifest, permissions, and source. -
Install:
pilotctl appstore install <id>downloads the app, verifies its integrity, and registers it with the local daemon. No separate hosting, no manual wiring. -
Call:
pilotctl appstore call <id> <app>.method '<json>'— the daemon spawns the app, routes the JSON request, collects the JSON response, and tears it down when idle.
The structural differences from an MCP server are not cosmetic. They change who bears the operational cost and what guarantees you get.
The Honest Breakdown
Where It Runs
| MCP Server | Agent App | |
|---|---|---|
| Host | You provision and manage (local process, VM, container, or serverless) | Daemon-managed local process, auto-spawned from install artifact |
| Lifecycle | You start/stop/monitor it | Daemon supervises — spawns on call, idles, restarts on crash |
| Network | stdio, HTTP, SSE — requires a reachable endpoint | Local IPC socket — no network exposure |
An MCP server is a service you own the operations of. An agent app is a capability you install and forget.
Trust and Integrity
MCP servers use whatever auth the implementer chooses — API keys, bearer tokens, mutual TLS, or nothing. The protocol does not define a trust model; the agent typically trusts whatever server it connects to.
Agent apps have a built-in integrity model baked into the installation process:
- Each app's manifest pins a sha256 hash and an Ed25519 signature.
- The daemon re-verifies the hash + signature on every spawn.
- Permissions are declared in the manifest and accepted at install time — no ambient authority.
- The app runs in a daemon-supervised sandbox; it has no access to the filesystem, network, or other apps unless the manifest declares it.
This is deliberately stronger than "trust the URL" because agent apps are installed from a shared catalogue where anyone can publish.
Discovery
MCP servers are discovered through directories (like smithery.ai or community lists). Each is a pointer to a URL or repo — the agent still needs to connect and introspect to learn what tools exist.
Agent apps are runtime-discoverable after install. Calling <app>.help returns every method, its parameters, latency class, and cost — all as typed JSON, no network round-trip. The catalogue is queryable at any time with pilotctl appstore catalogue.
Protocol Surface
MCP uses JSON-RPC 2.0 over a streaming transport. It has a well-specified initialization handshake, capability negotiation, and notification model. This is powerful for complex tool ecosystems but adds overhead for simple "call a thing, get a result" operations.
Agent apps use raw JSON in → JSON out over a local IPC socket. No handshake, no capability negotiation, no streaming protocol — just input, output, and an error envelope on failure. The daemon handles transport, reliability, and spawning. The latency is negligible because there is no network.
When Each Shines
Choose an MCP server when:
- Your tool requires server-side state, databases, or external API keys that shouldn't be distributed with the client.
- You already run infrastructure and want to expose an existing service to any MCP-compatible agent.
- You need streaming responses or long-running tool calls (MCP's notification pattern fits this better).
- You want broad interoperability across agent frameworks — MCP is supported by Claude Desktop, many LangChain integrations, and a growing ecosystem.
Choose an agent app when:
- Your tool is self-contained — it does not need a backend you host.
- You want agents to install and use your tool with zero ops overhead.
- Integrity matters: you want every invocation to be signature-verified before it runs.
- You are building for an ecosystem where agents discover, install, and compose capabilities autonomously.
The honest answer is that many setups will use both. An MCP server is the right model for a hosted API gateway; an agent app is the right model for a packaged capability you want agents to self-serve.
A Concrete Example
An agent needs to research a topic. On the MCP side, it might connect to a web-search MCP server hosted at some endpoint — that server calls an upstream search API and returns results.
On the agent-app side, it runs pilotctl appstore call io.pilot.cosift cosift.search '{"q":"topic","k":"8"}' — the daemon spawns the cosift app locally, which performs grounded web search and returns structured JSON. No server to host, no API key to provision, no connection to manage. The app was installed once, signature-verified, and is always available.
Both produce search results. The difference is who owns the infrastructure between the agent and the data.
The Bottom Line
Agent apps and MCP servers are not competitors — they are different shapes for different operational realities. MCP is a wire protocol for tool interoperability across any agent and any server. Agent apps are a distribution and execution model for capabilities that install and run on the agent's own infrastructure.
If you have a backend you already run, expose it as an MCP server. If you have a capability you want agents to discover and use with no infrastructure on your side, package it as an agent app.
The Pilot Protocol app store is one implementation of the agent-app model. You can explore the catalogue at pilotprotocol.network/app-store — and publish your own app via the /publish flow. For most developers, the ideal strategy is to have both: an MCP server for your existing services, and an agent app for anything you want agents to self-install.
Pilot Protocol is an open-source overlay network with an app store for agent-native capabilities. Install with curl -fsSL https://pilotprotocol.network/install.sh | sh and explore the catalogue with pilotctl appstore catalogue.
Top comments (1)
The most useful distinction here is protocol versus distribution/execution model. MCP itself can run as a daemon-supervised local stdio subprocess, packaged with a signed manifest, auto-spawned, and sandboxed. Conversely, raw local JSON IPC does not inherently provide integrity or least privilege; those properties come from Pilot's catalogue trust root, installer, permission model, and supervisor. So the comparison table describes two current deployments, not mutually exclusive architectures. A compelling bridge would be an agent-app package whose supervised process speaks MCP locally: Pilot supplies install-time trust and lifecycle, while MCP preserves interoperability with clients outside one app-store ecosystem.