The problem: every AI tool wants its own integration
If your team has tried to connect more than one AI client to the same data — email, a wiki, a ticket tracker, a shared knowledge base — you've probably run into the same wall from the other direction: every vendor built its own plugin system, its own connector format, its own auth flow. Wiring up Slack for one client doesn't help the next client you adopt; you start over. Multiply that by every tool your team uses and every AI client your team wants to use, and the integration work grows with both axes at once.
MCP exists to collapse that grid into a line. Instead of N clients each needing a custom integration with M tools, a client that speaks MCP can connect to any server that speaks MCP — one implementation, reusable everywhere. For a team evaluating whether to adopt it, or evaluating a specific MCP server (like a shared memory layer), the useful question isn't "what is MCP" in the abstract — it's what the protocol actually does, how a server proves it's trustworthy, and what changes for your team once it's wired up.
This guide is that evaluator-level explanation: what MCP is, how remote and local servers differ, how authentication works for different kinds of clients, and what to look for in a server before you connect your team's data to it.
How it works
Model Context Protocol is an open standard for letting an AI client call external tools and data sources through a consistent interface, using JSON-RPC as the message format. A server implementing MCP exposes a set of tools (and, for some servers, resources and prompts); a client that speaks MCP can discover what a server offers and call it, without the server and client needing a bespoke integration built for each other.
Servers come in two shapes. A remote server runs over HTTP — specifically the Streamable HTTP transport — and any properly authenticated client on the internet can reach it. This is what browser-based clients like Claude.ai, ChatGPT, and Gemini's web interface use, since they have no local process to run a server from. A local server runs as a stdio process launched directly by the client — common for CLI tools and IDEs that can spawn a subprocess and talk to it over standard input/output instead of the network.
Authentication follows the same split. Web clients authenticate to a remote MCP server with OAuth 2.1 and dynamic client registration: the client registers itself with the server, and you approve access through a consent screen, the same shape as any other "sign in with X" flow. File-based clients — CLIs, desktop apps, IDEs — typically use a personal API token instead, generated once and stored locally, since there's no browser in the loop to run an OAuth consent screen through.
Evaluating an MCP memory server
Because MCP is just a protocol, the trust boundary lives in the server, not the protocol itself. Before connecting your team's data to any MCP server, the questions worth asking are:
- How is data isolated between tenants? A server used by more than one team or account should scope data at the workspace or account level — not pool everyone's data with client-side filtering as the only boundary.
- Is data encrypted at rest? For a memory or document server specifically, this matters for anything stored long-term, not just in transit.
- What authentication does each client type use? OAuth for web clients, tokens for file-based clients, as described above — and whether tokens are stored hashed rather than in plaintext, and revocable per client.
- What happens to the content once it's stored? Whether it's used to train models, and if so whose, and under what consent.
Setting it up for your team
- Create an account. Sign up at /sign-up — no credit card required for the 14-day trial.
- Open the install page. Go to /install once signed in. This mints the credentials each client needs: an OAuth connection for web clients, or an API token for file-based ones.
- Connect your team's clients one at a time. The install page groups clients by setup effort: one-click (a deeplink or installer script, no terminal), one-liner (a single copy-pasted CLI command), or guided OAuth (adding a custom connector in the client's own settings, then completing a consent screen). Each client type gets the auth method appropriate to it, as described above.
- Confirm each connection. Most clients are detected automatically once connected; a manual confirmation step covers the ones where automatic detection isn't reliable.
- Repeat per teammate. Every teammate signs up for their own account and connects their own clients — the workspace and its data are shared, but each person's client connections are their own.
Where to go next
For the practical, day-to-day version of what a shared memory layer changes once it's connected, One Memory Across Every AI Client covers the problem this solves and what syncing looks like across tools. If Slack is one of the data sources your team wants searchable from AI clients, MCP Server for Slack covers that integration specifically.