About this talk
In this talk, Bernard Meyer, a senior research engineer at Storyblok, explores his journey towards implementing the Model Context Protocol (MCP) within the realm of AI integration. He discusses the concept of agents and their ability to autonomously interact with environments, referencing varying definitions and the spectrum of what constitutes an agent. The talk highlights the importance of creating a headless content management system that allows for flexibility in using different technologies, enabling both engineers and non-engineers to leverage AI agents for efficient interaction. The speaker provides insight into the development of the MCP as an open-source standard designed to connect AI applications with external systems, detailing key debates around MCP versus command-line interfaces and the evolution of best practices. He emphasizes the necessity of governance in AI interactions and proposes solutions such as API overlays to enhance usability and clarity for users.
Full transcript
Welcome to the silent disco version of my context progress. As a college journey to implementing an MCP. Um I'm Bernard Meyer and I'm a senior research engineer at Storyblok. Uh but I didn't fully lie to you. I'm also a psychologist. So, let's start. Everything works perfect. I'm going to part the talk into three parts. Um my context in progress or model context and protocol. And um let's
start with a few words about um myself. I'm like old. I'm like 24. Nearly. And um I'm a huge skeptic like in general. And I'm glad that there are clouds today so I can yell at them. But uh it actually took me until this year to try out this AI tooling stuff. And to be honest, I'm really amazed. But I read a lot about it um over
the last years, months. And um especially MCP and all these topics and how they can be integrated. Um and I love to ask questions. And I love thought experiments. And you're going to be part of the thought experiment today because currently my favorite question is What is an agent? Who of you has asked this question? Awesome. Really happy about that. So, um over the last events where
I attended and also my work colleagues um and friends, I asked a lot of them of what is an agent. And I got really interesting answers. As an example, a software system that autonomously perceives its environment, reasons, plans, and takes actions. On the one side. On the other side, I got the answer a markdown file. I love it because as ecologists, we love spectra or spectrums as
I learned yesterday. And I think it's a really good spectrum. But in reality an agent is also a software system that can delete your prod database through a markdown file. So I think definitely both All right. yeah. I like this even more because now it's a multi-dimensional spectrum and that's even better for doing science in psychology. Who of you has watched the talk of Matt Pocock just
recently released or who of you knows him? Oh, a couple of people. Um after his XState and TypeScript endeavors, he's now full on AI stuff. And he just recently released this uh cloud code for real engineers course or so, but we've not got time for a full course today. So I want to correct it a little bit and want to mention it as agents for real people.
As we are a SaaS company at Storyblok and uh we want to deliver our product to everybody to all people. We don't We don't only have engineers. I'm going to come back to that later. Um we want to provide our agent with capabilities for everybody. So it's not only focused on cloud code. First part done. And speaking about the model context uh I think it's important to
deliver some context. And this is the the this part is going to be about that. Like part of history of how MCP came together, my journey through MCP, and a lot of the discussions I had lately. let's talk about the goal. At Storyblok, um we are building a content management system. Uh interesting part about it is it's headless, so you're not dictated to bring some specific uh
so so you're not dictated to use some technology that we decide for you, but you can bring your own technology, your front-end frameworks. Uh you can use PHP, you can use JavaScript frameworks, you can do embedded stuff, you can go to mobile. You Some customers are even using it for print. So, you define your data structure, but at the same time you get the visual editor, uh
which is shown here. So, you can do the visual editing stuff, and um you can you also get just JSON, which you can render however you want. And we want our users, not only engineers, but also content editors, marketers, uh we want to enable them to use their AI agents to talk to our SaaS platform. So, that's where MCP comes in. And um I don't know who
of you have counted the term AI on this slide. It's up there six times. And so, we want to enable AIs to interact with in our case Storyblok SaaS, um but a lot of people writing MCPs they do have the same uh the same topic. So, what is the Model Context Protocol? It's summed up on the website modelcontextprotocol.io, I think, um as um MCP, the Model Context
Protocol, is an open-source standard for connecting AI applications to external systems. So, exactly what we want to do. First debate, and I think that's the one that brought me into even creating an MCP server, um or experimenting with things. It's this skills versus MCP debate. a skill is a standardized way way a standardized way to give AI agents new capabilities and expertise. Quite broad, but that's taken
from agentskills.io. And MCP, as we heard, is an open-source Again, is it a spectrum? I would say yes-ish. And then I started to look into what Anthropic says about this. And found this great this great document. Who of you has read this document? Nice, a couple of people. Um after scrolling to page five, there is this really insightful paragraph. If you already have a working MCP server,
you have done the hard part. Skills are the knowledge layer on top, capturing the workflows and best practices you already know, so Claude can apply them consistently. So anybody who wants to discuss skills versus MCP with me, that's my answer. Uh it's quite simple, and it works incredibly well. At least that's Anthropic's official So for me, it's not an either-or, they complement each other. Next debate, that's
the hot debate right now. MCP versus CLI. MCP is an open-source standard for CLI is a command-line interface. It's quite old. Is it a spectrum? I would say so. And I've just recently watched a really interesting like clarification video by Martin Keen from IBM Technology about CLI and MCP, and I think he perfectly sums it up. I screenshot that the subtitle. Um so MCP or CLI. You
probably saw this coming, but the answer is to use both. And it's ex- it's exactly what I recommend as well. Both have their use cases. And at Storyblok, we offer a CLI to do the deterministic updates, changes, deletions, so you can integrate the CLI into your script and you can do um like content management from a command line in a proper manner. So, and it's deterministic. And
we also offer MCP which people can use to do stuff like analysis, content analysis, migration, like a one-off migration, clone this website and migrate it to Storyblok, which works incredibly well. You can do content hygiene. You can ask which articles are outdated. Then you can ask yourself what does outdated even mean? If you have got a page about the weather, it's going to be outdated tomorrow. If
you If you have got a page about classic cars, it's probably not going to be outdated tomorrow. It might persist for 30, 40 years. just use both. And please don't tell me that get rid of the MCP server and just install a CLI. Because I talked about the real people and we also have like marketers, content editors, content reviewers and we want to provide them plugins so
they can use it because we don't want them to install CLI applications or their agents because I don't hate my security department. I love them. Third part. Uh about the progress. Now you have settled the debates. So, let's focus on what we actually built and live up to the promised talk title of the psychologist's journey because yeah, I'm not only a psychologist. I'm We also built the
MCP server. Let's revisit multi-context protocol. it's an open source standard for And as I told you before, I'm 24-ish and it feels like I've heard this a lot in my career. And I'd say it's quite similar to an API, like an application programming And I can remember REST from more than a decade ago and all the restful movement or soap which I really loved. I was five
by then in 2007. those are APIs and those are proper definitions for an API. And at Storyblok, we are offering an API for content. So, can't we just use our already existing rest API from Storyblok? I mean, in the end we want to enable AI applications um to use our APIs. The talk The future of MCP by David Soria Parra um released a couple of days ago,
um he argues the following. That you should design for an agent or for a human. That's a good proxy. Ground-up tools. Oh, there is the mouse cursor. Ground-up tools with clear intent, not thin as the key wrappers over a rest surface. Oh, well, that doesn't fit with my idea of building an He also goes into detail about this. We need to go and start building properly for
agents and that means we all need to stop taking rest APIs and put them one-on-one into an MCP server. Every time I see someone building another rest to MCP server conversion tool, it's a bit cringe because I think it just results in horrible things. What you should do instead, you should design for an agent. Basically, you can start designing for you as a human how you would
want to interact with this because it's actually a very, very good start for an agent. Um I'm a bit scared of the horrible things and of David being What is he? He's uh he feels cringe. I'm sorry for that, but we worked around those things and I think it's kind of interesting how you can But I think I misunderstood something because we want to connect AI agents
and we do have APIs. Why isn't this enough? It's called artificial intelligence. Artificial and intelligence. Isn't that supposed to be intelligent and can it figure out how to use an API by itself? But then I looked up the words in Oxford Learner's Dictionary cuz I'm not an English native. And artificial means made or produced to copy something natural, not or created by people not happening naturally. Or
and this one I like the most, not what it appears to be, synonym fake. And intelligence means the ability to learn, understand, and think in a logical way about things. The ability to And I think if we combine it now and see uh as a fake ability to learn, about things, it makes perfect sense that we invest so much engineering effort into an API that already exists
so that intelligent agents can consume it. Yeah, the clouds are still there. But I finally feel ready now, so let's the goal. We want to connect or we want to allow agents to talk to a SaaS And we already have an API. Um we want uh agents to to update content, remove content, like do content hygiene, which is really interesting. Go through all the blog articles about
some outdated framework and mention them to me or add comments about outdated sections and so on. And yeah, we want to feel to make this feel as natural as possible. Uh at Storyblok, as I mentioned, we are API first, which for me seems like a perfect fit. And we don't only have those two APIs, but um our I'd say main API is the content delivery API. That's
where you can actually consume your content that's stored in the content management system. And then you're free to render and show it however you want, wherever you want. But that's not how what we want to enable people to do with the MCP. It's about the management API. Uh which is a REST API to programmatically add, update, delete, or sync data. That's exactly the API we want to
expose to agents so agents can do the same things as humans can do. And taking David's arguments into account, um we found kind of a natural fit because years ago we already designed this management API around humans who want to use it. It's the content delivery API is is designed to be to be used as flexible as possible for your content to be presented, but the management
API um is to be is designed to be as ergonomically um yeah, as ergonomically as possible so that you can actually uh you can actually do your task as fast as possible and as easy as possible. So aren't they already agent ready? We have a lot of this documentation and for our APIs in the form of open API specs. But now it's getting into the territory of
of David not liking what I'm telling And because we have we've got a lot of things you can do in API, I watched one talk by Cloudflare where they mentioned they've got 2,000 endpoints. We've got around 400. I'd say around 140, 160 are targeted towards um management API and actually doing and modifying stuff. But it's still 140, 160 tools that would result in an MCP. this is
the Cloudflare talk I mentioned um by Matt Carey and he titles MCP as the mega context problem. And he says that by putting all their tools into the context for MCP, it's used around so you got basically no space left to do anything. It's even bigger than the contest window. Um but he also mentions that this is the perfect situation now where I can actually improve and
work on your open API spec. Clean up your API, think which endpoints do you have, how you structure them and so on. And this is actually one of the things that we did. We we looked through all our endpoints and and yeah and and investigated how well we like them. But we found one even better tool for doing that. And that's open API overlays. Who of you
knows or has heard of open API overlays? Okay, comparison. Who of you has heard of open API or Swagger back then? Nice. Then you're going to really love the overlay specification because it's a really small thin spec, just a couple of pages long, that allows you to modify your spec without actually modifying the source file. So you can change, update, or delete specific parts of your open
API specification without actually touching And this allows teams to work together without constantly locking each other. So let's see how this work or how this looks in in practice. This is a really small part of the thousands long open API spec that we do have. And um we do have uh an endpoint at this URL and then we have a summary which summarizes the uh what's happening
there. And then we have some parameters. And if you take a look here, we do have the parameters uh search and text search and they both have the same description. Really bad for an LM to find out what's actually what should happen here. Um and that's exact exactly the thing that people are criticizing when they are criticizing mapping open API specs to MCP servers because the the
LM can't find out what's the difference here. >> [snorts] >> But now enter um overlays. Uh they're usually written in YAML so they are easier to write. Can be perfectly written by any coding agent tool, um, which is really nice. And you use JSON path syntax, um, um, thing here that so you can select specific parts of your, um, OpenAPI spec. And then using the object keyword,
you can you can actually add properties. Um, in this case X-MCP include. So we are selectively, uh, yeah, we we are selecting the endpoints we actually want to include in our MCP so we don't include all by default, we specifically select them. Um, then we can assign some behavior we're going to see we're going to see later. And then we can target the parameters by themselves, uh,
like at name search or at name text search. And then we can update the description. And in here we can say match a story name and slug only. Does not search story content. For full content search use text search instead. And here we can instruct the LM to actually to actually do what we want it And this is really helpful because we don't have to touch the
source file which also allows us to use the source file for various departments in a company. We can use the same source file with different overlays for generating SDKs, generating the MCP, generating docs and so on. And this is really powerful. And this is what's the result. It's really predictable. It's just those properties added or changed or deleted that were mentioned in the overlay spec. And so
you get a new OpenAPI spec, but you don't have to touch the original one. it's it's really important for me to tell you that this this helped in in company organization as well because the teams the downstream teams can continue working on things while just applying a small overlay shim where the the upstream teams they don't have to even finish their work yet. And you get them
you get loosely coupled teams and they can work on the actual spec and then you can just compare those those documents and see what what are the differences, whether there are some some conflicting things, but it really helps in velocity and speed. I honestly love this overlay spec cuz it made my my work so much easier over the last couple of um of weeks. So, we now
fixed the technical tool descriptions um as criticized by a lot of people why you shouldn't map OpenAPI to MCP. Um but we've got another serious problem called context bloat, already mentioned a bit earlier. And again in the talk by David, uh progressive discovery is the solution for that. Um title tool search by Entropic. So, you don't put all your endpoints as tools into an MCP spec, but
you put in one tool called search endpoint or search tool. And then you can at the LLM can use this one to find what is what is possible. And so, they reduced um without tool search from 56,000 tokens 9,000 tokens. Um we also measured it and yeah, just found out that it's by a factor of of uh digit of two or not yeah, uh smaller. So, it's
an immense improvement. How did we do it? We also just um provided one search tool, a Storyblok search, so that it's it's also scoped to Storyblok. Because if you just call it search in an MCP server, the LLM is going to be confused for what to search for. You have to uh use a concept like namespaces. as Matt Carey in his talk mentioned, but it like works.
It works quite well. And we found the same thing. We didn't even over-engineer some things because we just tested it and it worked and we were happy with it. And that's why we we didn't really start this debate of CLI, MCP, and so on or like engineering want more effort because the search tool simply works. And it's not some semantic-based, embedding-based search tool, It's a really simple
keyword With a Levenshtein distance or so. And then we found out that for the search tool returning a couple of of is actually a bit problematic as well. Because if you return um the endpoints with all the parameters, then you get context bloat quite soon as well. So, we introduced another step for the cost of another round trip to the MCP server, which is called describe. And
only during the describe phase, the LLM can ask um [clears throat] for all the additional parameters. And this we really managed to reduce token usage. And then I think that's one of the most interesting aspects. Once you get this tool or the endpoint, you actually have to call it somehow. And in this pattern in the search execute pattern, this is usually called execute. But as soon as
you introduce just a single execute tool, you get no governance at all of whether you're querying some stuff, you're mutating your or you're deleting some stuff. And our enterprise customers, they really don't like that. They want to have governance built into the MCP as well. Of course, you can do it um with token level and often so on. But this is way earlier and you you reduce
a lot of round trips. So, how does this look visually? First, we search uh by weighted keyword scoring um and yeah, some fault tolerance. Then you the LLM can describe uh or can ask for a description. And then it can ask or those two tools in combination return which execute tool should be used. And then as an example, a lot of our engineers or content editors they
do have execute read only set to auto approve. all the read only stuff, you can actually do without without manual approval. And for mutating, you could prompt or whatever. And for destructive, explicit approval. And this works really, really So, we use search for progressive discovery. We use describe for reducing also hallucinations or as in psychologist terms avoiding cognitive dissonance. Then we do have this separate execute tools
uh to provide governance in potentially risky settings. And then one more interesting thing is the response fields thing that actually that's returned in the search or describe where you want it. Um and it allows the LLM to specifically query for specific response fields. So if we get a response like list stories and list 100 stories and you got you would get a lot of properties and a
lot of data. The LLM can do a like a conservative loading of the stories and it just wants the name and the date or so on. And that and this also reduces token usage by a lot. Probably more than all the other stuff combined. So we just expose these response fields and in the MCP server we map we map our API requests and we remove all the
other fields. And the LLM can understand it and it just And back to overlay. most of the thing that we had to do. It's just XMC X-MCP include and XMC behavior and in our mapper from the open API spec to the actual MCP server where we load the open API spec um we respect these properties. So we in the transformation step we get rid of everything that's
not included and during runtime um we assign okay this is read only. So we also do the um the governance during the read only tool um that you you actually have to or the LLM has to call an endpoint with a specific tool and it's blocked in all other And it's versioned in Git because it's an overlay. This is really nice side effect as well. One warning
note about install skills um because it is mentioned also by David Surya Pal um, where he says that you can already do some of that today. Providing skills via an MCP server, if you just give the model a load skills tool, we tried this. And please be aware, this can be really risky and my documentation engineers or our documentation engineers, they warned me about that. Because this
creates shadow docs on all the developer machines out there. Once the skills are loaded and installed via markdown and the markdown files are installed or put to a directory somewhere, try to get rid of them. It's not easy to execute code that get that remove skills via How are you going to accomplish that? So, think about that up front. There is a solution about that. I'm going
to propose in 2 minutes. >> Instead, use the server instructions. MCP has a feature where you can put a small um, text in there, which gets loaded into the system context what once an MCP server is added, which is really nice to give small instructions on how an MCP server should be added. This should not replace skills, but it can aid in using an MCP server properly.
Really powerful. It's also what I misused as kind of a prompt injection. So, it downloads the skills using the install skills tool. So, don't think too much about prompt injections if you want to get a good night of sleep. And if all of this and the fast pace of AI now tells you that the same as Matt Pocock, like his brain hurts. Um, I also want to
ask one question. Probably now with the hat of the psychologist now. Matt proposes that we should just re-architecture our software, whatever. I do have a different proposal. AI promises that we are going to be more productive by a factor of whatever. So, why don't use the time we gain to do something different. That's actually not sitting in front of So, to summarize, um what we did at
Storyblok for the MCP, uh even prior MCP, prior LLMs, um we design for humans cuz humans are actually the the end users of your product if humans are the end user of your product. Then, we utilized open API overlays heavily, also for team structures, social technical systems. It works really nice. We use progressive discovery to cut down tokens, and we added a governance layer because we do
have enterprises and we want to support Um what we will do is like OAuth support in uh an upcoming weeks because we know it's really important. Uh and we want to pluginify our MCP server and our skills, so it can actually be installed easier. And what we look forward to from the um the model companies or agent companies is proper stateless transport because horizontally scaling an MCP
server is hard now. And then this is exactly the thing David proposed that this year skills over skill delivery over MCP is going to make it into the MCP standard. And also server discovery using well-known URLs, which is really nice in terms of like ecosystem hygiene. And as server discovery is not yet implemented, um thanks a lot and feel free to try it. That's current server discovery.
And um I have basically no socials, maybe no Twitter account, um but feel free to approach me if you want to know everything anything um and uh I'll probably be at the Storyblok booth. Thank you so much.
