Fix naming of MCP Client & Server #2496
Description
Description
Currently Pydantic-AI names the object which maintains a connection to an MCP server as MCPServer. This is backwards from how they are referred to elsewhere, especially the official MCP SDK, which should be considered the authoritative source of truth. Aside from being backwards from the official SDK, it's also at odds with industry standard naming conventions. Basically PydanticAI is naming MCP servers & clients backwards from everything else.
server_params = StdioServerParameters(
command="uv", # Using uv to run the server
args=["run", "server", "fastmcp_quickstart", "stdio"], # We're already in snippets dir
env={"UV_INDEX": os.environ.get("UV_INDEX", "")},
)
async with stdio_client(server_params) as (read, write):
...server = MCPServerStdio(
'deno',
args=[
'run',
'-N',
'-R=node_modules',
'-W=node_modules',
'--node-modules-dir=auto',
'jsr:@pydantic/mcp-run-python',
'stdio',
]
)From what I can see, this came about as a misunderstanding of the terminology found in use:
#1100 (comment)
The misunderstanding appears to be due to the fact that people call the server parameters "server". This is true, but the representation of the client connected to the server is not called "server". This is especially clear and explicitly demonstrated in the official SDK usage I referenced above, where the server parameters are called StdioServerParameters, and they are passed to stdio_client.
Basically the request is to rename MCPServer (and all subclasses) to MCPClient.
I know this would be a breaking change, but I view this as a fundamental issue that is at conflict with official terminology, and will cause confusion, and should be fixed prior to the V1 release.
References
Kotlin SDK
/**
* An MCP client on top of a pluggable transport.
*
* The client automatically performs the initialization handshake with the server when [connect] is called.
* After initialization, [serverCapabilities] and [serverVersion] provide details about the connected server.
*
* You can extend this class with custom request/notification/result types if needed.
*
* @param clientInfo Information about the client implementation (name, version).
* @param options Configuration options for this client.
*/
public open class Client(private val clientInfo: Implementation, options: ClientOptions = ClientOptions()) :
Typescript SDK
/**
* An MCP client on top of a pluggable transport.
*
* The client will automatically begin the initialization flow with the server when connect() is called.
*
* To use with custom types, extend the base Request/Notification/Result types and pass them as type parameters:
*
*/
export class Client<
RequestT extends Request = Request,
NotificationT extends Notification = Notification,
ResultT extends Result = Result,
>
Langchain
class MultiServerMCPClient:
"""Client for connecting to multiple MCP servers.
Semantic kernel
They sidestep the issue entirely and just call it a "plugin".
class MCPStdioPlugin(MCPPluginBase):
"""MCP stdio server configuration."""
Llama index
class BasicMCPClient(ClientSession):
"""
Basic MCP client that can be used to connect to an MCP server.
This is useful for connecting to any MCP server.
HTTPX
https://github.com/encode/httpx/blob/89102021fcb44f6c3fab6304e5f951692723c908/httpx/_client.py#L594
This isn't MCP, but I'm mentioning because it's industry standard naming covention for the thing which connects to a server to be called "client".
client = httpx.Client()
response = client.get('https://example.org')