About this talk
This talk focuses on the Model Context Protocol (MCP) and its integration with Drupal. The speaker, Joe, explains the significance of MCP as an open-source protocol that facilitates communication between large language models (LLMs) like ChatGPT and third-party applications such as Drupal. He discusses how MCP enables developers to create a uniform interaction framework, enhancing the ability to retrieve and manipulate data while providing a structured approach for LLM applications. Joe highlights the importance of understanding components like client and server architecture, authentication through OAuth 2.1, and the need for custom tool creation to optimize functionality in Drupal. The session emphasizes the evolving landscape of integration and encourages developers to explore MCP’s potential in enhancing user experiences with their Drupal sites.
Full transcript
Hi, thanks for coming to my presentation. Uh, I'm going to go ahead and get started. Now, just so to make sure that you're in the right place, I am going to be talking about MCP or model context protocol and how to integrate that with Drupal. Um, quick introduction, my name is Joe. I am Eoj the Brave, which is Joe spelled backwards and then the brave on drupal.org
or and Slack and most other things on the internet. If you have questions after the session or would like to connect later to talk about any of this, uh the best place to find me or easiest place would be on Drupal's Slack as EOJ the Brave. I work at Drupaliz.me Drupalize.me produces Drupal training material um written tutorials, video tutorials, and a bunch of other content. To tie
that back to this presentation, um probably about eight months ago or so, I was tasked with um hey Joe, could you go figure out what MCP is and if we should implement that on the Drupalize Me website? And I said, yeah, sure. And then also at that same time, it was time to submit session talks to Drupalcon. And I was like, ah, I'll probably learn a whole
bunch about this and I can talk about it at Drupalcon. Um, and so this presentation contains a lot of the things that I've learned over the last eight months or so in trying to figure out different ways to implement MCP alongside of Drupal. This talk is broken up into roughly four sections, not of equal length, but there are four of them. Um, I'm going to spend a
bit of time initially just talking about what MCP is and why it matters. that I'm going to talk about how MCP works in the context of Drupal. Um, in particular, I'm going to focus on looking at kind of the different layers of what MCP is and how Drupal fulfills different roles in that system. Then I'm going to talk a little bit about the current working path to
getting things set up in Drupal. Um, a lot of this is what we're going to discover through a lot of this is that like anything in the sort of LLM AI um, ecosystem right now, things are moving really quickly and the thing that I set out to try to build eight months ago quickly became very relevant in about four months and then I started building something different.
There's been a lot of learning along the way and my hope here is that I can help you understand where things are in the Drupal ecosystem currently so that if you want to get started hacking on something, you've got a place to start with that and then also just bigger picture kind of systems thinking how MCP works and how Drupal fits into that picture so that when
you are trying to build something you know what all the pieces are that you're going to need to create. just to set expectations um this presentation is a is developer focused though there uh it's light on I said light on code actually there is not going to be any code on any of the slides um there will be some demonstrations but it is a pretty technical presentation
the goal is to explain from a technical or developers perspective how you can integrate Drupal with an LLM application using MCP um like I mentioned just before there's a lot of like architecture of MCP and more of a systems thinking and less of a specific this is the line of code you need to write and um yeah the goal is help you get started on your own
implementations and some discussion about where or when you might want to do that just as a quick um calibration who here has already tried to implement MCP in some form or another >> yeah yeah in Drupal or anywhere Okay, cool. That that's useful. What I saw is that for the most part, this is new to uh the vast majority of us in the room. Um okay, so
first of all, let's talk a little bit about what MCP is and why you might want to implement this in your Drupal application or to be fair any other application especially right now. MCP is short for model context protocol. This is an open-source um protocol or definition of how an LLM application like chatgpt or cloud code can have a conversation with a third-party application like Drupal or
notion or any other application that you can think of. The MCP is effectively the language that these two applications can use to communicate with one another and accomplish tasks. Um, MCP was originally started by Anthropic. They have since open- sourced it. It was born at a time when these applications like Cloud Code and Chat GPT were uh really starting to gain a lot of steam, especially people
wanting to figure out ways to use them in conjunction with existing tools that they already had on their machine. You know, a common example would be something like Obsidian or Notion or your note-taking thing and wanting Claude to be able to read your notes. Um at that time all of these sort of um chat applications were kind of coming up with their own different ways to do
that to integrate with thirdparty applications. Everybody had a different approach to it and it quickly became apparent that it would be better if there was a unified way to do this so that that we as developers could just do it once and it would work with any of the LLM applications in the ecosystem. Um MCP uses a client server architecture. We're going to be primarily talking about
the server implementation of it. Um which is the side that Drupal will live in. In the client server architecture here, the client tends to be something like your like your chat GPT application um wanting to communicate with the MCP server which is Drupal or the whatever other hosted application. uh and I just point that out because uh we're going to be focused primarily on the server architecture
but MCP does define both how the client and the server should operate. So if you are uh implementing chat GPT or working on cloud code um understanding how it works on the client side would be important. Uh I think an easy uh analogy for people who have written code for Drupal before would be the Drupal plug-in API where uh the so MCP is not literally Drupal plugins
but it plays a really similar role. It's kind of like a shared contract that lets the client or the plug-in manager in Drupal discover a set of available functionality using a common interface and then to um execute or call that functionality also using a common interface without having to necessarily know who implemented the plugin, how that individual plugin works. Um, so similar to like a custom block
plugin in a Drupal module, there's a unified way to define a block. The Drupal block plug-in manager doesn't care what the internal logic of your block plugin is as long as it returns a response in the appropriate format. Um, MCP functions a lot in the same way. Claude doesn't care what your MCP server is as long as it speaks the language of MCP. And I think that's
important because having open protocols like MCP allows an ecosystem to form around that protocol and around the applications. because of things like MCP, lots of the tools that we currently integrate with our LLM tools like Cloud Code or Codeex or any of these um use MCP to expose the functionality of the external application. But because it's using an open protocol, it doesn't matter which of the LLM
applications you choose. You'll be able to use your uh MCP server or MCP speaking application with it. um that means it's you the user get to choose all I'd like to use chat GPT versus the scenario which is also true right now in some cases where um certain LLN applications have kind of their own custom integration with a third party app and you're like wow the only
one that integrates with Gmail is Gemini so I have to use that one. Um the idea with MCP is keeping it open so that people can make choices. Here's a quick example of it in action. In this example, sorry if it's hard to see in the back. Um, I have Claude connected to the Drupalize.me website through an MCP. In this instance, um, I've already connected it and
logged in as my user account. And so that I can ask Claude to do things like um look up a set of tutorials on the DrupalizeMe website or look at my cue of tutorials on the Drupalize Me website. And these little lines where it shows what Claude is thinking, it's calling out, hey, I'm calling this tool right now. Whenever you see a doing that kind of thing,
it's calling out to an MCP server to make an action happen. In this case, I said, give me a list of tutorials about a foreign API, I think, is what I requested. in this case and it did it. It got those tutorials back. So cool. It was able to read it. But then I also said, why don't you go ahead and add those tutorials that you found
to my queue on Drupalize.me. Um it's doing that here by calling the add to Q tool. We'll get into how these tools are defined in a moment just to show it in practice. Um and it was able to successfully add those things to the queue. And I like this demonstration because it shows that in MCP we're talking both about retrieving data like reading something from a website
but also about performing actions on a website and even more importantly performing actions on behalf of an individual on that website or application. Right? This was able to log in as me on the website and add things to my specific queue. Um, so cool. That was that demo. Cool. Um, when I think about MCP and who it's for and who might want to use it, I think
of three different audiences. I think that the three audiences for MCP are developers. Like those of us who are Drupal developers. For us, the value of MCP is portability. You define your application's interface for talking with external LLM clients once and your users can choose whichever client they want to use to access your MTP server. You're not tying them into a specific decision about which uh AI
they need to use. Um, it also because it's a a common protocol that everybody speaks, um, there's opportunities for us to share code with each other, not have to reimplement every piece of the MCP conversation on every single Drupal site. Um, again allowing an ecosystem to develop around it. Another audience for MCP are the end users. So the people who have opened up chat GPT and selected
to connect your external application to their chat GPT client um for them the value is usefulness um it the ability to interact with your personal data on in a third party application is super powerful and it allows the sort of I mean one common thing would be the elimination of the need to copy and paste between your, you know, note-taking application or your um, you know, Drupal
blog post and whatever claude is written for you because it can just post it there for you. Importantly, it can take actions on your behalf. And then the third audience for MCPs are of course the LLM models that live inside of these applications like uh, Chat GPT or Cloud. And this is valuable for them because MCP allows them to get access to structured data and tools that
have specific intent. Uh, and I point this at because a lot of these tools now also have the kind of agent mode or a gentic interface where you can tell chatgpt like, hey, use a browser interface to go to the dupalize me website and perform these actions on my behalf. And it will do it. and it will generally do a pretty good job. It it can probably
go to the site and find the tutorials by clicking around just like a user would and eventually adds them to your queue. Um, but that also comes with the risk of it might not work. It might click the wrong button. the potential for a lot of kind of chaos to happen when it is just trying to automatically navigate and figure out your website versus something like MCP
which can provide specific structure and guard rails. Just call this tool with the ID of the thing that you want to add to the queue and I'll add it to the queue for you. Not go try to autonomously navigate the website and find the add to Q button. It doesn't even actually say add to Q. It's just a visual little plus sign. So, I hope the robot
can figure that out. Um, so th those are the three audiences I see for a couple of important terminology things that I think will just help with better understanding how all of this works and fits together. Um, we say host and client. Um, and this refers to the LLM app or the large language model app like Claude Desktop um, Codeex or Claude Code. That would be the
host. And each of those host applications contains an MCP client that does the work of speaking the MCP language to a server. The analogy here would be something like your Drupal application can make use of the Guzzle HTTP client that is bundled with Drupal to make HTTP requests. Drupal doesn't make the HTTP request. It asks the Guzzle client to do it. Claude doesn't make the MCP requests.
It uses a client library to do that. Um, and importantly I think too here is that again with that building an ecosystem and the ability for people to share code. A lot of the LLM host apps are using the same MCP client internally kind of like lots of PHP applications use Guzzle under the hood for dealing with HTTP. Then there's the MCP server. that is the thing
that um sits on the server side of this client server architecture and speaks the MCP language. Its responsibilities are basically exposing the capabilities that your application provides using the MCP defined um specification for what that definition looks like. Think of this as being like the API endpoint within your Drupal site. Um, within the MCP model. So there is also the concepts of tools, resources, prompts and sampling.
These are all the different sort of features of MCP. Um, MCP tools are callable actions. So the protocol has a way that you can define what it what the callable actions are and what the inputs and outputs are going to be for that action. U think of this as being like a Drush command. You open up the terminal. That's the host application. You type your commands into
it. You provide some arguments for it. Um Drush is the client here. It sends the request off to Drupaler, which is the server. Drupal clears the cache and sends a response back. That's a tool call or an action happening. Um, MTP also defines the concept of resources which are basically just readable chunks of content. These are pages more or less on your site um or like the
response to a JSON API request but not in JSON API format in MCP format. And then there are prompts and sampling. Um, these two I think are important to know exist, though in my experience they're uh they're still pretty new to the MCP spec and they're are less um consistently available across all different MCP clients. So, it might work in some cases and it might not in
others. Prompts are essentially a way for your MCP server to provide autofill text to put into the chat window in like chat GPT. So like think of it as like oftentimes you might want to go to a website and find somebody else's prompt for copy editing and you'll copy and paste it and that's your prompt like act as a copy editor etc. Um, MCP allows a way
for a diserver for a server to define those prompts. And then sampling uh gets a little more complicated, but sampling is a way for the server to ask the m the client application if it can use the LLM model embedded in that application to do something on the server's behalf. Kind of like you might type into chatpt like, "Hey, when's Joe's birthday?" and it'll look it up
and respond with an answer. Sampling allows Drupal in this case as part of the MCP pipeline to say I want to ask chat GPT that question, but I want to do it in the background. I don't want this to be userfacing. Um, so I'm going to ask the question, take the answer and use that as part of what I'm doing as as a tool call. Where I've
seen this used effectively is something like search summaries. um in that you might have a hey um Claude get me a list of all of the tutorials on the Drupalize Me website and it'll do that and then can when the tool call happens that does the search the Drupal website could say hey before you present this back to Claude what I actually want you to do is
take these search results and summarilize them using this format and it's asking the model with inside the cloud application to do that on your behalf comes back to Drupal and then Drupal passes that result back. That's what sampling is used for. Another way to think of it would be like your Drupal site does not need to have a model built into it in order to use the
LLM capability. It can just ask whichever client is attached to it if it can temporarily use its model to perform um some computation. MCP um the architecture of MCP also builds on the OOTH specification. It uses this in order to allow for authentication and authorization. Specifically, MCP requires OOS 2.1. And that's important because OOS 2.1 is relatively new um addition. The 0.1 is a relatively new addition
to the OASH It provides for um the ability for OOTH servers to publish metadata about the server that a client can ping a known URL and discover information about the server. Uh and what that does, we'll we'll see a bit more about why that's important. Um, but specifically if you're going to implement MCP authentication, it has to be OOTH 2.1. And a couple of additional RFC's that
are are part of the 2.1 specification. Um, MCP uses OOTH for a couple of things. Authentication is like logging in, proving the user is who they say they are. And then authorization, which is your permission to do something. So I'm logged in as Joe. Joe is an administrator. So these are the things that he can do. um scopes which are a way of bundling permissions together and
being even more specific than say a role in Drupal. You could think of a scope as when you um you know the most common oath flow that we probably all experience is GitHub. Sign in with GitHub and or sign in with Gmail and when you do that you're redirected to the GitHub website. You sign into your user account and then the application that's asking to work on
your behalf says I'm going to work on Joe's behalf. In order to do that I need access to do these and it gives you a list of scopes the things that it wants to do. And the important part here is that it's a narrower permission set than the user might have um if they were logged into the application directly. GitHub can access my email address and my
name, but it can't access my phone number or you know things like that. Um so scopes are a narrowing of permission sets. That's important when it comes to allowing thirdparty applications that have their own brain um accessing a site on your behalf because you really want to be conscious of limiting what it can do. And then discovery um which is the 2.1 part of this uh effectively
the OOTH 2.1 defines a way that you can publish metadata on your site that the OOTH client can read and figure out which different OOTH flow it needs to use because a browser uses a different authentication flow than a terminal application than a desktop application. This allows for the application to discover that um in the moment which flow will work versus having to hardcode it into the
application itself. Uh Drupal fits really well into this MCP model and uh for a handful of reasons and I actually if you were at the keynote earlier today I think Dre touched on this really well that Drupal is well positioned in the world of AI tools for a handful of reasons. things like the um importance that we've already placed on structured content. Structured content with typed data
um fields and entities make it easier for us to integrate tools like MCP with Drupal. It's already well positioned there. Drupal already has a really strong set of natural APIs for doing things like access control or entity manipulation. Um, all of those things that we as developers are already using when we write modules for Drupal to work with Drupal's internal data structures are APIs that can be
exposed using an MCP um to third party applications like cloud. Um, and Drupal also already has a strong um foundation for user authentication roles and permissions. um it even already has a really well-baked implementation of the OOTH 2.0 spec and so that is helpful when it comes to um MCP authentication. Uh so just quick summary of that saying the the summary here is that the MCP is
a way for a uh large language model client to speak with your thirdparty application using a shared language. The benefit of that shared language is we can build an ecosystem of tools that all work together. Um, Drupal fits really well into this model already because of its structured data and its APIs and because it can serve as a server, which we'll see in a moment. Um, and
that MCP uses builds on the existing OOTH specification, again, specifically OOTH 2.1 um, in order to allow for Now, I want to talk a little bit more about how Drupal fits into that picture. So, those are all the pieces of what makes MCP work. Here's how Drupal fits into that and the parts that it does. Um, just a quick reminder, we've got this concept of a U
MCP client and that's going to be your userfacing application. So, we'll say cloud code or chatgpt. There's the MCP turver turver. There's the MCP server which exposes the tools and resources that the client application can use. There's Drupal which in our case is the thing that is custom about our implementation. Drupal is our business logic. It is our data. Um it is the thing that we want
to expose to the MCP client. And then there's the authentication layer or OOTH. Um Drupal can fulfill one or many of the roles in this ecosystem. Um, you could have an implementation where you just have your Drupal site acting like it currently does and you could use Ozero for authentication and you could use a NodeJS proxy for the MCP server um that speaks MCP with Claude. Um,
you know, that'd be one possible implementation of it. And then Drupal has the system of record, right? It has the blog post or the tutorial that someone's looking up. Um, you could also go to the complete other end where Drupal still sells almost all of the roles in the picture. Everything other than being the client. Drupal can be the authentication server using the ooth module. Drupal can
um be the continue to be the business logic, but it can also be the endpoint that speaks MTP. Uh, and I got a couple examples of different setups of of all of those things. But I think conceptually keeping in mind that like Drupal can play just one role in this picture or it can play many roles depending on your specific needs. Um there are two common flows
for how tools work with MCP. There's a read flow and an action flow. In the read flow, a client application makes a request to the MCP server. The MCP server says, "Yep, here's the capabilities that I have that you could care about." And one of those things is going to be resources. And so then the client says, "Okay, I see a list of resources." It's kind of
like a table of contents of your site that Claude can scan. And then when you say, "Hey, I want to know um like what Joe's birthday is." It can say, "I got an about page for somebody named Joe." is one of the resources. I'm going to request that resource. The MCP server takes the request from the client um passes it along to the business logic in Drupal
that looks up the entity and the entity API and returns that. The MTP server then needs to take the say JSON that it got back from Drupal and format it into the appropriate shape for an MCP response. Similar to how when your a browser goes to your Drupal site, the symfony kernel has to form that uh response from Drupal into the shape of an HTML response, HTTP
response. Um so that would be the read flow. Um importantly, I think too in this case like read flows with MCP are not the same as an agent just going and browsing your site and kind of searching through all the pages. It's much more of a presenting the at initiation presenting the client with a table of contents of everything that it has available to it and then
the LLM will in the process of trying to answer a question look at that list and say it seems like this record might be useful at that moment it's going to request the record get the data back and include it in the context that it uses to answer the user's question. Uh the other thing that about that is that these are going to be in a much
more structured format. So it's probably going to get something that's in a JSON JSON format back versus um just the text of the page. Um and that can be important when the it can provide a lot of additional important information to the model about the data that it's seeing when it's in a structured format. The other flow, the common flow is the action flow. Uh same kind
of thing here. The client when it first starts up pings all the MTP servers that are connected and says, "Hey, give me a list of all the tools that I have access to." And the server responds and says, "Well, you've got a tool for get tutorial and a tool for add to Q." And this is the inputs that those two tools take. And then somebody asked the
client, you know, you type your question into the client in the process of answering the question, it goes, "Ah, they want me to add something to the queue." And I have a tool called add to Q. I'm going to call that tool with it appropriate inputs. sends that request to the server. Uh the MTP server uh in the action flow importantly, it's going to validate any inputs
to make sure that they're matching the appropriate format. It's not necessarily validating the values, but the MCP server does validate that the inputs are an integer if that's what it needs to be for the specific um commands for uh I guess parameters for the tool. passes that on to your canonical business logic in Drupal, which is going to do things like um permissions checks in Drupal. Does
the person who's asking to add to the queue have permission to use the queue? Like does this all kind of map to all the same validation logic that would run if you submitted the form in Drupal, returns a response back to the MCP server, shapes it for the client, sends it back to the client, probably says something like, "I did it." And then Claude's like, "I did
it." Um, and that's the flow there. I think the important distinction here with action flows versus retrieval flows is that in an action flow, validation and permission boundaries become really, really important because you're asking the application to do some kind of action that potentially mutates data. It could delete something, right? In the same way that we're much more worried about permissions for things like an HTTP post
or delete request than we are for a get request. there's that. When it comes to authentication, this is this adds the authentication server into the mix. Um authentication is not required for MCP. You can have an MCP server that is totally anonymous. So maybe just a retrieval flow because it's just grabbing blog posts off your site. But if you want to implement actions on the behalf of
a user, you need to have authentication. So Olaf comes into the picture there. And this just illustrates that a little more where the client um at when it's initialized reaches out to the authentication server and says like, "Hey, can I authenticate?" And you say, "Yeah, and Joe." And then it's like, "Okay, I can can I act as you?" "Yes, you can act as me." um gives it
a token that it can use in exchange with Drupal to uh and then Drupal can use that to authorize the actions that you're taking. Again, these could all be their own independent things. Um or they could all be contained within Drupal. Um this video, let's see if it starts playing. Yeah, this one um illustrates the OAS authentication flow. And specifically, I think it this is interesting in
that um when MCP uses an OOTH flow, the way that it works is the MCP client first makes a request to the server, the server responds and says like invalid um you need to be authenticated. Then the client says okay fine, how do I authenticate? So, it pings the server for the OOTH 2.1 metadata, which is basically just a big JSON object that says, well, if you
want to authenticate, here's all the different flows that I support and the scopes that I support and how to access them. And then the client says, okay, cool. Uh, I pick the authorization code grant workflow and it, you know, depending on what is implemented inside of that specific client, it'll start the flow with duper or whatever authentication server. It then goes through that whole handshake where it
says, "Okay, log in as Joe. Now I've got the appropriate token. The client or in this case the MTP inspector tool um has access to that token. Once it has the token, it can make requests on your behalf." Um so that's showing that in action. So that's a bunch of different layers of the stack and how those specific things work. Here are some of these ways that
Drupal currently fits into that. Um so you've got your client like cloud desktop and then there's the server, there's the authentication layer, and then there's the action calling or tools um layer in the Drupal world. Right now there is the Drupal MCP_server module which is does the work of acting as the MCP endpoint. It publishes your Drupal site's capabilities and says here's the resources and tools that
I have available. Um there is the Drupal slash there the tool module or tool API um which expose uses Drupal's plug-in architecture to expose u actions that can be performed in a Drupal site. Um again this this morning in Dre's keynote he was talking about the ECA module and its ability to compose various tools together. Um, ECA also uses tools from the tool API as part of
how it u interacts with things internally within Drupal. You can either use its existing tools or you can define your own custom tools using the plug-in architecture. uh Drupal has already the simple OOTH module which does a really good job of implementing the OOTH 2 specification and then there is this uh additional module um simple ooth_21 which is a work inprogress implementation of all of the parts
that are missing from simple ooth to add the um server metadata discovery stuff. I suspect that eventually those two will be merged together. Right now they're separate for like kind of faster iteration, but I expect those will be merged together. There's also the Drupalms MCP module. And I want to point this out because um kind of what's happening right now is both the MCP server and the
MCP module in the versions that exist that you can download effectively do the same thing. They both act as an MCP endpoint, but there is ongoing work to merge those two modules. MCP server as of right now is going to become the canonical server endpoint module and MCP is eventually going to become more of an ecosystem metadata module. Uh probably it's going to become like a recipe
that will install MCP server tool, simple ooth and In practice, it looks like this. If you apply all of the different um modules into that OAS authentication flow that we saw before, I don't I don't expect you to read the whole diagram. This is just a the important part here is the box that got drawn around a bunch of them that's labeled Drupal. like Drupal can do
all of these things, but I also think it's important to mentally keep those three things separate because when you're trying to set this stuff up and develop or debug it, knowing that there are three distinct parts of the system really helps with that. Um, so remember to sync in roles or architecture. Even if Drupal hosts some or all of the architectural components, keeping those separate is important.
Um I talked a little bit about the difference between a read or a retrieval path and the action path and um the importance here is that action paths specifically have different risks and you need to be aware of those risks and setting appropriate boundaries for those tools and mention that today's got there a handful of Drupal modules that allow for um configuring and setting all of this
up But it's still evolving and very much a work in process. Um, in my experience, you can install these modules and you can build MCP capability into your site, but it is not turnkey. It still requires quite a bit of um packing to get it all working, partially because everything's just moving so quickly. Um the other big thing that happened in the last maybe six months or
so is that um initially the work was happening around creating a Drupal module that also had a NodeJS component that would act as kind of a a middleware MCP server between Drupal and your MCP client. And the reason being because um node had an official MCP server SDK. It makes it pretty easy to easy it makes it easier to implement the MCP spec when you can use
somebody else's work that they've already um done a lot of that's how it started out in that time. Um, there's now a official PHP SDK for the MCP spec that is supported both by Anthropic and Symfony. Um, and so in the Drupal community, there was a move to pivot towards that because Drupal's PHP, uh, it would be great to use that. It is not yet as polished
as the node version. Uh, and it's certainly not as widely used. Um, it works. Um, the node version is more workinger. Uh, and I point that out because if you're as you're in get into this and you're maybe trying to hack something together for your particular use case, you one of the things to consider here is going to be like for my use case, does it make
sense to build something using the node the existing node MTP server as a proxy for say Drupal's JSON API? And if all you're doing is maybe retrieve a request, that might be a pretty easy way to stand something up. Just, you know, make a request to node, there's a small layer in there that just turns that request into a JSON API request to Drupal, gets the data
back, formats it as MCP, and sends it back to the server. Of course, with that, there's all the other implications like does your hosting provider support running a node application, etc., etc. Um, and you can also do that with Drupal using the MCP server module still evolving. Um, a couple practical examples of this in u action. I showed one with Drupalize Me already, but here's another one.
This one um, again showing that Claude is connected to the Drupalize Me MCP server in the Claude UI um, in the chat application. These are called connectors. um but it's an MCP server and in cloud code they're called MCP um connections and codeex has their own vocabulary and chatpt has their own vocabulary. The important thing is they're all speaking the same MCP protocol. You just give it
the URL of the MCP server and the application does the figuring out the rest of it. In this instance, it's um made a I I logged into I went in the cloud. It's already logged in as me to the Drupalize me site. And I said, "Hey, um, can you help me remember what I was working on learning last time I was learning Drupal?" And it's like, "Yeah,
you were learning how to implement forms. I don't remember what it said." Uh, but it was able to because I logged in and it could make specific requests to the site. It was able to look up like data that was in my queue and also my history of things that I had read on the site. And using that, it could create a more personalized experience for me
than it would have been able to if I just said, "Hey, can you search the Drupalize me website for content on forms, which it can totally do. It can use its internal web agent to go off and perform a search and and bring that stuff back." But this is a more personalized experience. And then I was also able to do things like add a bunch of things
to my queue, etc. Um, I think the important thing here is that idea of allowing the LLM model to act on your behalf and perform real actions on your behalf. In this case, it's, you know, adding things to my queue, but you could also imagine it adding to a calendar. You could imagine it um logging in as you as an administrator and coming back and giving you
a list of all of the images on your site that are missing alt tags and then working with you step by step to add alt tags to all of them and then it could also post back to the server uh to update those but then it can perform real actions uh on behalf of a a person or a robot. That was that example. I guess I just
walked through specifically that what that one did. The maybe the one thing I want to point out here is um when you're using the Drupal implementation of MCP, I said you can use the tool API and it provides a bunch of tools already. In my experience, it's definitely worth the time to define custom tools for MCP. And I think the tool API uh provides a bunch of
like very primitive tools. read this entity, create an entity, add a field to an entity. And if you hand all of those tools to a language model like Claude, it can look at all the definitions and it'll eventually figure out like, okay, what you want me to do is like create a flag entity with these fields with this ID and it's maybe called like four or five
different tools and it's used a lot of context and a lot of tokens in that workflow to accomplish it. Um, contrast that with defining um specific intentbased tools. Add to Q, give me the idea of the thing you want to add to the queue. It can call just that one tool rather than having to piece together a bunch of other tools. Another way to think of the
tools that you can find in the tool API are they're really well designed for things like composable actions like the ECA module or a lot of the agents that are in that are used by um various tools within the existing Drupal AI system. But those agents like the create a view agent has a system prompt that is a really intricate definition of each of these tools and
how to use them to create a view. When you when your MCP server exposes create an entity or read an entity to Claude, it doesn't necessarily have that same context. So custom tools provide the um language model with more information about the intent and how those tools should be used which can allow it to make better informed decisions about when it should use them. Um another thing
that I played around with was creating a MCP server that used u data from api.grupal.org as the backend. And one of the lessons I learned here that was really neat about using MCP versus just letting Claude or ChatgPT browse the HTML version of the site is that it in the MCP world I could provide the data in a very structured format. It's no longer just the HTML
of the page. It is a JSON object that says this is the function method. These are the parameters for the function. This is the version of Drupal that this function is compatible with, etc. um which it can kind of figure out if it browses the site, but if you just give it a JSON object that clearly lays it out, you're making it a lot easier for the
brain inside of chat GPT to figure out what to do with that information. Um, an example on the Drupalize Me side that I used was when you on on Drupalize Me, we've there are tutorial nodes on the site and they have a field called archive status and that field is an integer and it's has a value of like 0, one or two. And then when you go
to a page in the scene, we don't display a value like zero or one. We use that to decide which different visual representation we should show you on a page and it comes with a whole message that says, "Oh, this tutorial is archived because there's a newer version and that one's over here. You should go get it." Or, "Ah, this tutorial is archived and it's way out
of date and we wouldn't ever recommend you do this, so just ignore this tutorial." Um, or this tutorial is up to date. And those are all visual representations on the page that we as humans can pretty easily interpret. the LLM has a harder time when it looks at the HTML of the page making that understanding. And if all you were doing it was serving it a JSON
object that said like the field value is zero, it would be like okay the value is zero. So creating custom tools and using MCP, I could give it the field value of zero, but I can also tell it this field contains three different possible values and if it's zero, it means this and if it's one, it means this. And so now the now claude or chat GPT
has more information about what that data means and can make um useful inference based on that. But a couple other use cases that I've thought of where this might be useful. So mine so far have been related to um inter like as a individual interacting with personalized data on a site. Some of the other things I've thought about where MCP could be really interesting to implement would
be um as a content editing or editorial assistant. Um being able to I I mentioned earlier the idea of like asking Claude to give you a list of all of the images on your site that don't have an alt tag and then collaborating with it to create those alt tags. And then when you've approved them all, it could just update those entities on Drupal versus you having
to copy and paste all of the um content that it came up with. More things like copy editing a you might have like the AI first pass at copy editing a piece of content and the MCP server allows the uh LLM to just do that and then progress the node into the next state of the workflow without all the back and forth copying and pasting. Um, so
things like that I think could be pretty interesting. I think we'll also start to see some more um use cases you could expose a kind of like site building assistant. Hey, build me a viewer of events and it can the server can or the or gives Claude or Chat GPT more ability to perform those kinds of actions on your site. Um, again, just kind of thinking through
like what are the things that your site does? What are the ways that you interact with your specific Drupal application that would benefit if the LLM application could just do it directly versus you having to do all this copying and pasting and and managing things back and forth? Um, right now there is um I kind of mentioned that the the tooling for all of this exists and
it is possible to make things work, but it is definitely still hacking it together. Um, if you want to dive in and start playing around with this, my recommendation um would be to start with things that involve retrieval or reading. Uh, build tools for reading a piece of structured content from the site. In my experience, that was the easiest to set up and definitely a big early
win. Like get the data into the LLM for context with maybe some additional metadata that helps it understand what the data is. Um, then add some kind of logging or observability so you can see what the model is trying to do when it accesses the site. Um, there's a little bit of useful context in tools like Claude where it shows you, hey, I'm calling this particular tool
with these parameters, but it's also really helpful to see on the Drupal side like what did Drupal think was happening um during that call. And then I would after that focus on um introducing authentication and tooling um for things like add to Q. Um it's kind of like progressively it just gets harder and harder. The other thing about the authentication side of it that I've experienced is
it's particularly challenging to test and debug because it requires a full OOTH workflow. In a lot of local environments, development environments that can be hard to set up. Um, the pro tip here is use ddev and then use the ddev share command which will open up an SSH tunnel to access your local machine and then do all of your like givea the URL for that SSH tunnel
because most of the MCP clients are built in node but it's inside of something like claude but node does not like unsigned local SSL certificates unless you tell it like the specific, you know, this is development mode, but the problem is you can't tell it this is a development mode when it's opening node inside of the cloud desktop app. So, having that full uh SSL tunnel makes
a big difference for testing. Um, I spent like at least a couple of weeks bashing my head against that. Um, so that's that. Um, you know, just kind of to end where things are right now and where I see this going in the future. Right now, uh, I think in the Drupal ecosystem, we have a lot of really useful tools that do the heavy lifting of speaking
MCP and allowing you to integrate with Drupal's internals. It is still a work in progress. It is not a thing where you can just turn it on and everything is going to work the way you want it to. But it will give you a big step in the right direction if you are ready to start hacking together some custom tools. I think that in the future we're
going to see all of that get simpler and smoother. Uh I am imagining that down the road you'll be able to install the suite of Drupal MCP modules and using a UI like ECA or something else piece together your site specific tools and expose them to an MCP server potentially all right through the UI especially with primitive tools uh maybe always still a need to develop those
custom ones. Uh and then maybe importantly is that regardless of where you're starting with the the sort of cobbled together tools today or the shiny uh model in the future, I think having a good understanding of this the different layers of the MCP specification and the role that Drupal fills in them is always going to be helpful in in your ability to piece those things together. And
that is my presentation about MCP. You can scan this QR. I bet you've all heard this already a bunch of times today, but you can scan this QR code and leave feedback on the session and uh I and the Drupal Association would very much appreciate that. And uh I'm happy to stick around and answer questions. We are right at 350 and so feel free to get up
and leave. I will answer questions for a couple minutes until someone else has to come up here and then I will step to the side and answer questions over there. So, thank you for coming.
