Three deployment shapes
Local stdio: the server runs as a child process on your machine, communicating over standard input/output. Data never leaves the machine; the trust model is simplest — you only need to trust the code itself.
Self-hosted HTTP: the server runs on your own servers, shared by the team. Data never leaves your infrastructure boundary, but you handle auth and high availability yourself.
Hosted remote: run by the official team or a third party, ready to use. Least effort, but data flows through a third party; the trust model is most complex — you trust the code, the operator, and their infrastructure at once.
Decision matrix
Handling sensitive data (production databases, internal docs) → consider only local stdio or self-host.
Shared by a team, needs centralized audit logs → self-hosted HTTP.
Personal productivity tools, data is public anyway (web scraping, search) → the convenience of hosted remote is usually worth it.
Latency-sensitive scenarios (real-time code analysis in the IDE) → local stdio, saving the 50-200ms network round-trip.
Hybrid strategy (recommended)
In practice most teams use a hybrid strategy: run data servers (databases, file systems) locally, use hosting for capability servers (search, scraping). Draw the boundary by data sensitivity, not one-size-fits-all.