MCP Clients and Servers

What are MCP clients and servers?

MCP stands for Model Context Protocol. It is a protocol that lets AI applications connect to external data sources, tools, and workflows through a common client-server pattern. In MCP architecture, the host is the AI application or agent environment, the client is the connection component created by that host, and the server exposes resources, prompts, or tools for that client to discover and call. A host can run multiple client connections, typically with each client maintaining a one-to-one connection to a server.

The idea is similar to giving an AI assistant a standard way to ask, "What files, records, functions, or actions are available to me?" Instead of every AI product building a custom connector for every database, ticketing system, code repository, browser, or business application, MCP defines a shared message model for making those capabilities available.

That makes MCP useful, but it also makes it security-sensitive. A server that exposes a read-only documentation index is very different from one that can query customer data, send emails, open support tickets, modify code, or trigger financial actions. Site owners, security teams, and platform teams should treat MCP as an integration surface, not just an AI convenience feature.

Why does it matter?

MCP matters because it moves AI systems closer to real operational systems. A chatbot without tools can answer from its model and prompt context. An agent with MCP-connected tools can retrieve current records, inspect internal systems, call APIs, and act on behalf of a user or workflow.

That shift changes the risk profile. Traditional application security focuses on users, services, browsers, APIs, and backend permissions. MCP adds a layer where natural-language instructions can influence which tools are selected and what arguments are sent. The model may be reasoning over untrusted website content, uploaded files, chat messages, logs, or retrieved documents at the same time it has access to tools.

For public websites and APIs, MCP can also increase automated access. Agents may browse pages, retrieve product data, compare prices, summarize articles, test workflows, or interact with APIs as part of a user request. That can be legitimate, abusive, or somewhere in between. Teams that already monitor AI crawler traffic should expect MCP-style integrations to make the boundary between crawler, assistant, and acting agent less clear. Related crawler guidance is covered in what are AI and LLM web scrapers? and how to detect AI crawlers.

How MCP clients and servers work

At a high level, an MCP client connects to an MCP server, negotiates capabilities, and exchanges structured messages. The server may expose three broad kinds of capability.

Resources are data the client can read, such as files, knowledge-base entries, database records, logs, or documents. Prompts are reusable prompt templates or workflows the client can request. Tools are callable functions, such as searching a system, creating a ticket, sending a request to an API, updating a record, or running a local command.

The client presents those capabilities to the model or agent runtime. When the model decides it needs a tool, the client sends a structured request to the server. The server executes the operation or retrieves the data, then returns a structured response. The client may then pass that result back into the model's context.

This separation is important. The model is not usually connecting directly to every backend. The client and server sit between the model and the outside world. That gives teams places to enforce permissions, validate arguments, redact sensitive data, log activity, and require human approval for risky actions.

Risks and abuse modes

The biggest MCP risks come from misplaced trust. A tool description may sound harmless while the action behind it is powerful. A prompt injection in a web page, document, email, or support ticket may attempt to influence the agent into calling a tool with attacker-controlled arguments. A server may expose more resources than the user should see. A client may approve tool calls automatically without showing enough detail to the user.

Excessive permissions are a common failure mode. If every user reaches the same MCP server with the same high-privilege service account, the agent can become a path around normal authorization. Tool output can also leak sensitive data when retrieved context is passed back into model prompts, chat transcripts, logs, or analytics systems.

Operational failures matter too. A tool that performs searches, scraping, code execution, or large API queries can create unexpected load. An agent that retries aggressively may amplify a partial outage. A poorly bounded crawler-like tool can request large parts of a website, creating the same concerns described in how to block AI crawlers.

Evaluation checklist

Teams evaluating MCP clients and servers should start with the same questions they would ask of any integration that connects users to sensitive systems:

• What resources, prompts, and tools does the server expose?
• Which users, clients, or agent workflows can access each capability?
• Are permissions evaluated per user, per tenant, per environment, and per action?
• Can tool calls change state, send messages, spend money, publish content, or access regulated data?
• Are tool arguments validated against a strict schema?
• Is untrusted content clearly separated from system instructions and tool instructions?
• Are tool calls logged with user, client, server, arguments, result status, and approval evidence?
• Can high-risk calls require human approval with the exact action displayed?
• Are rate limits, timeouts, and retry limits enforced?
• Is there a clear way to disable a server or tool during an incident?

This review should include security, platform, privacy, and business owners. The important question is not only "Can the AI use this tool?" It is "What is the worst reasonable outcome if the AI uses this tool at the wrong time, with the wrong input, or under the wrong identity?"

Controls and governance

Good MCP governance starts with least privilege. Expose narrow tools rather than broad backend access. Prefer read-only access until there is a clear business need for write actions. Use per-user authorization rather than shared high-privilege credentials. Keep production, staging, and local development capabilities separate.

Tool design should make misuse harder. Use strict schemas, bounded arguments, safe defaults, and explicit confirmation for destructive or external actions. Avoid tools that accept arbitrary natural-language instructions and then decide internally what to do. If a tool can send data outside the organization, show the destination and payload before approval.

Monitoring should connect MCP activity to the rest of the request path. A security team should be able to answer which agent called which tool, what content influenced the call, what backend request was made, and what data came back. For web-facing systems, combine MCP monitoring with bot, API, and application-security telemetry. Useful background controls are covered in what is API security? and what is REST API security?.

MCP can make AI systems more useful because it gives them structured access to real context and tools. The same property makes it a governance surface. Treat clients and servers as part of the application architecture, keep permissions narrow, and assume that any data the agent can read or action it can influence.

Related learning

• ChatGPT Plugins
• Prompt Injection
• How To Manage AI Agents For Businesses
• OWASP Top 10 Risks for LLMs