At Lambda Curry, we’ve been exploring how to make e-commerce management even more powerful using AI. Specifically, we’ve been building an MCP server (Multi-Command Protocol) for Medusa — an open-source headless commerce engine — that enables natural language control over storefront workflows.
This post is a behind-the-scenes look at where we started, why we pivoted, and what’s coming next, including our use of the OpenAPI spec, our strategy for tool filtering, and our future vision for auto-generated MCP servers.
Watch the Walkthrough 👇
In this video, I share a behind-the-scenes look at our progress building a dynamic MCP server for Medusa. You’ll see a live demo, the architectural decisions we made, and where we’re headed next — including how we’re using OpenAPI specs and dynamic tool filtering to solve real challenges.
Why Medusa + MCP?
Medusa’s admin backend supports hundreds of powerful workflows — everything from product updates to order management to customer service flows. These are usually accessed via a RESTful API or through the Medusa Admin dashboard. But for non-technical users or those building novel admin UIs, we wanted to unlock a more conversational interface.
Imagine typing:
“What orders did we ship this week?”
… and having a Medusa-integrated AI answer accurately, by calling the exact endpoints needed — without writing a single query or API call.
That’s where an MCP server comes in: it maps natural language requests to Medusa’s API functionality using structured tools.
The Initial Approach: Embedding MCP in the Medusa Server
Our first strategy was to build the MCP tools directly inside the Medusa server. This approach had major advantages:
- Speed – Local access to Medusa’s internals meant zero network latency.
- Tight coupling – No need for a separate service layer; updates were instant.
- Simplicity – Tools could directly access the Medusa DB and service logic.
But then the complexity hit.
There are over 370+ potential tools when you account for all workflows (GET, POST, DELETE variants), and maintaining them within the server turned into a monster task. Especially if we wanted to support custom plugins — like our internal reviews plugin at Lambda Curry.
Unless I gave up sleep for the next year, we needed another way.
A Shift in Strategy: Leveraging the OpenAPI Spec
Inspired by some proof-of-concept work from the Medusa community, we explored the idea of generating tools from the OpenAPI spec.
🔍 What’s the OpenAPI Advantage?
Medusa already provides an OpenAPI spec that describes all its endpoints and data structures. By parsing this:
- We could auto-generate MCP tools for each endpoint.
- Each Medusa instance could spawn a private MCP server using its own spec.
- Tools reflect custom endpoints from plugins and overrides if the spec includes them.
This means we could go from:
“Here’s a list of 370+ tools to hand-code and maintain…”
to:
“Here’s a single spec to generate all tools at runtime — tailored to your Medusa build.”
But this approach isn’t without challenges.
OpenAPI for MCP: The Pros & Cons
| Pros | Cons |
|---|---|
| ✅ Fast tool generation from existing specs | ❌ Loss of user experience design — just mirroring REST structure |
| ✅ Plugin support if included in the OpenAPI | ❌ Specs are often very verbose — bloating context for AI |
| ✅ Scalable across many Medusa instances | ❌ Tool count easily exceeds token limits (e.g., OpenAI’s 128-tool cap) |
| ✅ Separation of concerns (external MCP server) | ❌ Less flexibility for shaping tools around intent, not structure |
This tradeoff is why some (like Kent C. Dodds) recommend against using OpenAPI for MCP-style interfaces. But with the right filtering and structure, we believe it can still be a powerful starting point — especially for large, complex systems like Medusa.
The Real Bottleneck: LLM Context Limits
Here’s where it gets even trickier.
Even if we auto-generate all tools, large language models like GPT-4 have limits on:
- How many tools
- How much context
Passing 300+ tools directly to the LLM? Not feasible (at least not yet).
So we built a solution: dynamic tool filtering using a lightweight nano-LLM.
Our Solution: Dynamic Filtering with Nano-LLMs
Instead of handing the full tool list to the AI, we use a two-step call:
- Nano LLM (e.g., GPT-4.1 Nano)
- Main LLM (e.g., GPT-4.1 Mini or Full)
This approach:
- Reduces latency dramatically 🏃
- Keeps tool count within limits 📉
- Supports intelligent routing without hardcoding flows 🧠
It’s still evolving, but early results are promising. We’ve seen much faster response times — and the ability to serve complex requests like:
“Show me my Barrio-branded products”“Respond to this customer review with a thank-you”“Get a list of pending orders”
All dynamically routed, without pre-defining every path.
The Vision: Auto-Generated MCP Servers per Medusa Instance
Here’s where this gets exciting.
In the near future, we aim to:
- Auto-generate an OpenAPI spec at build/deploy time, including all custom plugins.
- Spawn a private MCP server with tools derived from that instance.
- Integrate natural language controls for every plugin (e.g., Lambda Curry’s reviews plugin).
- Create customized AI experiences per merchant — without touching the base code.
Ultimately, we believe any store running Medusa should have access to their own AI-native admin assistant. One that knows their customizations, their products, their workflows — all built from the code they already have.
Let’s Talk
If you’re building with Medusa, exploring AI interfaces, or curious about MCP in general — we’d love to chat.
Drop us a note at Lambda Curry, or hit us up on YouTube, or Twitter. Let’s build the future of e-commerce tooling together.