MCP Explained: Clients, Servers, When to Use It, and How Agent Harnesses Fit

What is MCP?

Model Context Protocol (MCP) is an open standard for communication between an AI application and external capabilities.

An MCP server can expose capabilities such as searching a knowledge base or querying alerts. An MCP client inside the AI application communicates with that server.

MCP servers can expose three main building blocks:

• Tools: Callable functions, such as searching alerts or creating a ticket.
• Resources: Data made available as context, such as documents or database schemas.
• Prompts: Reusable prompt templates for specific tasks.

MCP defines the communication interface. It does not decide what an agent should do next, manage the agent's reasoning loop, or automatically make an integration secure.

An AI assistant can explain a suspicious login from information you paste into a chat. But what if you want it to retrieve the alert, check related events, and prepare an incident ticket using your organization's systems?

That requires connections to real tools and data, plus software to coordinate the work. This is where two commonly confused ideas appear: Model Context Protocol (MCP) and an agent harness.

Here's the distinction up front:

MCP standardizes how an AI application accesses external capabilities. An agent harness manages how an agent uses capabilities to complete a task. Neither replaces your existing APIs, permissions, or security controls.

1. First, understand the four players

An MCP server does not have to be a separate physical server. It can be a local process started on your laptop or a remotely hosted service. And the language model does not directly connect to the MCP server: the application's MCP client does.

What can an MCP server expose?

• Tools: Callable operations such as get_alert, search_tickets, or create_ticket. A tool can read data or perform an action.
• Resources: Data the application can read as context, such as an approved document.
• Prompts: Reusable templates, often selected by a user.

MCP defines the interface for discovering and invoking these capabilities. The server's implementation decides how it connects to the underlying system.

2. Where do the MCP client and server come from?

A frequent beginner's question is: Do I need to write both? Usually, no.

If you already use an MCP-capable AI application: its developers provide the MCP client. You configure a compatible server and give the application permission to connect to it. Depending on the product, you may supply a server URL or a local command to launch it.

If you need an MCP server: there are three common paths. Use a server supplied by the system vendor, evaluate an open-source or third-party implementation, or build an internal server around your approved API. You can discover published servers in the official MCP Registry and study the project's reference server examples. A listing is not a security endorsement, and reference examples are not automatically production-ready. Review ownership, source code, requested privileges, maintenance, and data handling before connecting anything to production.

If you are building your own AI application: you can implement its MCP client using an official SDK. You also decide which exposed tools to show the model and which requests the application will authorize.

Two useful connection methods are:

The connection method is not the security policy. Authentication, authorization, network exposure, and secrets management still need deliberate design.

3. Build a tiny MCP server and client

This example uses the official MCP Python SDK v2. It is intentionally small and uses synthetic alert data—no SIEM credentials, network access, AI model, or agent harness are required.

Install the SDK in a Python 3.10+ environment:

python -m pip install "mcp>=2,<3" 

Save the following as server.py:

from mcp.server import MCPServer from mcp.server.mcpserver.exceptions import ToolError mcp = MCPServer("Training SOC Alerts") @mcp.tool() def get_alert(alert_id: str) -> dict[str, str]: """Read one demonstration security alert by its ID.""" if alert_id != "A-1042": raise ToolError("Alert not found") return { "alert_id": "A-1042", "user": "demo.user@example.invalid", "signal": "Sign-in from an unfamiliar location", "status": "Open", } if __name__ == "__main__": mcp.run() # Start a local stdio server 

The SDK turns the function's name, type annotations, and description into a discoverable MCP tool. The function itself supplies the data. A real implementation would query an authorized SIEM API rather than return a fixed record.

Now save this as client.py in the same directory:

import asyncio import sys from pathlib import Path from mcp import Client, StdioServerParameters async def main() -> None: server = StdioServerParameters( command=sys.executable, args=[str(Path(__file__).with_name("server.py"))], ) async with Client(server) as client: tools = await client.list_tools() print("Available tools:", [t.name for t in tools.tools]) result = await client.call_tool( "get_alert", {"alert_id": "A-1042"} ) print(result.structured_content) if __name__ == "__main__": asyncio.run(main()) 

Run:

python client.py 

The client starts the server as a subprocess, discovers get_alert, calls it with an alert ID, and prints the result. You have now used MCP without an LLM. That is useful because it proves MCP is a communication protocol, not the AI model or the agent workflow.

To connect this server to an existing MCP-capable host, follow that host's configuration instructions and specify how to launch server.py. See the official host integration guide. For remote use, the SDK also supports Streamable HTTP; that requires appropriate deployment and access controls.

4. What is an agent harness—and why isn't it MCP?

