Skip to main content

MCP Client: Connecting AI Agents to Capability Providers

What Is an MCP Client​

An MCP Client is the software component that enables AI agents and applications to connect to MCP Servers, discover their capabilities, and consume tools, resources, and prompts through the Model Context Protocol. Unlike an ad‑hoc integration, an MCP Client implements the standard JSON‑RPC 2.0 handshake, capability negotiation, and transport‑layer communication, providing a unified interface for agents to interact with any compliant MCP Server.

In the MCP ecosystem, the client is the actor—it initiates connections, discovers what tools are available, invokes them, and fetches resources or prompts as needed. The server merely responds to these requests. This separation of concerns allows an AI agent to remain agnostic to how a tool is implemented; it only needs to know that the client will translate its intent into a correctly formatted MCP request.

Why MCP Clients Matter​

MCP clients solve three fundamental integration challenges that plague ad‑hoc tool consumption.

ProblemWithout MCPWith MCP Client
Tool discoveryHardcoded tool names and endpointsRuntime tools/list returns available tools dynamically
Transport complexityCustom HTTP client, stdio handling, error managementSDK abstracts all transport details
AuthenticationEach tool invents its own auth schemeStandard OAuth 2.1 + PKCE across all servers
Multi‑server orchestrationManual aggregation, connection jugglingUnified abstraction with routing and merging

Practical impact: A single MCP Client implementation (e.g., a LangGraph agent or a Claude Desktop host) can connect to hundreds of MCP Servers—an internal CRM API, a weather service, a code interpreter—without rewriting integration code. The client discovers what each server offers at runtime and adapts accordingly.

MCP Ecosystem Overview​

The Model Context Protocol defines a clean separation of responsibilities between three parties:

  • Host – The AI application running the agent (Claude Desktop, Cursor, or a custom LangGraph system). A host runs one or more MCP Clients.
  • Client – The protocol implementation inside the host that maintains a dedicated connection to a single MCP Server. Each client connects directly to one server.
  • Server – The capability provider. It exposes tools (executable actions), resources (read‑only data identified by URIs), and prompts (reusable templates for LLM interactions).

Client‑side capabilities (as of MCP 2025‑06‑18) include:

  • Sampling – Servers can request LLM completions from clients during tool execution, delegating AI reasoning to the client.
  • Elicitation – Servers can request structured user input with validation schemas, enabling interactive workflows.
  • Notifications – Real‑time updates for resource changes and progress.

MCP Client Responsibilities​

ResponsibilityDescriptionWhy It Matters
Server connectionEstablish and maintain a connection (stdio or Streamable HTTP) to an MCP Server.Without a connection, no capabilities can be consumed.
Capability discoveryCall initialize, then tools/list, resources/list, and prompts/list to discover available capabilities.Enables runtime adaptivity—no hardcoded tool names.
Tool invocationTranslate agent decisions into tools/call JSON‑RPC requests and parse responses.The agent can execute actions without knowing underlying API details.
Resource retrievalFetch resources via resources/read using URI templates.Provides read‑only contextual data (files, logs, database records).
Prompt accessRetrieve prompt templates via prompts/get with argument substitution.Centralises reusable interaction patterns.
AuthenticationObtain OAuth 2.1 tokens (with PKCE) and attach them to requests.Secures access to protected servers.
Error handlingParse JSON‑RPC errors, retry transient failures, and surface actionable errors to the agent.Prevents silent failures and enables graceful degradation.
ObservabilityEmit traces, logs, and metrics for every client operation.Debugging and performance monitoring.

MCP Client Lifecycle​

The MCP specification defines a rigorous lifecycle for client‑server connections that ensures proper capability negotiation and state management.

Lifecycle Phases​

1. Initialization Phase​

The initialization phase MUST be the first interaction between client and server. During this phase, client and server establish protocol version compatibility, exchange and negotiate capabilities, and share implementation details.

The client sends an initialize request containing:

  • The protocol version it supports (this SHOULD be the latest version supported by the client)
  • Client capabilities (sampling, elicitation, roots, tasks)
  • Client implementation information (name, version, optional metadata)

