A package or a URL
Both carry the same protocol. A package people install runs over stdio on their machine; a URL such as GitLab's /mcp runs on your infrastructure over Streamable HTTP. The choice is about where code runs and who holds the keys.
By the end of this lesson you can
- compare a local package and a remote URL on seven dimensions;
- say which one an enterprise should default to, and when the other is the right call;
- describe the thin local proxy and the one-factory pattern.
Copies everywhere, or one place
Where the code runs
- As a package, a copy of your server runs on every user's laptop.
- You release v1.4. Some users upgrade, some do not: versions drift, and you support all of them.
- Each copy holds its own secret in an env var or config file, and runs with that user's permissions. In return it can reach their files, their IDE, localhost and a local browser.
- As a URL, one deployment serves every host that dials in.
- Deploy v2.0 once and everyone has it.
- Each user signs in with OAuth; tokens are short-lived, every call is audited, and access is revoked in one place.
- For a host that only speaks stdio, a thin local proxy can forward to the remote server.
Side by side
| Local package (stdio) | Remote URL (HTTP) | |
|---|---|---|
| Code runs | On every user's laptop | On your servers |
| Updates | Each user upgrades; versions drift | Deploy once; everyone has it |
| Credentials | Secrets in env or config files on each machine | OAuth per user, short-lived tokens, central revocation |
| Audit and kill switch | Hard | One place |
| Supply chain | Your code runs with each user's permissions | Your code runs with your service's permissions |
| Can reach | Local files, the IDE, localhost, a local browser | Only what your network can reach |
| Latency and offline | In-process, works offline | Network round trip |
Recommendation
For an enterprise, default to the URL. Anything touching company data or a SaaS API belongs behind central auth, audit and rollout. Ship a stdio package only when the server must reach the user's own machine. For hosts that only speak stdio, a thin local proxy can forward to the remote server. With the SDK, both entry points come from one server factory (lesson 16).
Where should this server run?
For each server, choose a local package or a remote URL.
- Reads and edits files in the project folder the user has open. It must reach the user's own disk, so it runs where they are.
- Lets a 300-person sales team query the company CRM. Company data, many users: central OAuth, audit and one deployment.
- Drives the user's local browser for end-to-end tests. A local browser is only reachable from the user's machine.
- Creates Jira tickets with each user's own permissions, with an audit log. Per-user authorization and audit are what the remote, OAuth-protected server gives you.
- Your SaaS product's server, which customers add to Claude. Deploy once, update for everyone, revoke centrally; nothing of yours runs on customers' laptops.
- Talks to a database running on localhost during development. localhost is the developer's machine; a remote server cannot reach it.
Quick check
Why is a stdio package harder to govern in a company?
Your remote server must also work in a host that only supports stdio. What do you ship?
Recap
- Package: runs on each laptop, versions drift, secrets on every machine, but can reach local files, the IDE and localhost.
- URL: deploy once, OAuth per user, audit and revocation in one place, only reaches what your network reaches.
- Enterprise default: the URL; stdio only for local resources; a thin proxy for stdio-only hosts; one factory for both.