{"slug": "shipping-an-mcp-server-desktop-app-vs-hosted-web-app", "title": "Shipping an MCP Server: Desktop App vs Hosted Web App", "summary": "A developer compared shipping two Model Context Protocol servers: Hiberden, a desktop LTO tape archiving app whose MCP server runs locally over stdio inside the installer, and Easy2257, a hosted multi-tenant service whose MCP server is a network endpoint requiring authentication on every request. The account argues deployment model mechanically determines transport, authentication, distribution, and versioning decisions, with desktop servers pinned to app versions for years while hosted servers update for all users at once.", "body_md": "We ship two Model Context Protocol servers. One runs inside a desktop application, on the machine where the data already lives. The other runs as a hosted service behind an account, in front of a multi-tenant database. They speak the same protocol and share almost none of the same decisions.\n\nMost writing about MCP stops at the hello-world tutorial: register a tool, return a string, done. The interesting part starts after that, when you have to decide where the server runs, how it reaches users, how you update it, what it is allowed to touch, and what happens when the assistant calling it is confidently wrong. Those answers are not a matter of taste. They fall out of the deployment model almost mechanically.\n\nHere is the comparison, decision by decision.\n\n[Hiberden](https://hiberden.app) is desktop software for LTO tape archiving. It keeps a local catalog of everything it has archived: every project, every copy on tape, disk, NAS and cloud, every file path, every checksum, and every overnight job. The MCP server ships inside the application.\n\n[Easy2257](https://easy2257.com) is a hosted service that keeps 18 U.S.C. 2257 records for producers in a federally regulated vertical: who appeared in a scene, that identity was verified, which paperwork is signed, and a certificate proving the record existed at a point in time. Its MCP server runs as part of the service. Nothing is installed.\n\nOne catalog sits on your desk. The other sits in a database shared by every customer. Nearly everything below follows from that one difference.\n\nThe desktop server is a local process. The transport is stdio: the assistant launches the server as a subprocess on the same machine as the data. There is no network hop, no listening port, and no inbound surface to attack. The catalog it reads is an ordinary local file the user already owns.\n\nThe hosted server is a network service. The assistant connects across the internet to something holding many companies' records at once. Every single request has to answer \"who is asking, and what are they entitled to see\" before it can answer anything else.\n\nThe consequence is not subtle. On the desktop, authentication is mostly solved before you write a line of server code: the person is sitting at the machine, and the operating system already decided they can open that file. On a hosted server, authentication *is* the product surface. It is the first thing you build and the thing you keep rebuilding.\n\nA desktop server has to physically arrive on the machine. A well-built one ships inside the installer, and it is also published to the official MCP registry as a versioned, checksummed bundle running over stdio, plus third-party directories like Glama, which is increasingly how assistants and their users discover servers at all.\n\nA hosted server has nothing to install. The endpoint exists the moment the account exists. Distribution stops being an engineering problem and becomes a documentation problem: the work is making the connection instructions short enough that somebody finishes them.\n\nEach model quietly inherits a different environment. Ship on the desktop and you inherit the user's machine: operating system versions, assistant clients that each store their config somewhere different, antivirus software with opinions about unsigned subprocesses. Ship hosted and you inherit the network: timeouts, retries, and clients that will absolutely call the same tool four times in a row.\n\nThis is where the two models diverge hardest, and it is the one people underestimate.\n\nOn the desktop, the server version is pinned to the application version. A customer running last spring's build is running last spring's tools, and they may run them for years. You cannot fix a tool for everybody at once, and you cannot remove one either, because somebody who never updates will keep calling it forever. Deprecation is a release-notes problem measured in years, not sprints.\n\nOn the hosted service there is exactly one version and everyone is on it. A fix reaches every customer the moment it deploys. The flip side is that a breaking change breaks every customer simultaneously, and the software calling your tools is not your software. It is somebody's assistant, wired up months ago, that you cannot test against.\n\nWhat that works out to in practice: on the desktop, make changes additive and never alter a tool signature that already shipped. On hosted, you can iterate faster, but treat the tool list as a published API contract, because that is what it is.\n\nThe desktop application already holds credentials it needs for its own work, such as the keys for the customer's own cloud storage account. Those live in the operating system keyring. The rule we settled on is simple and worth stating plainly: **credentials never pass through the assistant**. The assistant asks the catalog questions and the catalog answers them. Keys are not part of the conversation, are never returned by a tool, and are never needed to call one.\n\nThe hosted server has the opposite problem, because the connection itself needs a credential. There are two routes in. A customer can generate an API key, which is hashed at rest and displayed exactly once, capped at ten per account, with every key revoked automatically if the account password is reset. Or they can sign in interactively and connect with short-lived tokens, which can be disconnected in one click. Either way, a credential is scoped to exactly one account, and attempts to look up records belonging to somebody else are throttled rather than merely refused.\n\nNow the interesting part. The two servers made opposite choices, and both are right.\n\nThe desktop server exposes about thirty tools, and a good number of them write. They can create a project, assign a policy, move an archive between destinations, retire a destination, or delete a copy. That is defensible because the person driving the assistant already owns the data and the machine. Deleting a copy through an assistant is not more dangerous than deleting it through the application's own interface: same person, same computer, same file.\n\nWhat it does require is that consent is explicit and the work leaves a record. Permissions are a setting inside the application rather than something an assistant can grant itself. Read-only is the default. Destructive operations sit behind their own separate switch. Every action is written to an audit trail.\n\nThe hosted compliance server exposes sixteen tools and *none* of them can create, change, sign, delete, or pay for anything. That is not timidity. On a shared compliance service, a write tool means an assistant can hallucinate a state change into somebody's federal records. The blast radius is not a ruined afternoon, it is a legal record about a real person. So the write path stays where it belongs: on the website, performed by a human being, on purpose.\n\nThe rule that falls out of the comparison: **how much a tool is allowed to do should track who absorbs the damage when it is wrong.**\n\nThe second divergence is quieter and, we think, more important.\n\nThe desktop server returns file paths, file names, checksums, and tape barcodes. Every bit of that is already sitting on the user's own disk. Handing it to an assistant running as a subprocess on the same machine leaks nothing that was not already there to read.\n\nThe hosted compliance server deliberately returns none of the identity data it holds. No names, no dates of birth, no ID numbers, no images, no document contents, no file paths. What comes back is compliance state: record codes, statuses, counts, dates, and content hashes. Records are referred to by public codes rather than by the people in them.\n\nThat is not a gap in the feature set. It is the reason the surface is safe to point at a shared assistant at all. There is nothing in the payload worth stealing.\n\nA desktop server is discovered the way software is discovered: registries, directories, and the installer the user already ran. A hosted server is discovered the way an API is discovered: documentation, a setup page, and a connect button inside the product. If you are building one, budget real time for whichever of those applies. A server nobody can find is indistinguishable from a server that does not exist.\n\nBoth servers are live. The desktop connector is documented at [hiberden.app/mcp](https://hiberden.app/mcp), including exactly what it can and cannot do. If you are building something similar and want a second pair of eyes on the architecture, that is the kind of work we do in [custom development](https://agaveis.com/custom-development) and [local AI integration](https://agaveis.com/local-ai).\n\n*Originally published at [agaveis.com](https://agaveis.com/blog/mcp-server-desktop-app-vs-hosted-web-app).*", "url": "https://wpnews.pro/news/shipping-an-mcp-server-desktop-app-vs-hosted-web-app", "canonical_source": "https://dev.to/agave_info_solutions/shipping-an-mcp-server-desktop-app-vs-hosted-web-app-1hk7", "published_at": "2026-09-26 02:29:00+00:00", "updated_at": "2026-09-26 02:30:06.200825+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "developer-tools", "ai-tools"], "entities": ["Model Context Protocol", "Hiberden", "Easy2257", "Glama"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/shipping-an-mcp-server-desktop-app-vs-hosted-web-app", "markdown": "https://wpnews.pro/news/shipping-an-mcp-server-desktop-app-vs-hosted-web-app.md", "text": "https://wpnews.pro/news/shipping-an-mcp-server-desktop-app-vs-hosted-web-app.txt", "jsonld": "https://wpnews.pro/news/shipping-an-mcp-server-desktop-app-vs-hosted-web-app.jsonld"}}