Recap and Next Steps
In Part 1, we laid the foundation for Model Context Protocol. We learnt MCP as an open standard that lets AI applications (hosts) talk to external systems through MCP clients and servers, instead of every team inventing a custom “tool API” for each integration. We also focused on WHAT, WHY and WHEN of MCP. I strongly recommend going through Part 1 to understand the concepts of MCP and how it helps to streamline the integrations in agentic solutions.
In Part 2, we will focus more on:
- Building an MCP server
- Exposing tools
- Integrating with backend enterprise systems (e-commerce application)
- Debugging and Testing locally
- Deploying on cloud (Business Technology Platform)
To make this concrete, we’ll turn the ideas from Part 1 into something you can actually run end to end: A commerce MCP server that wraps Commerce OData APIs as agent‑ready tools.
By the end of Part 2, you will not just understand what a remote MCP server is, you will have one running on your local machine and can be deployed on cloud.
Commerce MCP Server (Architecture and Building Blocks)
The commerce-mcp-server project is a Python‑based MCP server built on FastMCP that exposes a set of tools wrapping Commerce (or any CAP‑based commerce) OData APIs. Instead of calling your Commerce APIs directly from the your agentic solution, the MCP server sits in the middle and offers agent‑ready tools like get_products, get_retailers etc. that are easy for MCP‑aware clients to discover and use. This is the concrete “MCP server” instance that brings the abstract concepts from Part 1 to life.
Building blocks of Commerce MCP Server
- Agentic Solutions + MCP Client: This is basically your Enterprise Agentic AI solution which embeds MCP client that talks to the commerce MCP server on behalf of the LLM. MCP client discovers available tools exposed by the commerce MCP server and routes the LLM's request for data to the MCP server.
- Commerce MCP Server: MCP server is the application or a program which exposes the e-commerce capabilities to the AI Agent application through MCP standards.
- Tools: Tools are actions that the MCP server can perform. For example: "Get Product List", "Create Cart", "Add Product to Cart" etc. Tools gives host applications a structured set of capabilities.
- Transport Layer: MCP uses standard communication like STDIO for local and HTTP with Server‑Sent Events for remote servers.
The diagram below gives a overview of how commerce-mcp-server acts as a facade for the agentic AI solutions.
Jumping into the Code: How to Run It Yourself
Now that we’ve seen the architecture and building blocks, let’s get this MCP server running on your own machine and subaccount. The GitHub project already contains a detailed, step‑by‑step guide. in this section I will highlight the key choices and pitfalls, then point you to the exact README sections to follow.
Step 1: Pre-requisites
Before touching any code, verify the basics as called out in the sections
- https://github.com/avinashvaidya09/commerce-mcp-server/blob/main/README.md#pre-requisites
- https://github.com/avinashvaidya09/commerce-mcp-server/blob/main/README.md#local-set-up
If you just want to play with the MCP server without touching BTP, the README’s “Option 1: Mock Backend (no BTP required)” path lets you skip the subaccount and destination setup for now.
Step 2: Decide - mock backend or live backend
The next decision point is: Do you want to hit real Commerce data, or just see the MCP server in action?
For a quick start: Use mock backend as mentioned in the README file.
For an end‑to‑end scenario against BTP:
Use live backend.
Then follow the VCAP SERVICES section to load service credentials into VCAP_SERVICES locally.
If this is your first time, start with Option 1 to understand MCP’s flow. Then come back and switch to Option 2 once your Commerce OData APIs are ready.
Step 3: Start MCP Server
Just start the MCP server to get started - https://github.com/avinashvaidya09/commerce-mcp-server/blob/main/README.md#mcp-server-on-local
You can see the MCP inspector where you can see the tools and also test them.
The good news is: You don’t have to memorize any of these steps. The README file in the repository is intentionally written as a step‑by‑step playbook: from prerequisites and local setup, through mock vs live backend, all the way to BTP deployment and curl‑based debugging. Once you understand the high‑level choices we just walked through, you can simply follow the README top‑to‑bottom and you will end up with a working commerce MCP server and MCP Inspector showing all tools on your local.
Wrapping Up Part 2
At this point, you have seen how the commerce MCP server maps the MCP concepts from Part 1 into a concrete implementation. The architecture diagram and building blocks show you where the MCP server sits between MCP clients and your Commerce OData APIs. Rather than duplicating every command here, the README gives you a detailed, step‑by‑step path to go from zero to a running MCP server locally with mock data or against live Commerce services and finally deployed on BTP.
My recommendation: Read this blog once to get the mental model, then switch to the README and follow it top‑to‑bottom. If you do that, you will finish Part 2 not just with a theoretical understanding, but with a working commerce MCP server, tools like get_products, get_categories etc. exposed via MCP and at least one client (MCP Inspector, helper script, or curl) successfully talking to it.
In Part-3 of the series, we will move from standalone MCP server to integrating it with MCP client. We will create an agent and integrate MCP server, all using Joule Studio.
Disclaimer: This is not an official reference application or documentation. The thoughts outlined in this blog are based on my real world experience and learnings.
Feel free to “like“, “Share“, “Add a Comment” and to get more updates about my next blogs follow me!
Bluesky