If the server supports the requested protocol version, it responds with the same version. Otherwise, it responds with another protocol version it supports (preferably the latest). If the client does not support the version in the server’s response, it SHOULD disconnect.

Important constraints:

  • The client SHOULD NOT send requests other than pings before the server has responded to the initialize request.
  • The server SHOULD NOT send requests other than pings and logging before receiving the notifications/initialized notification.

After successful initialization, the client MUST send an initialized notification to indicate it is ready to begin normal operations.

2. Discovery Phase​

Once initialised, the client discovers server capabilities:

  • tools/list – Returns all tool names, descriptions, and input/output JSON Schemas
  • resources/list – Returns resource URIs (e.g., file:///logs/{date}) and metadata
  • prompts/list – Returns prompt names, descriptions, and argument schemas

The official MCP specification requires specific notification methods (notifications/tools/list_changed, notifications/resources/list_changed) when capabilities change. This is not a matter of preference; it is a requirement per the MCP specification.

3. Operation Phase​

Normal protocol communication: the client invokes tools, reads resources, and gets prompts as needed. The client may also register to receive notifications for resource changes.

4. Shutdown Phase​

Graceful termination of the connection. The client SHOULD cleanly disconnect, and the server should release any acquired resources.

MCP Client Architecture​

Component Descriptions​

ComponentResponsibility
Connection ManagerEstablishes and maintains connections to MCP Servers (stdio or Streamable HTTP). Supports multiple concurrent connections.
Capability Discovery ModuleCalls tools/list, resources/list, and prompts/list. Caches results to avoid repeated queries. Subscribes to change notifications.
Tool Invocation EngineTranslates agent requests into tools/call JSON‑RPC messages. Validates input parameters against schemas. Handles retries and timeouts.
Resource Access LayerFetches resources via resources/read using URI templates. Supports parameterised URIs.
Prompt Access LayerRetrieves prompt templates with argument substitution.
Authentication ModuleManages OAuth 2.1 tokens (obtain, refresh, attach). Handles PKCE flows.
Observability ModuleEmits OpenTelemetry traces, logs, and metrics for all operations.
Capability CacheStores discovered tool/resource/prompt schemas to reduce network round trips. Invalidated on change notifications.

MCP Capability Discovery​

Tool Discovery​

MCP supports dynamic tool discovery, allowing clients to start with a small core set and load additional tools on demand. The client calls tools/list to retrieve:

{
  "name": "get_order",
  "description": "Retrieve order details by order ID",
  "inputSchema": {
    "type": "object",
    "properties": {
      "order_id": { "type": "string" }
    },
    "required": ["order_id"]
  }
}

Discovery considerations:

  • Some servers register their full tool catalog upfront; others support on‑demand loading.
  • The client should cache discovered capabilities and subscribe to notifications/tools/list_changed to invalidate the cache when tools change.
  • For multi‑server clients, tools must be namespaced to avoid collisions (e.g., weather:get_forecast, orders:get_order).

Resource Discovery​

Resources are identified by URI templates. Example:

  • file:///logs/{date} – Returns logs for a specific date
  • db:///orders/{id} – Returns order data from a database

Resource consumption workflow:

  1. Client calls resources/list – returns available resource URIs and descriptions.
  2. Client calls resources/read with a concrete URI – returns content (text, JSON, or binary data) and MIME type.
  3. Client can subscribe to notifications/resources/updated to be notified of changes.

Prompt Discovery​

Prompts are parameterised templates for consistent LLM interactions.

Example prompt registration:

{
  "name": "analyze_security_incident",
  "description": "Analyse a security incident report",
  "arguments": [
    { "name": "severity", "description": "Severity level", "required": true }
  ]
}

Consumption workflow:

  1. Client calls prompts/list – returns available prompts.
  2. Client calls prompts/get with { "name": "analyze_security_incident", "arguments": { "severity": "high" } } – returns a fully rendered prompt string.
  3. Client passes the prompt to an LLM.

MCP Connection Models​

Local MCP Server Connections (stdio)​

For local servers (e.g., Claude Desktop, VS Code extensions), the client launches the server as a subprocess and communicates via standard input/output.

Characteristics:

  • Inherently local and secure—no network exposure.
  • Messages are newline‑delimited JSON‑RPC over stdin/stdout.
  • The client is responsible for process lifecycle management (start, monitor, kill).
  • No authentication required (trust is by process isolation).

Use case: Personal developer tools, file system access, local database queries.

Remote MCP Server Connections (Streamable HTTP)​

For remote servers, the MCP specification has deprecated HTTP+SSE in favour of Streamable HTTP (as of the March 2025 specification update).

Characteristics:

  • The server runs as an independent process accessible over HTTP.
  • POST requests for JSON‑RPC, GET with SSE for streaming.
  • Requires authentication (OAuth 2.1 with PKCE is mandatory).
  • Stateless scaling; each request can be handled by any instance.

Use case: Multi‑tenant enterprise deployments, cloud‑native services, public APIs.

Implementation note: HTTP implementations must implement proper authentication mechanisms, with OAuth 2.1 being the specification.

Multi‑Server Connections​

A single MCP Client can connect to multiple MCP Servers simultaneously. However, each client maintains a dedicated connection to a single server. For multiple servers, the host must run multiple clients, each managing its own connection.

Practical pattern: The agent‑facing abstraction aggregates multiple clients. The agent requests a tool by name; the routing layer selects the appropriate client.

Federated MCP Architectures​

For large‑scale deployments, gateways and federation layers aggregate multiple MCP Servers behind a single endpoint.

Virtual MCP (agentgateway) enables clients to access tools from multiple MCP servers through a single endpoint and MCP connection. This approach uses label selectors to multiplex traffic across backend servers.

ContextForge MCP Gateway provides a feature‑rich gateway and proxy that federates MCP and REST services, unifying discovery, auth, rate‑limiting, observability, virtual servers, and multi‑transport protocols into one clean endpoint for AI clients.

MCP Client Security​

Authentication and authorisation are core to the MCP design and cannot be an afterthought. AI agents can move money, change account state, approve refunds, or deploy builds—you need to know who is calling and what they are authorised to do.

OAuth 2.1 with PKCE – Mandatory for Remote Servers​

MCP now relies on OAuth 2.1, the same protocol that secures much of the modern web. PKCE (Proof Key for Code Exchange) protects the authorisation code exchange without requiring a client secret and is required by the MCP spec.

Authentication flow:

  1. Client discovers authorisation server metadata (RFC 8414) and protected resource metadata (RFC 9728).
  2. Client initiates OAuth 2.1 code flow with PKCE.
  3. User authenticates via browser (SSO, Google, etc.).
  4. Client exchanges code for access token (short‑lived, minutes not hours).
  5. Client attaches token to every MCP request.
  6. Token is validated per request—not just at session establishment.

Per‑request validation is critical. The spec mandates that every request crossing the boundary between client and server must be authenticated and authorised.

Auth Mechanisms Comparison​

MechanismWhen to UseMCP Compliance
OAuth 2.1 + PKCERemote servers, multi‑tenant, user‑specific accessRequired by specification
Static API keysSystem‑level access, internal tools onlyPermitted but not recommended
No authenticationLocal stdio servers onlyAcceptable (trust by process isolation)

Security Checklist​

  • Use OAuth 2.1 + PKCE for all remote server connections.
  • Never hardcode credentials—use environment variables and secret stores.
  • Validate JWT tokens—signature, issuer, audience, expiry, and required scope.
  • Implement least privilege scopes – different tools require different scopes.
  • Rotate refresh tokens on each use.
  • Log all access attempts – success and failure.
  • Respect token expiry – never reuse expired tokens.

MCP Client Performance Optimization​

Connection Pooling​

Connection pooling eliminates the setup cost of establishing fresh connections for each request. 80% of performance gains come from connection pooling—and it takes only about 10 minutes to implement.

Best practice: Maintain a set of ready‑to‑use connections; requests reuse what’s already open rather than starting from scratch each time.

The mcp-pool Python package provides an async connection pool for MCP client sessions, keeping sessions warm and reusing them across requests.

Capability Caching​

Capability discovery (tools/list, resources/list) should be cached to avoid repeated network round trips. Cache invalidation occurs via change notifications (notifications/tools/list_changed).

Tool Result Caching​

For idempotent, read‑only tool calls, cache results with a short TTL (e.g., 30 seconds). Reduces load on backend servers and lowers latency.

Parallel Execution​

When a plan requires multiple independent tool calls, execute them concurrently using asyncio.gather or Promise.all. The P95 latency drops from sum of durations to the maximum duration.

Performance Checklist​

  • Implement connection pooling (mcp-pool or custom httpx client reuse)
  • Cache capability discovery results
  • Cache frequent, idempotent tool results
  • Use concurrent execution for independent tool calls
  • Set appropriate timeouts per tool (not global)

MCP Client Observability​

MCP observability is crucial for debugging, performance monitoring, and capacity planning. Silent failures can occur where a tool invocation does not return valid data but no clear error is raised.

OpenTelemetry Integration​

Instrument your MCP client with OpenTelemetry to capture:

  • Traces – Complete request flow from tool invocation to response, including all downstream calls.
  • Metrics – Latency histograms, error rates, request counts.
  • Structured logs – Timestamped, queryable logs with correlation IDs.

Semantic conventions for MCP define attributes like mcp.client.session.duration and mcp.client.operation.duration.

What to Observe​

OperationAttributes to Capture
Tool invocationtool_name, duration_ms, success, error_type, client_id
Capability discoveryoperation (tools/list, resources/list), result_count
Authenticationtoken_obtain, token_refresh, scope_requested
Connection managementserver_url, transport_type, connect_duration_ms

Monitoring Dashboard (Grafana or Datadog)​

Track:

  • Tool success rate (target >99%)
  • P95 and P99 latency per tool
  • Connection pool utilisation
  • Rate of change notifications
  • Authentication failures

Platforms like Heimdall provide comprehensive observability for MCP server‑client systems, built on OpenTelemetry standards. Signoz also offers detailed guidance on instrumenting MCP stacks for telemetry collection.

MCP Client Error Handling​

MCP uses JSON‑RPC 2.0 error format for all error conditions. Clients must handle errors at both the protocol level and the tool execution level.

Error Categories and Strategies​

Error CategoryExamplesHandling Strategy
Protocol errorsInvalid JSON, method not found, malformed requestReject; log; notify agent; do not retry
Connection errorsNetwork timeout, server unreachableRetry with exponential backoff (3 attempts max)
Authentication errorsExpired token, insufficient scopeRefresh token; if fails, re‑authenticate via OAuth flow
Tool execution errorsInvalid parameters, backend failureParse error; surface structured error to agent for replanning
Timeout errorsTool execution exceeds configured timeoutCancel call; retry (if idempotent); notify agent

Idempotency​

For tools that modify state, require an idempotency_key parameter. On retry, the server can detect duplicate keys and return the original result without executing the operation again.

Fallback Strategy​

When a tool fails after all retries:

  1. Log the failure with full context.
  2. Notify the agent (e.g., return { "error": "Tool unavailable" }).
  3. The agent may replan (choose an alternative tool) or ask the user.
FrameworkMCP Integration ModelMCP CapabilitiesBest Use Case
LangGraphDirect via MCPClient wrapper; tools become graph nodesTools, resources (via read nodes), promptsComplex, stateful workflows requiring tool orchestration
CrewAIVia crewai-tools library; MCP tools as CrewAI ToolsTools onlyRole‑based multi‑agent systems with linear tool use
AutoGenVia mcp_tools module; convert MCP tools to AutoGen function toolsTools onlyConversational multi‑agent systems
OpenAI Agents SDKVia HostedMCPTool; MCP servers as OpenAI‑compatible function callsTools onlySingle‑turn agentic apps with OpenAI stack
Semantic KernelVia plugin integration; MCP tools as Kernel FunctionsTools, resourcesEnterprise .NET/Java systems

Integration Patterns​

Most frameworks follow a common pattern:

  1. Discover – Client connects to MCP server, calls tools/list.
  2. Convert – Tool schema transformed into framework‑specific function definition.
  3. Register – Converted tool added to framework’s tool registry.
  4. Invoke – When agent selects the tool, framework calls MCP client’s call_tool.

LangGraph + MCP​

LangGraph can embed MCP tools into agentic workflows, with MCP tools becoming nodes in the state graph. The official TypeScript SDK includes a Client class that connects to MCP servers and discovers available tools.

CrewAI + MCP​

Connect CrewAI agents to MCP servers using the crewai-tools library. The tools library converts MCP server capabilities into native CrewAI tools, allowing role‑based agents to discover and invoke MCP‑exposed functions seamlessly.

MCP Client Deployment Models​

Embedded Clients​

The MCP client runs inside the same process as the AI application. Simplest model; suitable for local development and single‑tenant deployments.

Use case: LangGraph agent with an embedded client connecting to 1–3 local MCP servers.

Standalone Clients​

The client runs as a separate service, exposing an API to agents. Enables centralised management, monitoring, and authentication.

Use case: Large‑scale deployments with many agent instances sharing the same MCP infrastructure.

Gateway Clients​

The gateway (ContextForge, Solo Enterprise AgentGateway) acts as a reverse proxy and federation layer, presenting a single MCP endpoint to clients while routing to multiple backend servers.

Use case: Enterprise environments with dozens of MCP servers; multi‑tenant deployments.

Best Practices​

  1. Cache capabilities – Use tools/list responses for the entire session unless a change notification arrives. Reduces network overhead.

  2. Monitor tool latency – Track P95 and P99. Slow tools are often the bottleneck in agent workflows.

  3. Use connection pooling – For remote servers, maintain a pool of HTTP connections. 80% of performance improvements come from connection pooling—implement it first.

  4. Validate schemas before invocation – Check that required parameters are present and of the correct type before calling tools/call.

  5. Separate authentication concerns – Delegate OAuth token management to a dedicated module. Do not mix auth logic with tool invocation.

  6. Implement retries with exponential backoff – For transient failures (timeout, 5xx). Do not retry 4xx client errors.

  7. Set per‑tool timeouts – A 10ms database query and a 30‑second LLM call need different timeouts.

  8. Structured error handling – Parse JSON‑RPC errors, extract actionable information for the agent, and decide whether to retry, replan, or escalate.

  9. Instrument from day one – Add OpenTelemetry spans, logs, and metrics before writing production code. Retroactive instrumentation is painful.

  10. Handle change notifications – Subscribe to tools/list_changed, resources/list_changed, and resources/updated notifications to keep capabilities fresh without polling.

  11. Design for offline scenarios – Cache tool results and resource contents where permitted, allowing the client to function when servers are temporarily unreachable.

  12. Version your client – The MCP protocol supports version negotiation. Ensure your client can negotiate down to earlier protocol versions when connecting to older servers.

Common MCP Client Mistakes​

MistakeConsequenceFix
Hardcoding tool metadataChanges require re‑deploying the client.Always call tools/list at runtime.
Ignoring capability discoveryClient attempts to use tools that don’t exist.Validate tool names against discovered capabilities.
Poor error handlingSilent failures, agent proceeds with stale or incorrect data.Parse JSON‑RPC errors, surface actionable errors to agent.
Missing observabilityCannot debug why a tool call failed or why latency spiked.Add OpenTelemetry instrumentation before deploying to production.
Excessive server connectionsOpening a fresh connection per request kills performance.Use connection pooling and session reuse.
No connection retryTransient network blip breaks the entire session.Implement exponential backoff for connection establishment.
Ignoring change notificationsClient uses stale tool schemas after server update.Subscribe to tools/list_changed and invalidate cache.
Single‑threaded executionIndependent tool calls execute sequentially, adding latency.Use concurrent execution for independent operations.
Missing idempotencyRetry after timeout may execute the same operation twice.Require idempotency_key for state‑changing tools.

Case Study: Enterprise Research Agent with Multi‑Server MCP Client​

Scenario: A financial services company deploys an AI research agent for analysts. The agent needs to query an internal CRM API (customer data), a market data API (real‑time prices), a document store (research reports), and a team calendar (availability).

MCP Client Architecture​

Connected Servers and Tools​

ServerTools / ResourcesAuthenticationHost
CRMget_customer, search_contactsOAuth 2.1 + PKCERemote (internal HTTPS)
Market Dataget_price, get_historicalAPI key (short‑lived)Remote (third‑party)
Document Storedocs://research/{id}OAuth 2.1 + PKCERemote (S3 + proxy)
Calendarget_availability, book_meetingOAuth 2.1 + PKCE (user consent)Remote (Google Calendar)

Tool Discovery Workflow​

Upon session start:

  1. Client connects to all four servers.
  2. Client calls tools/list on CRM, Market Data, and Calendar servers.
  3. Client calls resources/list on Document server.
  4. Results are cached with 30‑minute TTL.
  5. Client subscribes to notifications/tools/list_changed for each server.

Agent Query Example​

Analyst: “Get customer Acme Corp’s latest order, check current stock price, and find the research report from last quarter. Then summarise.”

Client execution:

  1. Router maps “get customer” → CRM server → get_customer(name="Acme Corp").
  2. Router maps “check stock price” → Market Data server → get_price(symbol="ACME").
  3. Router maps “find research report” → Document server → resources/read(uri="docs://research/2026-Q1-Acme").
  4. Results aggregated, passed to agent’s LLM for synthesis.

Monitoring Strategy​

  • Metrics – Tool success rate, P95 latency per server, connection pool utilisation, cache hit rate.
  • Traces – Full distributed trace across all four servers for each analyst query.
  • Alerts – Market Data server failure > 5% over 1 minute; token expiry nearing (< 10 minutes left).

Optimization Outcomes​

After implementing connection pooling, capability caching, and parallel execution:

  • P95 query latency reduced from 8.2s to 2.4s.
  • Tool success rate increased from 93% to 98.7%.
  • Cache hit rate for capabilities: 94%.
  • Cost reduction of ~35% due to reduced token usage (cached tool schemas).

FAQ​

1. What is the difference between an MCP Client and an MCP Server?
An MCP Client initiates connections, discovers capabilities, and consumes tools, resources, and prompts. An MCP Server exposes those capabilities and responds to client requests. The client is the consumer; the server is the provider.

2. Can one client connect to multiple MCP Servers?
Each MCP Client maintains a dedicated connection to a single server. For multiple servers, the host must run multiple clients, each managing its own connection. Federation gateways (e.g., agentgateway, ContextForge) provide a single endpoint that aggregates multiple servers.

3. How do MCP Clients discover tools?
By calling tools/list after successful initialisation. The client can also subscribe to notifications/tools/list_changed to be notified when the server’s tool set changes.

4. What transport should I use for an MCP Client?
Use stdio for local servers (Claude Desktop, CLI tools, VS Code). Use Streamable HTTP for remote servers. Legacy HTTP+SSE is deprecated and should be avoided for new implementations.

5. Is authentication mandatory for MCP Clients?
For stdio (local) connections, no authentication is required—trust is enforced by process isolation. For remote HTTP connections, OAuth 2.1 with PKCE is mandatory per the MCP specification.

6. How do MCP Clients handle token refresh?
The client should monitor token expiry and proactively refresh the token before it expires. The OAuth 2.1 refresh token flow is used; refresh tokens SHOULD rotate on each use.

7. Should MCP Clients cache tool discovery results?
Yes. Capabilities should be cached for the session duration and invalidated only when a tools/list_changed notification arrives. This dramatically reduces network round trips.

8. How do I handle MCP server failures?
Implement retries with exponential backoff (max 3 attempts). If all retries fail, surface an actionable error to the agent. The agent may choose an alternative tool or escalate to a human.

9. Can an MCP Client invoke tools in parallel?
Yes. For independent tools (no shared state, no order dependencies), the client can execute tools/call requests concurrently. Use asyncio.gather in Python or Promise.all in TypeScript.

10. What is the role of sampling in MCP Clients?
Sampling allows an MCP Server to request LLM completions from the client during tool execution. This enables servers to delegate AI reasoning to the client, which controls which LLM is used and how requests are made.

11. How does MCP fit into existing agent frameworks (LangGraph, CrewAI)?
Most modern agent frameworks include MCP integration layers that convert MCP tools into native framework tools. This allows agents to discover and call MCP‑exposed capabilities without modifying the agent’s core logic.

12. What is federated MCP?
Federated MCP aggregates multiple MCP Servers behind a single gateway endpoint. Clients connect to the gateway, which routes requests to the appropriate backend server based on tool names, resource URIs, or namespace prefixes. This simplifies multi‑server orchestration.

13. How do I debug MCP Client connectivity issues?
Enable debug logging in the client SDK (e.g., DEBUG=mcp* in Node.js). Capture OpenTelemetry traces. Use test clients (e.g., locus test tool) to validate server connectivity before integrating with agents.

14. What is the typical latency for MCP Client operations?
The client itself adds minimal overhead (JSON‑RPC parsing, validation, dispatching)—typically < 1ms. Most latency comes from network round trips and server processing. Connection pooling reduces per‑request latency by eliminating connection establishment overhead.

15. Can an MCP Client work offline?
Partially. Cached tool schemas and resources remain available, but any tools/call or resources/read that requires real‑time data will fail. Design for eventual consistency where possible.

16. How does MCP handle large resource payloads?
The protocol supports streaming responses (via Streamable HTTP). Implement pagination or truncation in resource handlers for very large responses (e.g., log files exceeding context limits).

17. What SDK should I use for building an MCP Client?
TypeScript SDK (official @modelcontextprotocol/sdk) – reference implementation, most feature‑complete. FastMCP (Python) – Pythonic, powers ~70% of MCP servers, includes client support. Java SDK – Enterprise‑grade, good for JVM‑based agents. Semantic Kernel – .NET/Java, enterprise integration.

18. How do I test an MCP Client without a real server?
Mock the MCP server using the same JSON‑RPC interface. The official SDKs include test utilities for simulating server responses. Tools like mcp-jest provide protocol compliance testing.

19. What is elicitation and how does the client handle it?
Elicitation is a server‑driven request for structured user input (e.g., GitHub username, configuration preference). The client presents a form defined by JSON Schema, collects the user’s response, and returns it to the server. Three outcomes are possible: Accept, Decline, or Cancel.

20. What are the biggest security risks for MCP Clients?
Credential leakage (logging tokens), token replay attacks, man‑in‑the‑middle on HTTP connections (use TLS), and insufficient scope validation. Mitigate by using OAuth 2.1 + PKCE, validating tokens on every request, never logging tokens, and enforcing TLS for all remote connections.

Continue Your Journey​

Now that you understand how MCP Clients connect agents to capability providers, explore the rest of the MCP ecosystem:

  • MCP Basics – MCP Introduction (protocol fundamentals and architecture)
  • MCP Servers – MCP Server (building and deploying capability providers)
  • MCP Tools – MCP Tools (deep dive on tool implementation)
  • MCP Security – MCP Security (comprehensive authentication and authorisation)
  • Agent Frameworks – LangGraph Guide (integrating MCP clients with graph agents)
  • Agent Workflows – Agent Workflows (orchestrating multi‑tool execution)

Or return to the Agent Learning Path to see where MCP fits in your overall agent engineering roadmap.

This article is part of the AgentDevPro Production Agent Engineering Handbook. Updated for Q2 2026.