Model Context Protocol servers give AI assistants tools: query a database, read tickets, check deployments. When a team adopts them, an early question is whether everyone runs their own copy locally or the team shares one hosted instance.
Per developer, local#
Each person runs the MCP server on their machine, usually launched by their editor or assistant over standard input and output.
Pros:
- Zero infrastructure.
- Each person uses their own credentials, so permissions follow existing access.
- Easy to experiment with.
Cons:
- Credentials spread across laptops, often in plain config files.
- Versions drift; one person's tool behaves differently from another's.
- No central record of what tools did.
Shared, hosted#
One MCP server runs on a server the team controls and is reached over HTTP with authentication.
Pros:
- Credentials to backend systems live in one place, not on every laptop.
- One version, upgraded once.
- A central log of tool calls: who asked, which tool, what arguments.
- Access can be scoped per user or group.
Cons:
- Someone has to run, secure and monitor it.
- Authentication between assistants and the server must be set up properly; an unauthenticated endpoint is a serious exposure.
- Actions happen under a service identity unless you pass user identity through.
A practical split#
Read-only tools that touch shared systems, such as logs, metrics and deployment status, fit well on a shared server with central auditing. Tools that act on a developer's own environment, such as local files or a local database, belong on the developer's machine.
Before you host one#
Decide how users authenticate, how tokens are scoped, where logs go and how long they are kept. Start with read-only tools and add write actions one at a time.
For a walkthrough of deploying and securing a shared instance, see this guide to self-hosting an MCP server for your team.
Comments
No comments yet. Start the conversation.