An MCP connector is a server that offers tools and data to an AI application through the Model Context Protocol. The chat app is the host, it creates one client per server, and the server is the connector. For a security buyer, the connector is the part that decides what the assistant can see and do.
The three parts
The MCP architecture overview names three participants.
- Host: the AI application, such as a chat app or a coding assistant.
- Client: a component inside the host that keeps one dedicated connection to one server.
- Server: the program that provides context, wherever it runs.
The word server confuses people. It does not mean a big machine in a data center. The documentation says an MCP server is simply the program that serves context, whether it runs locally or remotely.
Local and remote servers
A local server uses the stdio transport and normally serves a single client on the same machine. A remote server uses Streamable HTTP and usually serves many clients. Remote servers support standard HTTP authentication, and MCP recommends OAuth to obtain tokens.
For security tools this split matters. A remote connector holds credentials on the vendor side and checks who you are. A local one runs code on your laptop with your privileges.
What a connector can offer
The architecture page lists three primitives a server can expose.
| Primitive | Meaning | Security example |
|---|---|---|
| Tools | Functions the assistant can call | List findings for a project |
| Resources | Data the assistant can read | An exported report |
| Prompts | Reusable templates | A triage checklist |
Tools are the ones to scrutinize, because tools can act. The tools page says they are model controlled, meaning the model can discover and invoke them from your prompt.
Why buyers should care
When a vendor says it has an MCP connector, the useful questions are about the tool list, not the logo on the integrations page.
- How many tools are there, and which ones can change data?
- Which can be switched off by an administrator?
- How does the connector prove who is asking?
- What is recorded when a tool is called?
The protocol itself does not answer these. The architecture page states that MCP focuses on the protocol for context exchange and does not dictate how AI applications use language models or manage context. The vendor and your chat provider fill in the rest.
A one minute mental model
Think of a power strip. The host is the wall socket, the client is the plug, and the connector is the appliance. The protocol makes the plug fit. It does not tell you whether the appliance is safe to leave running.
A worked example: one question, five steps
Suppose an engineer types a question into a chat app that has a security connector attached: which of our projects have open critical findings? Here is what happens, in the order the architecture overview describes.
- The host, which is the chat app, already has a client for the connector and a cached list of its tools.
- The model reads the question and the tool list and decides that a findings tool matches.
- The host routes a tool call through that client to the server, which is the connector.
- The server checks who is asking, runs the query, and returns a result.
- The host passes the result back to the model, which writes the answer you read.
At no point did the model talk to your security database directly. Everything passed through the connector, which is why the connector is the place to apply controls.
Where each participant can go wrong
| Participant | Typical failure | Who owns the fix |
|---|---|---|
| Host | Shows no approval prompt, or hides which tool ran | The chat provider |
| Client | Caches an old tool list | The chat provider |
| Server | Returns more data than the user should see | The connector vendor |
| Model | Misreads a result or follows text hidden in it | Shared, so keep humans involved |
Buyers often only review the server. All four rows matter. The tools specification says applications should show which tools are exposed to the model, indicate when tools are invoked, and present confirmation prompts. That is host behavior, and you can test it.
Step by step: draw your own diagram
Before you approve a connector, draw the path on one page. It takes ten minutes.
- Write the name of the chat app and the plan you use.
- Write the connector's name and whether it is local or remote.
- Write the sign in method between the app and the connector.
- List the tools, marking read and write.
- Write where the security data lives and who can see it there.
- Mark every place a person can approve or deny.
- Circle any step where you do not know the answer.
The circled steps become your questions for the vendor and for the chat provider.
Terms you will hear
- Transport: how messages travel. Local servers use standard input and output. Remote servers use HTTP.
- Capability: a feature the server declares, such as tools or resources.
- Primitive: one of the core types of thing a server offers, which are tools, resources and prompts.
- Discovery: the client asking what a server can do.
Why one client per server matters
The documentation says the host creates one client for each server, each with a dedicated connection. That isolation is useful. If you disconnect one connector, the others keep working, and you can reason about each connection separately. It also means that the number of connectors is the number of connections to review, not one combined review.
What to take to a vendor meeting
Bring the one page diagram. Ask the vendor to correct anything wrong on it and fill in the circled steps. A clear vendor will do that in one meeting. A vague one will tell you the diagram is too detailed, which is its own answer.
Where Safeguard fits
Safeguard offers an MCP Guardrail for policy on the tools agents can call, and asset discovery for inventory. A good first step for any team is to list what is connected today.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the setup and notice which tools a server exposes before any assistant uses them.
Quick check
Is the host the same as the model?
No. The host is the application, such as a chat app. The model is what the host uses to generate answers. The host decides when to call a tool on the model's behalf.
Can one chat app talk to several connectors at once?
Yes. The documentation says a host creates one client per server, so it can hold many connections at the same time.
Where do I turn off a tool I do not need?
In the chat app's tool menu if it offers one. Claude's help center describes disabling unneeded tools from the search and tools menu.
Sources
Last reviewed: 19 October 2026.
