Data layer versus API

I recently experimented with creating an MCP server in front of a live instance of Yontrack.

After having plugged it into Claude, I could directly access the Yontrack data and display the information I needed.

For example:

Can you give me the durations between the build creation and their BRONZE promotion, for the main branch of the yontrack project? I'd like to have it displayed as a chart. I want only the builds that do have a BRONZE promotion.

Then, getting the data and some graphs, following up with questions about some aspects of the response.

After seeing how I was interacting with the data layer, after having seen some posts on the subject and listened to a great conference here in Brussels, I started to see the emergence of a new reality (or was it always there?): the data is what matters, but so is how you give access to it.

Getting rid of the UI (or more exactly here, bypassing it) removes any obstacles in the way I use the data. I not only interact with it but I make it fit my needs. I don't need to raise an issue and/or code new charts or pages. I can just rely on Claude to do the work for me.

Of course, in many cases, just using the built-in UI or the API will be a better fit for some purposes. But for ad-hoc cases, where I need to quickly assert something about my CI/CD ecosystem, the prompt and its interaction with the data behind is just good enough.

Speaking of API, do we need it here? In this experience, yes, definitely! But not just any API. In the case of Yontrack, data is accessed through GraphQL and Claude is able to use the whole schema in order to design, based on specific instructions at the MCP server, very accurate and performant queries. This therefore requires the API to be comprehensive and well documented. I was using GraphQL, but I guess the same can be done with OpenAPI. The GraphQL API was just very good at translating complex questions into performant queries.

So: API and documentation first to open possibilities for your data?

PS: I'll write a second part of this article where I explain how I've set up this MCP server in front of Yontrack, what issues I faced, how I made it secure, performant and reliable.