About this talk
This talk focuses on building Model-Client-Provider (MCP) servers specifically for Vue applications. The speaker, Elise Patrick, introduces the growing relevance of MCPs in the development process, particularly in automating interactions between large language models (LLMs) and various software applications. She outlines the architecture of MCPs, which consists of clients, servers, and transport layers enabling communication. By demonstrating the implementation of an MCP server using SDKs available in multiple programming languages, Elise shows how easy it is to set up and connect servers for Vue. Additionally, she discusses the potential uses of MCPs, such as enhancing internal documentation retrieval and improving development workflows through integration with development tools. The session concludes with a persuasive argument that MCPs remain significant in modern software development.
Full transcript
just just to check my Yeah. Hello everyone. Welcome back. I hope you all had an amazing lunch. Let me introduce myself. My name is Militita and I will be your MC for the rest of the day. We have an incredible lineup of speakers coming, five more talks and one amazing panel discussion to end the day. Before we start, let's just give a lot of applause for our
sponsors as well that make everything happen today. Okay, let's kick things off. Our first speaker this afternoon is someone who is lives and breeds you. She is a senior front-end developer, a freelancer and co-organizer of U.J Paris meetup. So, she is truly part of this community. Her talk today is about something that is on everyone's mind right now. MCP service. Angular has one. SW has one. So
what about view? She's here to show us how to build one. Please give a warm welcome to Elise Patrick. Hello. Hello. Hello. Thank you very much for this nice wonderful introduction and yeah so as it was mentioned I will speak about MCPS today. Uh but first I would like to speak about physiology. Yeah why not? Uh actually there is a specific reason for that. It is that
I'm not teaching you anything right now. It's 2 pm which means we are right after lunch and we are starting to be in these phases of the day where people where we are all like oh starting the digestion process right so when I've seen the schedule when I I saw that my talk was uh planned for that moment in the day I was a bit anxious and
so I started doing some research I googled it uh yeah I still use Google um >> and yeah And actually that was not really positive because I love this new word postpandual deep or foot coma. I was like oh my god what I'm going to do and especially like it's supposed to start between 60 to 90 minutes uh after lunch. So if you had lunch around 1
p.m. Uh we are dangerously arriving in this zone. So I thought what can we do? What can I do against that? Maybe I should propose to do some uh like a physical activity like some people do that. This is Cancy Dot. You probably know him if you know a bit about uh React ecosystem and yeah he likes starting talks with a session of um air squats. I
thought oh that's a brilliant idea but wait I'm not considered I would never convince a single person here to do that for sure. So I will just keep it easy and more simple. I will try to highlight as much as possible the key takeaways of my talk. So in case you would feel a bit like less attentive or maybe sleepy, at least you can have this ideas
out of the talk hopefully. So this being said, I will just say a few words about me. Uh so my name is Eliz. I am from France in Paris. Uh you probably can guess it from the emojis and from the accent. I I am a front- end architect at a company called We Save. It belongs to the Amund group and I am also an occasional speaker. I
uh had the chance to speak here two years ago in Amsterdam. I've done also a couple of other conferences and uh I am as it was mentioned, thank you again. uh a VGS Paris co-organizer and by the way um if you feel like sharing anything with the Parisian view community feel free to find me to talk with me um even if you are not living in Paris
we can have some guests sometimes so we may be able to arrange some things okay so now I would like to tell you about uh how my interest for MCPS began and it began in London September 12th of 2025 well it was 6 months ago and it began there at a conference an Angular conference called Angular connect which if you are into angular ecosystem I really recommend
that's a great one and uh this was the opening talk with the angular core team and they were explaining like they were given like lots of great ideas I can give you the reference of the of the conference later of of this of the talk and among these ideas uh there was the question of How to make agents more autonomous uh in the way they build uh
build I mean in the way they developed software how to replicate the uh development uh flow that we as a developer have for agents and they were basing this idea this research this reflection on MCPS so that's the reason why but wait I want MCP's dead why am I asking because I was at the community event yesterday which was uh great. Um and we had a panel
uh brilliantly animated by Alex and um and yeah actually I had like a few um kind of remarks about MCP like uh yeah it was MCP before but now now it's more about skills you know or MCP used to be a thing or who is still using MCP? No, I'm kidding. I did not have that one but that was just to emphasize it but yeah so um
I know that there used to be like a lots of vibe around MCPS uh now it's less the case but I am convinced is still a thing and I will try to convince you as well so the agenda is uh I mean uh the the talk is really simple it's divided in two parts the first part is more generic uh about MCPS and especially how to build
them uh so if you are like a bit tired But I would recommend to focus on that one maybe. And the second one because it's that's the most generic one. Um and uh the second one is focused on building an MCP server for Vue. So let's start. Uh I start with a brief introduction on MCPS because I really want everyone to be on the same page and
also I noticed that there was bit of confusion around the notion of MCP. So I think it's good to redefine things. So um first of all uh LLMs cannot do uh everything for sure like they cannot search in a DB they cannot read files they cannot launch a browser etc etc so uh the solution is to let them call a server right who will be able to
do uh these kind of things but this um triggers questions like lots of questions and especially true the first one is how do we connect how do we connect LLM with a server Right. And the second one uh is how do we we let them communicate efficiently uh especially how do we let um LLM know which input it has to pass to a server for example. So
of course this leaded to a custom implementation. So everyone did his own thing uh which has lots of drawbacks and especially the one that we can end up with something like this uh with like lots of different implementation everywhere. Um therefore MCP was created by anthropic in 2024 uh with the idea of standardizing everything. I mean I I mean standardizing this process uh of um connecting LLMs
with servers and enthropic provides several things that's really interesting. So first it provides a protocol. So um the protocol in itself like the the specification then it provides SDK and also development tools and references implementations. So let's focus first on the protocol. The protocol provides several things like that's quite uh complete I would say but uh one thing I want to focus on is the architecture that
it provides that it um yeah that it provides that it um specifies sorry. Uh so in this architecture there are three things that we need to know three entities I would say. Uh the first one is the client. So the client is the piece of code which will be interacting with the uh with the host and the LLM and with the rest of the process. Then at
the other part of the chain there is the server right which exposes tool that uh the LM will call. And in between to make the connection we have the transport which can be local or remote. We will come back on this notion. So let's have a a schema that will be probably clearer. Um at the first at first we have here the host. So the host is
really the userfacing application. That's cursor that's VS code that's whatever application that uh uh which is uh used by by us. Um so this is what we call the host. Inside the host we have LLM and then um we have as I mentioned this piece of uh this entity which is called the client which would communicate between uh which will assure the the communication between the LLM
and the rest of the process. Then afterwards we have the server right which does his own thing like for example looking in the fi interacting with the file system um and which exposes tools such as reading writing whatever and in between we have this entity the transport um we can wonder why do we have a transport in Britain I mean we could uh like maybe directly connect
the client and the mcb server well that's because uh there are different ways of communicating of connecting Sorry MCB client and servers um I mean different actually there are two different we can either connect them locally or remotely and that's the transport which will assure ensure the fact that we um um that both of them are connected and do this uh the translation to the MCP server.
So yeah the transport is responsible for that. So we can connect it locally with std in SD out process for example or we can connect it um remotely with streamable HTTP. So I hope it is clear and um yeah so that was all for the uh the architecture the idea I mean when you build NCP you don't really need to have like deep knowledge of it but
that's good to have an idea of the architecture to understand then on the code part what is happening. Okay so all good I hope. Are you fine? Okay, cool. Uh let's move to the SDK. Uh and if you want to listen just only one part of the talk, I would recommend to listen that one. Uh because I will show you concretely how it looks like um on
the coding part and you will see it's surprisingly easy. So the SDK is really convenient. uh it's available in several languages including TypeScript and it literally abstracts the whole protocol logic. So let's have a look on how it works. Uh and we will build here MCB server um just right away. So uh first we will declare the server. So for that we are using the uh the
uh the SDK. Sorry I just stop it like it's might be a bit fast. Uh we are using the SDK for that. So as you can see we uh well you cannot see it very well but uh we just uh declare a new instance of of MCB server. We configured it with the name with the version and that's all like here we have a server which might
which is functional and which may be connected to the rest of the process. So let's do that now. Let's connect it to the rest of of the process. And you will see that's also very easy. we will instantiate a new transport. So here uh we keep things simple like we will use this um we will use this uh this server uh in cursor. So we we are
we are doing everything at the same uh on the same machine. We are doing everything at the same place. So we will just use a local process. So stdio server transport um and that's all actually. And now all that we have to do is to connect it. So just with this 10 lines of code uh we have a MCP server which is functional and that we can
literally right away use uh in our host here cursor. So it's functional but it does nothing. So it's not very interesting. Uh so let's add a tool right. So we are adding a tool and for that we will use the method register tool which is provided by the server instance and which will we will configure it by adding a name by adding some um some metadata such
as a description. The description is really important that's uh because it will help the LLM to know when to use uh the server and also the input schema. Uh so this is also important because this will uh provide the llm information of which input the server is expecting and then we have the actual implementation and that will be in the end probably the hardest part but uh
here we add something very simple. We just say hello. So here we are. We just need to import z and we should be good. The last thing that we have to do is to uh inform cursor that we have this uh this server which is available but you're probably used to that. Uh we have this server which is available and how to use it. So we just
declare it in the configuration file. Um and that's pretty old. This is these are things that we are used to do right and then it should be working. Let's check. So if I go in my uh settings, I can see we can see the server and we can see that we have one tool which is enable and which is uh probably working. Let's just test it. And
actually you will see there is something interesting happening in this video. I did that test several time maybe seven something like this. Each time when I was prompting that uh I had um cursor decided to use the MCP except in that time where he decided to do his own thing. Why not? I mean this is uh not deterministic, right? So that um I I kept this video
because I found interesting to um I found it interesting to highlight the fact that it's really that the description of the tool is really important because each time um we we have a demand uh for the LM to use it. I mean it's um the better the description is the more likely we are uh to be used we we are that the LCP will be used uh
at the right use case. So yeah that was just an example. I found it interesting and then I do it it again and then that time it works. I I'm helping him a bit with the MCP and uh I just go a bit faster. Oops. Sorry. Well, it had to happen once at least. Uh just showing the result. He's sinking, sinking, sinking. And then woohoo, he called
it. So yeah. So that's it for uh the generic part like the part on MCPS in general and how to build it in our code ourself. So now I would like to focus to something uh else which is um building MCP server for Vue or at least trying to do to build a We um which use case could we have um for MCP4 view? That's that's a
good question, right? Uh I personally see two use cases I see. Oh, and by the way, if you're interested in that question, you can also have a look on the uh as was mentioned on the angular and MCPS which are also their own tools. Um in my case, in the case of you, I was mostly seeing two use cases. I was seeing the first one is about
documentation like providing a tool to look in the documentation directly. The second one is about dev tool like providing a tool for LLM to be able to interact with the view dev tools at the runtime. So let's start with the documentation. Why would we need like to fetch the documentation? After all like we have LLM which are very performant. Why? Well, uh there could be like two
two uh to me two main reasons like the first one is that maybe we want to have like fresh data data which are fresher than the data on which the models are trained, right? And uh the other one is that we may want to provide uh a tool to get smarter content than uh what a client would normally do like if he if he does the same
search on internet. uh for example like in the case of view we will we will fetch the information directly in the algorat and also we could also consider like reworking the information that we get back uh in the MCP in order to save tokens and to provide directly to the LLM like uh an actual and relevant information. Uh spoiler. Oh, okay. Spoiler. To be honest, I did
lots of test and I think it's not very useful on view. Um because uh to be honest like even like on late like very recent features LLMs are quite good uh and they they're aware of they know how to look them to look for them. So I was a bit mitigated on the utility on view but I still wanted to show it. Why? because sorry uh because
uh I think that's something which can be used to any documentation and especially that could be useful for let's say internal documentation things like this or maybe documentation which is less known than the view documentation which evolves quickly things like this like for example we could consider for your internal design system like having uh OMCP which uh provides some tools to uh look directly in this kind
of So let's have a look quickly uh on how it works like I mean it's really basic. We have exactly the same thing that we had done uh earlier. Uh and we have here a tool which uh basically just um provide um uh uh goes and fetch in the algoria documentation with the right parameters and so on um the query that the LLM would pass and then
there is a bit of rework on the uh on the on the output part and uh and that's that's all. So that's completely something which is applicable to uh any any kind of of documentation. Okay. Are you still there? Because now we are going to the death tool part. And that one is I have to say a bit technical. A bit more technical. I mean we will
not go into details but yeah hold on we are almost done. So on the dev tool part um first all the credits I I want to give some credits like to I'm not it was not a great explanation. All the credit goes to these two genius persons. These two geniuses uh Anthony that you probably know right and also Arlo who is also a view team member VidC
team member u view team member um other sim team member like he's brilliant and yeah what I will show now is completely based on their work. So uh dev tools what uh what can we do with LLMs and dev tools? Well uh we can provide LLM to um for uh sorry we can provide a tool uh for LLM to inspect the runtime state of the application like
what is the state of a component in the browser what is the state of a store and we could also um consider like maybe why not uh providing to the LLM the ability to mutate uh through the dev tool the runtime the runtime state I will make it uh in order to uh help it to debug some situations things like this. Okay. I think there are many
many applications which are possible. Um right now we will just focus on two of them. I mean even one of them uh which is inspecting uh the runtime state of a and for that what do we need? First we need of course the the dev tools right? uh we need to have the dev tools which are available in the client and for that we will use the
uh dev toolkit which is a kind of how to say a kind of I mean that's really imprecise but a kind of API for the dev tools then of course we don't want to inject it directly in our production code so we would like to inject it in the only in dev mode uh and ideally programmatically. So that's actually a very good use case for doing a
vit plug-in. And then second thing, what do we need else? We need MCP server of course and a communication between the MCP server and the client the client sorry maybe it's not so very clear here. I by the client I mean the client application like the the front end application running in the browser, right? So we need a communication between these two between the server and the
application. Okay, how can we do that? We have something great which is available right out of the box which is called the vit websockets. So let's use that and we can why not configure it directly in a vit plug-in. That's also a good application and use case for a vit plug-in. And then we need to instantiate somewhere the server, right? And since this is extremely related with
the uh two other actions that we have to do injecting in the client in the application uh the dev tool I mean the the dev tool kit and also uh joining connecting to the vip web socket we will simply do uh the rest of the process meaning instantiating the server also in the vit plug-in. So basically that will be a vit plug-in which in um which creates
MCB server and then which uh make it connected uh with uh the the dev tool of the application. Just a little parenthesis. Uh here we um since we also we have this vit server which is available we will use for the transport streamable HTTP and instead of local I mean because it's available and also a small global generic solution. Okay. So let's just summarize quickly summarize that
quickly with a with a schema. I I highlighted um a bit because I think that's also a good use case on not only for NCP but also for VIT plug-in. Uh so we have here our host as usual, right? And then we have this vit plug-in which will um do most of the job uh and in particular instantiate the uh MCP server and also the transport that's
on as we have seen before. And these two will communicate through a streamable HTTP through an endpoint that we will make available through in the vit uh uh development server. And on the other side we have the browser with the application and inside the application we injected this uh dev toolkit. We injected it in uh the vit plug-in by the v plugin I would say and then
these two like the mcb server and the application will communicate uh through the uh vit websocket. So that's the idea. Let's see now in action. Let's see what it does. So here is like a coffee application like coffee if we need to uh know and um so here I am just asking to get uh the uh the state of the root component and let's see what what
it does. Maybe I can make it faster. Yeah. Yeah. Supposed to be okay. It's a it's a bit long. It's a bit long. I can't I can't make it faster. Okay, good. Great. So, um he found that he could use the uh view MCP uh which has been uh installed in this application and uh yeah, actually it's working as we can see it's working and he could
get back the uh the state of the component. So, I find it personally pretty cool and uh yeah, I find it pretty cool. I hope I'm not the only one. Thank you. Thank you very much. And now let's arrive to the conclusion of all this. And for the conclusion, I would like to uh come back uh to the initial idea of the talk which was the this
uh idea of replicating the development flow that we have us as developers uh in um to to give the ability to agents to replicate it. And basically this development tool I mean this is a simplified version of it but let's say we write some code then we visually test it right and then we might if we think that we need it uh try to test it internally
um maybe to have some look on uh internal state things like this through the dev tools and then according to what we see what we discover what we find out we rewrite some code and so on and so on. the idea would be to tend uh to this uh to this flow to t to let agents tend to this uh uh autonomous flow. So I tried to
um do ask my lm my client to do something a bit more complicated which is uh to add the basket like so the user can select some coffee and then can um find the selection in the basket. So let me just show you uh how we could work and also I added uh the fact that I want I helped it a bit because uh so I write
it down in the prompt like yeah please test it visually and also test the state. Um I I think we would need to configure it precisely like through skills or through through cursor rules like to make it automatically but whatever. I asked him to develop to do the development and then to test it visually through the play MCP and uh also to test the state through the
um viewc and I will go a bit faster because uh oh no no it's not possible what's happening Okay. Okay. We are here. So here he has written the code. The all the code part is done. And now he's um he's testing with the playright MCP. So it is uh visually testing. That's what I ask in the prompt. So it is doing it by itself. So you
probably test used the the paycp before. uh still testing taking a snapshot getting back the snapshot the LM can visualize the snapshot and say okay visually everything some seems okay let's not try to uh test internally like to taste the state of the application and then he found that he could use the view I mean he found that he could use the the view MCB for that
and it is testing well it's coming back a bit to play right like it's not like completely seamless but still it is testing it and yeah I think he got it now and now he he concluded that okay visually the application looks as expected and also in the state it looks as expected as well. So yeah, so that was a little experiment like to see how we
could tend to this like uh autonomous agentic flow. Okay, let's conclude because I have 15 seconds left. Um key takeaway key takeaway uh NCPs are not dead. First thing uh also uh I really wanted to emphasize the fact that they are really I mean the SDK part is easy to implement. Of course there is then the several implementation but um globally is surprisingly easy I would say
and also that I really believe that it can be useful I mean in our daily life it can be useful like for handling custom use cases uh if you're interested in uh this uh view mcp server uh feel free to have a look on the repo you can also install it um feel free like to give some feedbacks to I mean I would be happy to have
any feedback about it for now there are like very little uh tools very few tools but I I want to improve it and to keep on experimenting it. Uh I wanted to give uh a big thanks to uh first to the Belleview meetup which is the Belgian meetup run by Cyan who is not here today because he like better going to the dev world than to view
Amsterdam and because actually um uh we had the Belgium meetup at a company called Monies but they are here and they that was the first iteration of my talk and they really gave me some great feedback and it encourages me into continuing it. So I wanted to thank you and I wanted to thank Julian as well. I don't know if he's there uh because he helped me
also for for the talk. And that's all. I wanted to thank you for being here, for being part of the view community and for listening to me as well. Thank you.
