MCP Mesh — Data Mesh evolution for auditing and organizational self-service

Why you should consider delivering MCPs as a part of the solution delivery

Situation

Every time you deliver a new product to production, despite the urge to pat yourself on the back and consider the project as finished, the truth is much uglier. Now, you have just brought a new software life form to life. You will have to take care of it. Upgrade software, add patches, add new features, and all that sounds nice, but what is the worst part? You will have to respond to questions about that piece of software (especially when you are busy with other things) and support it.

We are introducing some form of auditing to make everyone’s life easier. If users are privileged to access the data directly, they can self-service their questions. What is the problem here?

Interfaces
Quite often, users of those audits are non-technical people. This means that linking data sets will require you to write code and modify queries for each and every use case that is requested. Let’s be frank — writing a query whenever you want to quickly get info about some audit events is not something you want to spend your time on (and your employer doesn’t want to pay for it either).

Data sets
Whenever we deliver products, we build an audit, which is part of the solution delivery. Thanks to that, the team that knows best their domain curates the data and delivers a high-quality dataset.

The audit models and quality of the data stored in each field are clear, clean, and ready to use. Audit data is treated as part of the product.

Diving into the essence of an issue using those data sources is totally feasible with proper audits filled with rich data, but correlating different data sets in the data mesh can be challenging.

Some parts of the analysis won’t be feasible, though. Typically, when running some analysis using, for example, Athena, we can’t cross-correlate it with live data, data not being part of audit data, third parties, public data, and so on. We are limited to the collected data.

How can we approach it differently?

What if we could deliver an extra component, a set of tools for supporting a system used in an MCP Server?

The idea is that engineers or any other company employee could use such an MCP Server with their own credentials and just stand on the shoulders of ̶g̶i̶a̶n̶t̶s̶ great engineers working with them (who provided you with great tooling to have peace of mind and… yeah, of course, also to improve organizational efficiency).

That way, we are not limited to our curated, great audit data sets. We can cross-correlate data across multiple datasets and tools from many different domains. What is also great? Our LLM can also be aware of our ubiquitous language with proper context.

The interface is no longer a big issue for non-technical employees. In the end, they can chat with a chatbot. The difference is that it will be skillful enough to consume internal company resources.

Ubiquitous language

Sometimes, certain things might be called differently across domains/departments/projects/teams. We all know that introducing such semantic conventions and ubiquitous language is a pure pleasure and an easy goal to achieve in organizations 😅. This is why we might have many different names for exactly the same thing. For example, a user identifier might sometimes be called “userId”, “customerId”, or just “user.”

Where should that translation be put in these cases? In all users’ heads, or can we do something better and make it part of the MCP-based solution?

Do not cover 10000000000 cases

If we expose our data sets to tools, it’s the model task to combine data and use all of those tools efficiently. This is a great benefit because this solution is supposed to work better and better as models improve over time. We are just focusing on delivering proper tools and resources that support users' self-service across our systems.

There is also a downside of that situation which is determinism, but let’s not focus on it now too much.

So let’s cover some super simple cases. Imagine that we have some types of super-simple resources to expose:

• API listing all the airports (name, id, country, city, coordinates etc.)
• API listing the timetable of connections between two IDs (let’s say IATA codes)

Thanks to that, we can ask about the full timetable of flights flying from Warsaw to France (and both of them are not airports). LLM will:

1. List all of the airports and filter the French ones
2. For each of the airports, load the timetable
3. Merge it and return it

Then, we can work on it and filter specific days of the week. None of this is part of the APIs that we have provided; we have extended our capabilities.

Based on those resources, we can get info that is not accessible through any of those API contracts, like:

Where can I fly on Friday and come back on Sunday from the capital of the United Kingdom to Spain in Q3 2025?

LLM will translate “capital of the United Kingdom” to London and filter out all airports related to London and all Spanish airports. After loading the timetable, it can filter out dates not within Q3 of 2025. I know it doesn’t seem super-helpful, but I want to sell you the idea.

Extend capabilities

We can add another API that will expand the capabilities of our chatbot, which will be able to mix and match using different tools (for good and bad, sometimes models are doing strange things and do not optimally use tools). That extension is not linear but can be used with any existing tool. For example, in case we add an API that returns fare prices for one way flights, we can evolve into:

What is the cheapest flight on Friday for a trip at least 5 days long departing from the capital of the United Kingdom to Spain in Q3 2025?

An important point to note here is that even though we defined a tool to find one-way flights, models understand that a return flight must occur after departure.

Then, we can add an API that will provide information about flight operational details and get information about the type of aircraft operating a flight, cabin crew, or any other information available to us.

The beauty is that we can easily add new tools that quickly evolve our agents' capabilities. We can use LLMs as glue for all of the capabilities that we expose. We are abstracting away the integration of all those tools into the model.

Replace people with tools, and negative with positive complexity growth. Source

Summary

I believe in this new paradigm of software delivery, where, as part of the delivery, we are not only building a curated audit dataset but also a curated and dedicated MCP. That could democratize access to data and empower organization members, especially those non-technical ones, who usually are the power users with the biggest domain knowledge. Plenty of ideas will come from that area when those users see what is possible.

We could also reduce the number of questions the engineering teams receive (which was my initial motivation), allowing them to focus on delivering value and really hard cases instead of helping with all sorts of easy issues and tasks.

Models are still non-deterministic, and you have to be aware of that. Models are not 100% predictable, and the same prompt can be addressed in different ways every time. Sometimes you will be amazed by the way the model approached your prompt, but sometimes you can be totally disappointed that it doesn’t understand you this time, even though it understood you 100 times before. Still it is a way better and cheaper approach than building a solution based on 100s of deterministic integrations.

Posts going into implementation with MCP framework details are coming soon.