Once models can call tools, an obvious problem appears. Every AI application needs to connect to every useful data source, and every data source needs to work with every application. That is multiplicative work, and it is the reason integrations felt so repetitive.
The problem, concretely
Five AI applications, twenty data sources, and you are looking at a hundred bespoke integrations — each with its own authentication, its own schema, its own maintenance.
A shared protocol makes it additive instead: each source implements the protocol once, each application speaks the protocol once, and everything interoperates. This is the same argument that produced any successful standard.
MCP — the Model Context Protocol — is one such standard for exposing capabilities to AI clients.
Clients and servers
A server exposes capabilities. It might offer access to a filesystem, a database, a ticketing system, a repository. It declares what it provides and how to call it.
A client is the AI application that connects to servers and makes their capabilities available to the model.
The model itself is not part of the protocol. It still does exactly what the previous lesson described — emits a request to use a named tool with arguments. MCP standardises how the client discovered that tool existed and how it routes the call.
Servers typically expose three kinds of thing:
- Tools — actions that can be taken
- Resources — data that can be read
- Prompts — reusable templates the server suggests
Trust is the thing to think about
Connecting a server grants real access to whatever it exposes. Before adding one, the questions are ordinary security questions:
- Who wrote it, and can you read the source?
- What access does it require, and is that the minimum for what you need?
- Where does data go? A server sits between your data and the model.
- Can it be scoped — read-only, one directory, one project?
A connector with broad write access is a broad write capability handed to a system that can be influenced by text it reads. The prompt injection lesson applies directly: retrieved content is untrusted, and a widely-scoped connector turns a successful injection into a real action.
Standard connector or custom tool?
Use a standard connector when the capability is common — files, a well-known SaaS product, a database — and a maintained implementation exists. You inherit its maintenance and its conventions.
Write a custom tool when the capability is specific to your domain, when you need tight control over scope and validation, or when the operation should be deliberately narrow. A tool that does exactly one safe thing is often better than a general connector that could do a hundred.
Most real systems use both: standard connectors for commodity access, narrow custom tools for anything consequential.