Repository navigation
Official Adapter Functions for LLM Providers in MCP Python SDK #235
Description
Is your feature request related to a problem? Please describe.
Currently, when integrating MCP tools with various LLM providers, developers must implement their own adapter functions to convert MCP tool schemas to the target provider’s format. This repetitive and manual process increases development time and introduces potential inconsistencies and errors across different implementations. For example, while one developer may create a conversion adapter for the Gemini tool, another might duplicate the effort in their own project, leading to fragmented solutions and maintenance challenges.
Describe the solution you'd like
I propose that the official Python SDK for Model Context Server includes a suite of built-in adapter functions to facilitate seamless conversion from MCP tool schemas to those required by popular LLM providers (e.g., Gemini, GPT-4, etc.). By providing these adapters, the SDK would:
- Standardize the conversion process across projects.
- Reduce development time and prevent duplication of code.
- Enhance consistency and reliability when integrating with multiple LLM providers.
- Allow developers to focus on higher-level integration concerns rather than schema translation.
Describe alternatives you've considered
One alternative is for each developer to write their own adapter functions, as demonstrated by the sample code below. However, this approach is inefficient and can lead to fragmented and non-standardized implementations. Another alternative would be to provide partial documentation and code snippets as guidance, but without official support, developers might still encounter integration challenges and maintenance issues.
Additional context
The inclusion of official adapters would not only streamline the integration process for MCP clients but also foster a more robust and unified ecosystem. The sample code below illustrates how a conversion function from an MCP tool to a Gemini tool might look, serving as a basis for the kind of functionality that should be officially supported:
from google.genai import types as genai_types
from mcp import types as mcp_types
def to_gemini_tool(mcp_tool: mcp_types.Tool) -> genai_types.Tool:
"""
Converts an MCP tool schema to a Gemini tool.
Args:
mcp_tool: The MCP tool containing name, description, and input schema.
Returns:
A Gemini tool with the appropriate function declaration.
"""
function_declaration = to_gemini_function_declarations(mcp_tool)
return genai_types.Tool(function_declarations=[function_declaration])
def to_gemini_function_declarations(
mcp_tool: mcp_types.Tool,
) -> genai_types.FunctionDeclarationDict:
required_params: list[str] = mcp_tool.inputSchema.get("required", [])
properties = {}
for key, value in mcp_tool.inputSchema.get("properties", {}).items():
schema_dict = {
"type": value.get("type", "STRING").upper(),
"description": value.get("description", ""),
}
properties[key] = genai_types.SchemaDict(**schema_dict)
function_declaration = genai_types.FunctionDeclarationDict(
name=mcp_tool.name,
description=mcp_tool.description,
parameters=genai_types.SchemaDict(
type="OBJECT",
properties=properties,
required=required_params,
),
)
return function_declaration
Activity
hasani114 commentedon Mar 1, 2025
I think this would be great. I’m using LibreChat and the support for MCP is inconsistent. If there was official support it would make it easy to implement this for various providers.
wtfzambo commentedon Mar 12, 2025
I concur. I was playing locally, trying to make a simple MCP Client with OpenAI SDK, and being relatively new to LLM tool calling, I wasn't aware of the different quirks between providers. So while OpenAI and Ollama work seamlessly, Gemini screams at you in certain cases (for instance, it really doesn't like optional parameters).
Took me a while to figure out what is was because the error message is simply
INVALID REQUEST🤦.bldev2473 commentedon Apr 18, 2025
Hi there, wtfzambo. Hmm, is it impossible to map parameter defaults automatically when using Gemini?
jcamatta commentedon Apr 29, 2025
I think that as soon MCP becomes widely adopted, those LLM providers will implement their own adapters. I think this is better for maintenance since when they will make some change to their APIs, they will update at the same time theirs adapters.
wtfzambo commentedon Apr 29, 2025
If not impossible, then very hard, because Gemini API accepts only a small subset of JSON schema, whereas MCPs can span the whole range.
The only Host I found that can avoid these issues is Cline, but that's because it adds the tools payload directly to the
messagefield, alongside the user query, rather than the separate, dedicatedtoolsfield. At least last time I checked (and if I understood correctly).felixweinberger commentedon Oct 7, 2025
I'm not sure we want to take on the burden of maintaining adapters to third party SDKs - those SDKs (like Gemini) will be much better placed to provide these adapters as part of their SDKs to integrate with MCP.
However, marking this important for us to ensure the Python SDK is set up such that creating such adapters would be easy - maybe with an example in documentation.
feat: add LLM provider adapter documentation and examples
dgenio commentedon Feb 28, 2026
Hi — I have an open PR (#1709) addressing this with documentation and a runnable example, following @felixweinberger's guidance above about providing docs/examples rather than official adapter utilities.
The PR needs a rebase and some cleanup (README insertion is too large, stale naming from the FastMCP → MCPServer rename, minor code style fixes), but the core content is ready — a comprehensive
docs/llm-adapters.mdguide covering Gemini, OpenAI, and Claude adapters, plus a working example inexamples/snippets/clients/.I'll be rebasing it shortly. Just wanted to confirm this direction still makes sense before I put in the work. Thanks!
MukundaKatta commentedon May 10, 2026
Strong agree that re-implementing the schema conversion per-app is the wrong abstraction layer. The conversions are mechanical and the bugs show up at the field-edge cases (Anthropic wants tools.input_schema, OpenAI wants function.parameters, Gemini wants different again).
Two ways to land this: a per-provider adapter module (one file each, easy to maintain) or a generic JSON schema to provider-shape transformer with per-provider overrides for the field names that differ.
The adapter-per-provider path is cleaner because each one can also handle the response shape (tool_use vs tool_call vs functionCall), not just the schema.