The MCP server built across this course works identically regardless of which client connects to it, that is the protocol’s core value. This lesson wires it into three representative clients: Claude, ChatGPT/OpenAI’s Agents SDK, and the open-source LangGraph framework, and closes with an important caveat: identical protocol conformance across clients does not mean identical behavior, since tool selection and argument construction happen in the model’s own reasoning, which the protocol deliberately does not standardize.
Claude via the Claude Agent SDK
from claude_agent_sdk import ClaudeAgent, MCPServerConfig
agent = ClaudeAgent(
model="claude-sonnet-5",
mcp_servers=[
MCPServerConfig(
name="knowledge-base",
url="https://mcp.acmecorp.internal/kb/v2",
headers={"Authorization": f"Bearer {oauth_token}"}, # Module 4
),
],
)
response = await agent.run("Find our refund policy for enterprise customers and summarize it.")
# Claude discovers kb_query/v2 via tools/list, calls it, and reasons over the resultClaude Desktop and Claude Code use the same underlying mechanism through a local configuration file for stdio-based servers, or the same remote URL configuration for Streamable HTTP servers.
ChatGPT / OpenAI Agents SDK Connector
from openai import OpenAI
from openai.types.beta.threads import mcp_tool
client = OpenAI()
response = client.responses.create(
model="gpt-5.1",
input="Find our refund policy for enterprise customers and summarize it.",
tools=[{
"type": "mcp",
"server_label": "knowledge-base",
"server_url": "https://mcp.acmecorp.internal/kb/v2",
"headers": {"Authorization": f"Bearer {oauth_token}"},
}],
)LangGraph
from langgraph.prebuilt import create_react_agent
from langchain_mcp_adapters.client import MultiServerMCPClient
mcp_client = MultiServerMCPClient({
"knowledge-base": {
"url": "https://mcp.acmecorp.internal/kb/v2",
"transport": "streamable_http",
"headers": {"Authorization": f"Bearer {oauth_token}"},
},
})
tools = await mcp_client.get_tools() # tools/list, wrapped as LangChain tool objects
agent = create_react_agent(model="claude-sonnet-5", tools=tools)
result = await agent.ainvoke({"messages": [("user", "Find our refund policy for enterprise customers.")]})flowchart TB
Server["Enterprise MCP Server\n(knowledge-base, v2)"]
Server -->|"same tools/list,\ntools/call protocol"| Claude["Claude Agent SDK"]
Server -->|"same protocol"| GPT["OpenAI Agents SDK / ChatGPT"]
Server -->|"same protocol,\nvia langchain-mcp-adapters"| LG["LangGraph"]
Claude --> App1["Support Agent App"]
GPT --> App2["Sales Assistant App"]
LG --> App3["Internal Ops Agent"]
style Server fill:#f0fdf9,stroke:#0D9488,color:#0F172A
style Claude fill:#EEF0F7,stroke:#6366F1,color:#0F172A
style GPT fill:#EEF0F7,stroke:#6366F1,color:#0F172A
style LG fill:#EEF0F7,stroke:#6366F1,color:#0F172AOne server, three completely independent applications, built on three different frameworks by three different teams, all consuming the identical tool catalog with zero changes to the server itself.
What the Protocol Standardizes, and What It Deliberately Does Not
It is worth being precise about the boundary here, since it is easy to over-claim what “same protocol” buys you. MCP standardizes tool discovery (the exact schema every client receives via tools/list) and tool invocation (the exact JSON-RPC shape of a tools/call request and response). It says nothing about, and is not intended to standardize, how a model decides which tool to call for a given query, or how it constructs the arguments once it has decided. Those are properties of the underlying model’s own reasoning and, layered on top of that, whatever system prompt, context window management, and tool-result formatting choices the surrounding framework makes.
This means two teams connecting the identical server to two different models (or the same model through two different frameworks) can observe genuinely different tool-selection behavior for the same user query, one might call kb_query with a broad search term while another decomposes the request into two narrower calls, without either client violating the protocol in any way. This is not a bug in MCP, and it is not something a schema fix on the server side can resolve, it is simply a reflection of the fact that MCP intentionally standardizes the wiring between agent and tool, not the reasoning that decides how to use that wiring. Lesson 26’s model-in-the-loop evals exist specifically to measure this behavior empirically for whichever client and model combination a team actually deploys, rather than assuming identical protocol conformance implies identical outcomes.
The next lesson extends this to open-weight models accessed through tool-calling harnesses rather than a vendor SDK, where this same distinction, protocol conformance versus model reasoning quality, becomes an explicit evaluation question rather than something a vendor SDK absorbs on your behalf.