# Building a Customer-Facing MCP Server: What Do You Actually Need? In the previous article, we looked at how MCP works behind the scenes and the role played by clients, servers, tools, resources, and prompts. This time, let's look at a specific use case: building a customer-facing MCP server. If your goal is to allow customers to interact with your product through AI clients such as Claude, ChatGPT, Cursor, or Claude Code, what do you actually need? The good news is that if you already have APIs or services, you're often closer than you think. ## The Essentials If you're building a first version, I'd focus on these first. ### 1\. Existing Functionality to Expose Most MCP servers sit on top of functionality that already exists. That functionality might come from: * REST APIs * GraphQL APIs * Databases * Internal services The MCP server becomes a layer that exposes that functionality to AI agents. One thing you'll quickly discover is that not every API endpoint necessarily deserves to become a tool. The goal isn't to mirror your API one-to-one. Instead, think in terms of capabilities that would be useful to an AI assistant. For example, instead of exposing: ```text GET /projects GET /projects/{id} POST /projects/{id}/tickets ``` You might expose higher-level tools such as: ```text search_projects create_ticket ``` The MCP server can orchestrate one or multiple API calls behind the scenes. What matters is not how your API is structured internally, but what actions are useful for the AI assistant to expose to the user. One thing that surprised me was how capable modern AI clients are once they have access to well-defined tools. My initial instinct was to think through every possible workflow a user might need. In practice, I found that the AI client could often orchestrate much of that on its own. For example, imagine an MCP server exposes: * `search_projects` * `create_ticket` * `get_ticket_status` A user might ask: > Create a ticket for the login issue in the Mobile App project and let me know when it's done. The AI client can determine which tools to invoke, chain multiple calls together, provide the appropriate inputs, and even check back for updates if the workflow requires it. This changed how I thought about tool design. Rather than exposing a tool for every workflow, I found it more useful to expose clear capabilities with good names and descriptions, allowing the AI client to orchestrate them as needed. ### 2\. An MCP SDK The easiest way to get started is with an MCP SDK. SDKs are available for several languages, including: * TypeScript * Python * Java The SDK handles much of the underlying protocol and transport details, allowing you to focus on defining the tools, resources, and prompts you want to expose. ### 3\. Choose a Transport One of the first architectural decisions is how clients will communicate with your MCP server. The two most common options are: * `stdio` * `HTTP` For my first implementation, I started with `stdio`. It was a great way to get a prototype working quickly and test the integration in my local development environment. Since the MCP client launches the server as a local process, getting started was relatively straightforward. Within a short time, I had my existing APIs connected to Claude and was able to interact with them conversationally. Instead of manually calling endpoints or testing requests, I could simply ask Claude to perform actions using the tools exposed by my MCP server. It didn't take long, however, to realize that our end goal wasn't a local integration—it was allowing multiple customers to connect to the same MCP server. At that point, an HTTP-based server became the more appropriate choice. If your goal is simply to get a feel for MCP and validate an integration quickly, starting with `stdio` can be a good option. It lets you connect your APIs to an AI client with minimal setup and experiment locally. However, if you already know you'll need a hosted, multi-user solution, you may prefer to go straight to an HTTP-based server. ### 4\. Decide What to Expose One of the most important design decisions is deciding what functionality should be available to AI agents. A common mistake is trying to expose everything. For a first version, focus on the handful of actions that provide the most value. Ask yourself: > If a customer connected this MCP server today, what are the top five things they would want an AI assistant to do? Start there. You can always expose additional functionality later. ### 5\. Decide How Users Will Authenticate If your MCP server exposes customer data or performs actions on behalf of users, you'll need a way to authenticate them. Authentication becomes especially important once multiple customers start connecting to the same MCP server. The AI assistant isn't acting on its own behalf—it is acting on behalf of a specific user. That means the MCP server needs a way to identify who the user is and what data they are allowed to access. Common approaches include: * API Keys * OAuth We'll explore authentication in more detail in a future article. ## Start With the Smallest Useful Integration One thing I found useful was focusing on getting a single end-to-end workflow working first. For example: 1. Connect an MCP client to the server. 2. Authenticate a user. 3. Expose a small set of useful tools. 4. Successfully invoke those tools from the AI assistant. Once that foundation is working, it's much easier to iterate. You can always add more tools, resources, prompts, richer authentication flows, and additional transports later. In my experience, the challenge isn't usually exposing another tool. It's making sure the entire flow works smoothly—from connecting the client, to authenticating the user, to successfully invoking functionality in your application. ## Nice-to-Haves That Improve the Experience Once you have a working integration, there are several things that can make your MCP server even more effective. ### 6\. Provide Context One thing I didn't fully appreciate at first is that exposing tools is only part of the solution. The AI also needs context to understand how those tools should be used. For example, in one implementation, the underlying application stored dates and times in a specific timezone, while users interacted with the AI in their own local timezone. Providing that context allowed the AI to perform the appropriate conversions before invoking tools or presenting results. I found this particularly powerful because it allowed the AI to adapt its behavior without requiring additional tools or changes to the underlying APIs to accommodate every possible use case. In many cases, if the AI seems to be making poor decisions, the missing piece isn't another capability—it's additional context. ### 7\. Consider Resources and Prompts Many MCP servers start with tools, but the protocol also supports resources and prompts. Resources can provide additional context, such as product documentation, while prompts can expose reusable instructions or workflows. These aren't always necessary for a first version, but they can be valuable additions as your MCP server evolves. ### 8\. Document How to Use It Even with a standardized protocol, documentation still matters. Users need to know: * What your MCP server does * How to install it * How to authenticate * Which AI tools support it Good documentation often makes the difference between an MCP server that gets adopted and one that doesn't. ## Conclusion One thing I learned is that a lot of MCP server design decisions become clearer through testing and real usage. As you try different scenarios, you'll quickly discover whether: * The agent is missing important context. * A tool is missing. * Two tools should be combined. * A description needs to be clearer. * Additional resources would help. I was also surprised by how capable modern AI clients are once they have access to well-defined tools. They can often chain multiple calls together, provide the appropriate inputs, and orchestrate workflows that I initially thought would require dedicated tools. The best way to understand what your MCP server needs isn't to design every possible workflow upfront—it's to start with a small but useful integration and observe how the AI client uses it in practice. Over time, those interactions will tell you where the gaps are and how the server should evolve.