Top!
Hello
AI systems have long been capable of far more than just answering questions. Through the Model Context Protocol (MCP), LLMs can be connected to external services, tools, and data sources. But a functioning MCP is far from being a good tool for AI agents. In this post, we draw on our experience at let's dev to show what really matters when building one.
LLMs, or AI in general, are now indispensable in both private and business life. Few technologies have developed as fast and as disruptively in recent years as artificial intelligence. Chatbots started out as a toy for nerds or poorly built support assistants on websites, but AI as a tool, and the content it generates, has long since reached everyday life: traffic reports on the radio are read out by an AI voice, classic search queries can finally be phrased in natural language, and more than a few school assignments get a (not entirely legal) boost from AI.
In the business world, too, the journey has moved well beyond the simple chatbot. It's no longer just about typing questions or search terms into a chat interface. Today it's mainly about connecting different services through their interfaces and letting them get tasks done together. The two biggest providers, OpenAI and Anthropic, keep pushing their clients further toward agentic tools: you can have your next appointments displayed, place an order, or have your download folder cleaned up automatically. And so that an AI can communicate with other services, tools, and data sources easily and consistently, Anthropic introduced the Model Context Protocol (MCP) in late 2024. MCP is an open standard, and there are already many SDKs available to implement it in various programming languages.
Figure 1: Good tools don't just deliver data – they take the next step
At let's dev, we started early on connecting our own and third-party services through MCPs and hooking them up to LLMs (by the way, we always design our own solutions so that they meet the data sovereignty criteria of the EU AI Act). And as tempting as MCP's promise is, to simply connect services and tools together, the devil is naturally in the details here too.
Admittedly, building a first version of such a server is really quite easy. Let's say, for example, you want to teach the chat client of your choice to look up the current weather report for a specific location. For that, you could pick a service like OpenWeatherMap. The service offers an API that does exactly what we need. However, the "normal" API call to OpenWeatherMap expects the location in the form of WGS-84-compliant coordinates. Unless you happen to know the coordinates of your favorite or vacation spots by heart, you actually need one more call that converts a city name into coordinates. And now you need a second MCP that provides a corresponding geocoding service. On top of that, when defining the MCP-compliant protocols, you have to make sure the calling LLM understands how to combine the services with each other. A simple "provides weather data for a location" and "converts city names into location data" isn't enough — especially considering that the answer to the question "What is the location of Springfield?" isn't unambiguous, but a list with more than a dozen entries. Without further clarification, there's simply no good solution here. Sure, a chatbot would probably just ask you which Springfield you actually mean. But wasn't the whole point of automation to avoid exactly these kinds of follow-up questions?
This is exactly where it gets interesting: for an AI, or agentic AI, to truly benefit from other services and their combination, you have to think carefully about the design of the MCP interfaces. We too have learned that this is quite a bit more than "simply" wrapping the API.
Whether it's building something new, installing, or extending an existing MCP server: at let's dev, we support you with everything related to MCP, LLMs, and AI integrations.
Get in touch – we're happy to advise you on your individual use case.
MCPs shouldn't be thought of as thin API wrappers, but as tools built for agents. Anyone who just exposes endpoints bluntly ends up with tools – not dynamic, intelligent working tools. Only those who also design role, timing, and result semantics get genuinely useful collaboration between tools. And that's ultimately what matters to us: we define the task, the "what" – but the tools themselves should figure out and negotiate the actual execution, the "how."
This is exactly where many teams underestimate the effort involved. An MCP server that just passes an endpoint through 1:1 can be built in a few hours – and that's exactly what makes it tricky. It looks finished, seems to work fine in the first test, and yet it still falls apart in practice later on, as soon as an agent actually uses it on its own.
Semantics, not syntax. A tool schema that's syntactically correct doesn't tell an LLM anywhere near enough about when it should be used and when it shouldn't. Two tools whose descriptions are too similar lead to an agent picking the wrong one or mixing both up – a problem that only shows up once you actually test the server with a real agent and realistic tasks, not in an isolated unit test of a single function.
Error cases are the real design space. The happy path of a tool is usually written quickly. The real work lies in what happens when a request is ambiguous, an external service doesn't respond, or a result stays incomplete. Should the tool then throw an error, return an empty response, or ask a follow-up question on its own? Each of these decisions fundamentally changes how well an agent can work with the tool – and can't simply be bolted on afterwards without rethinking the interface from scratch.
Security and trust boundaries. As soon as an MCP doesn't just deliver data but itself accepts or processes content from outside – a URL, a document, an email – the trust boundary shifts. Who guarantees that an agent doesn't accidentally process unsafe content, or that instructions hidden in a document don't manipulate the agent itself? Such questions are often simply overlooked in early MCP implementations, because they never came up in the original service's API design.
Interplay between multiple MCPs. As soon as several MCP servers need to work together to solve a task, as in the weather example above, dependencies arise that no single server can resolve on its own. How granular do results need to be so that another tool can process them directly? How do you handle ambiguous intermediate results without the system simply guessing in the end? These are design questions that go far beyond a single interface.
Figure 2: Just passed through vs. designed for real collaboration
At let's dev, we now build a whole range of MCP servers – for internal as well as externally connected services – and it's precisely out of this repeated practice that clear, shared principles have emerged for us: tools are never designed in isolation, but always with an eye to how an agent will actually use them within a larger chain. Error cases are considered from the start, not added on afterwards. And recurring building blocks – from the basic server scaffold to unified response formats to security mechanisms – we bundle into a shared internal library instead of reinventing them in every new project. That means a new MCP at let's dev never starts from zero, but builds from day one on a foundation shaped by real, hard-won lessons from previous servers. Our experience in this field lets us build new MCPs quickly today, or adapt existing ones to new standards and circumstances – because of course the Model Context Protocol itself keeps evolving too. We're also happy to help you build your own MCP, or maintain and further develop an existing installation – just get in touch with us.
