As the Model Context Protocol (MCP) ecosystem matures from tech demos to production cases, different design patterns emerge. While MCP is fairly new, as an industry we’ve got plenty of experience with making functionality accessible to other programs, whether those are services or frontend clients. This post explores whether your MCP should follow an SDK-like (Software Development Kit) approach or a BFF-like (Backend For Frontend) pattern.
Understanding MCP Servers
MCP servers are lightweight adapters that bridge AI models with external systems like APIs, databases, and files. They standardize communication between AI and software, functioning much like a USB port for connecting diverse technologies.
Exploring Two Potential Approaches
The SDK-like Approach
An SDK-like approach to MCP servers offers AI systems broad access to all API capabilities. This approach allows the AI to:
- Discover and experiment with all available functionality
- Adapt to new use cases without requiring backend changes
- Find unexpected solutions by combining different API capabilities
This approach seems particularly suited to exploration and prototyping. When we’re in the early stages of AI integration or aren’t yet certain of all the ways AI might interact with our systems, an SDK-like approach could provide the flexibility needed for discovery.
From an implementation standpoint, an SDK-like MCP server might be more straightforward to build initially, creating a pass-through layer that maps closely to existing API structures. If you have an API specification, these are easy to automatically generate.
The BFF-like Approach
A BFF-like approach to MCP servers might create a more specialized interface that exposes only specific functionality and data the AI needs for designated tasks. This approach could potentially offer:
- Enhanced security through the principle of least privilege
- A more focused environment for the AI with fewer distractions
- Embedded business rules that ensure consistent enforcement
Current LLMs still struggle with larger contexts, missing relevant information. This extends to MCP servers, the larger the surface of it is, the more likely the AI won’t find the right tool for the job. By curating available functionality, a BFF-like approach creates a more streamlined interface for the AI, potentially leading to more efficient task completion and reducing the chance of the AI taking “wrong turns” in its reasoning.
Real-World Scenarios to Consider
Metrics API Example
For a system with a comprehensive metrics API:
SDK Approach: The MCP server might provide the AI with access to all available metrics, from API traffic statistics to infrastructure metrics. However, this approach comes with practical challenges. If the AI needs to fetch HTTP usage data, it might not know the exact metric name to query. This could lead to either:
- Requiring the developer to explicitly include metric names in the AI’s prompt or context
- Forcing the AI to first retrieve all available metrics, analyze them to determine which ones relate to HTTP usage, and then query the specific metrics it needs
This discovery process increases complexity and could result in less efficient interactions or even failure to accomplish the task, especially when dealing with systems that have hundreds or thousands of metrics.
BFF Approach: The MCP server might expose only specific metrics relevant to the AI’s tasks, e.g. one metric that combines HTTP status codes and API call volume. Other metrics like CPU usage aren’t available. The description can list specific examples we expect the AI to use, e.g. “amount of 4xx errors in the last 24 hours”. With this targeted interface, the AI can directly access the metrics it needs without discovery steps or additional context.
E-commerce Example
In an e-commerce context:
SDK Approach: The MCP server might offer access to the full product catalog API (including product information, pricing or discount management functions) and shopping cart functionality, with all the same capabilities as the standard API.
The descriptions are likely generic, e.g. for a product search an example like “Search for products in category foobar with a price <$100”.
BFF Approach: The MCP server only offers access access to relevant APIs, e.g. in a shopping case to view the product catalog (but not edit it) and to shopping carts of the user that is logged in
The MCP could restrict the product catalog to only show products that are currently in stock, preventing the AI from recommending unavailable items.
The MCP server might implement specific business rules. E.g. during COVID, it could enforce limiting toilet paper purchases during supply shortages. (I’m not a fan of this approach, because it means the business rules need to be re-implemented in all BFFs!)
The descriptions are very specific, e.g. for a bicycle shop, an example could be to search for e-mountainbikes for women in size L with a price below $2500 that are in stock. The description can list relevant infos, e.g. which categories are available (mountainbikes, e-mountainbikes, …).
A possible middle ground: Permission-Based Systems
Between these approaches, there might be valuable middle ground in leveraging permission systems:
If an API already incorporates robust permission systems, one might implement an SDK-like MCP server that offers broad functionality but controls access through permissions:
- The AI would see all endpoints and capabilities, but only be able to execute those it has permission to use
- Permissions could be assigned based on the AI’s role, user context, or other parameters
- Field-level whitelisting could restrict what data the AI can see within otherwise accessible resources
However, relying solely on permissions could have potential drawbacks:
- The AI still “sees” capabilities it cannot use, potentially causing confusion
- Error handling might become more complex as the AI attempts to use inaccessible functionality
- The AI might waste computational resources exploring unavailable paths
Dynamic MCP Server Generation
A more sophisticated approach might dynamically generate or adjust MCP servers based on available permissions:
- If an API endpoint is not allowed for the AI, it does not appear in the MCP server and the AI would only see and know about capabilities it can actually use
- This might prevent the AI from taking “wrong turns” by removing inaccessible options entirely
The Future: AI-Generated MCP Servers?
As AI code generation continues to advance, we might see interesting developments in how MCP servers are created. Here’s one potential future direction:
API providers might initially offer SDK-like MCP servers for exploration. Organizations could then use these comprehensive servers with AI systems during prototyping phases to understand which functionalities they actually need for specific use cases.
Once usage patterns emerge, AI code generation tools could automatically analyze these patterns and create tailored BFF-like MCP servers that include only the necessary functionality. The descriptions are enriched with examples that are frequently used and known to work well. This would combine the exploratory benefits of the SDK approach with the security and focus of the BFF approach, but with much less manual development effort.
This AI-driven approach might reduce development time for BFF-like MCP servers compared to manually creating one.
Current Generation Tools
The MCP ecosystem is already seeing significant tool development for generating SDK-like MCP servers from API specifications. There are several open source projects that either dynamically offer tools based on an API specification, or generate a static MCP server. I have played around with a few projects, but it’s early days and I can’t give a recommendation yet. Expect “early adopter” open source quality :)
There are also companies like Stainless and Speakeasy that offer SDK generation from specifications, and they are now offering the generation of MCPs, too. I haven’t tried them out yet.
My Predictions for the Future
I predict that SDK-based approaches to MCP servers are here to stay. When the ecosystem matures, they should become easy to generate from API specifications, and make them quickly accessible to companies without big investments.
However, I also believe that SDK-like MCP servers aren’t the best approach for all use cases. As organizations gain experience with AI integration and better understand their specific requirements and security concerns, we’ll likely see more tailored BFF-like MCP servers designed for specific use cases. At least with the current state of LLMs, I see a need to invest in setting the right context for the LLM. This could be done through the prompt, but the descriptions in the MCP may be the better place.
Rather than a one-size-fits-all approach, we may see organizations maintaining multiple MCP servers for different purposes: SDK-like servers for exploration and development, alongside more focused BFF-like servers for production environments with sensitive operations or strict security requirements.