An agent harness is the runtime software that coordinates an AI agent's work. It prepares requests to the model, supplies context and tools, handles returned tool calls, maintains task state, and may implement logging, limits, retries, and human approvals.

Think of the distinction this way:

• Model: Suggests the next step based on available context.
• Harness: Runs the multi-step process and coordinates checks and tool execution.
• MCP client/server: Provide a standardized path to available tools and data.

A harness can call APIs directly without MCP. An MCP client can call a server without a harness, as our Python example demonstrates. You need both only when you have both integration and workflow-orchestration requirements.

Terminology note: “agent harness” is an architectural term. It is not the same as Harness, the named software-delivery platform.

5. Detailed example: an SOC assistant investigates a login alert

Consider a hypothetical enterprise SOC with a SIEM, an identity system, and an incident-ticket platform. The team wants an assistant to gather evidence, draft a recommendation, and—only after approval—open a ticket.

The application contains a language model, an agent harness, and MCP client connections to approved servers:

• Read-only Security MCP server: Exposes get_alert and get_sign_in_history; its backend calls authorized SIEM/identity APIs.
• Ticketing MCP server: Exposes create_incident_ticket; its backend checks the caller's authorization and calls the ticketing API.

The investigation might unfold like this:

Step 1 — An analyst asks: “Investigate alert A-1042. Tell me whether it needs escalation.”

Step 2 — The harness prepares the request: It supplies the model with the analyst's question, relevant instructions, and the tools permitted for this session. The model proposes calling get_alert("A-1042").

Step 3 — The MCP client requests the alert: The host's client sends a tool call to the read-only MCP server. That server validates the request, queries the SIEM through its own approved integration, and returns the alert fields. The MCP server does not decide whether the login is malicious.

Step 4 — The model asks for more context: The first alert reports a login from an unfamiliar location. That is a signal, not proof of compromise. The model may request get_sign_in_history to compare surrounding activity. The harness coordinates the next tool call and keeps track of the results.

Step 5 — The assistant drafts a finding: Based on returned evidence, it might report: “Unusual sign-in location observed; investigate device, MFA, and expected travel or VPN usage. Confidence is limited until those checks are completed.” Claims should be traceable to tool responses, not filled in by the model.

Step 6 — A proposed write action is gated: If creating a ticket is appropriate, the harness requests human approval before executing create_incident_ticket. If denied, no ticket is created. If approved, the host's MCP client calls the ticketing MCP server, which must still enforce service-side authorization.

Step 7 — The analyst receives the outcome: The harness returns the ticket ID if creation succeeded, or a clear error if it failed, plus an evidence-based summary and any unanswered questions.

The drawing is conceptual. Every MCP tool call—including an approved ticket-creation call—must be routed through the application's MCP client. Human approval in the harness does not replace authorization at the ticketing system.

What each component contributed: MCP made the two external integrations available through a consistent interface. The harness coordinated the multi-step task and approval point. The model interpreted evidence and suggested next steps. The SIEM and ticketing systems remained the authoritative systems of record.

6. When should you use MCP—and when should you skip it?

An important distinction: Retrieval-augmented generation (RAG) is a method of retrieving information for model context. MCP can be one way for an application to access retrieval capabilities, but RAG does not require MCP.

7. Before using MCP in production, check the boundaries

The most useful architecture question is not “Can the model call this tool?” but “What could this tool expose or change if the model requested the wrong thing?”

Review these controls before rollout:

• Permissions: Separate read-only tools from write or destructive tools. Apply least privilege to both the MCP server and downstream APIs.
• Approval and enforcement: Gate sensitive actions in the harness, and enforce authorization independently at the server/backend.
• Input and output safety: Validate tool parameters. Treat tool descriptions, documents, and returned data as potentially untrusted; prompt injection can originate in retrieved content.
• Credentials and data: Store secrets outside prompts and source code. Limit sensitive fields passed to the model and follow data retention requirements.
• Operations: Log who invoked which tool, with safe handling of sensitive content; monitor failures, timeouts, rate limits, and retries. Avoid automatically retrying non-idempotent write actions without safeguards.

MCP standardizes the connection; it does not automatically make the connected system safe.

A simple decision rule

Ask yourself two separate questions:

1. Do multiple AI workflows need a consistent way to access tools or context? Consider MCP.
2. Does the assistant need to coordinate several model/tool steps with state or approvals? Consider an agent harness.

If both answers are yes, they can complement each other. If not, use the simpler architecture.

MCP is the interface. The harness is the runtime coordinator. The model supplies reasoning. Your applications and security controls remain responsible for what is actually allowed.