Full Spec MCP: Hidden Capabilities of the MCP Spec — Harald Kirschner, Microsoft/VS Code

Talk transcript

1. 0:00

   [upbeat music] Since all the questions already got asked, who built an MCP server and it didn't work?

2. 0:23

   Okay, Sam, go. [laughs] So we're here to comm-commiserate on, like, how to actually build with the full spec, what are the hidden capabilities, why they matter, and how they light up.

3. 0:32

   I work on VS Code, so this is a biased local MCP for development track, but all of it is applicable to everything. I really love the intro to the track.

4. 0:44

   It's all about... It's MCPs on high velocity. It's a lot of ecosystem growth, excitement, people working together, collaborating. But there's so much more work to do as they realize it's so early in that ecosystem.

5. 0:58

   So none of this is a criticism of the spec or the ecosystem. It's just we're so early, and I want to point out where we can gain more powers.

6. 1:06

   And just 10 days ago, on a Friday, we had actually the first l- in real life gathering of the MCP steering committee during the MCP Dev Summit. So that's how early it is.

7. 1:16

   We haven't even met before. We just talk on Discord. So we finally met in person the first time to talk about the... anything, how to evolve the spec, how to evolve the ecosystem.

8. 1:26

   And all the basics are kinda covered, um, hopefully in the previous talks. This is my first MCP talk that I don't spend halfway through just explaining what MCP is.

9. 1:35

   There's roots in the client. There's sampling. There's prompts and tools and resources. There's a really rich ecosystem to build dynamic discovery and persistent resources and rich interactions. But there's a gap in how this is being implemented.

10. 1:50

    There's this, like, MCP's just another API wrapper syndrome that's happening because people just wanna ship. They wanna build products, and they're actually building really excellent products with just tools.

11. 2:02

    And that creates this reinforcing loop because once you see how MCP works, you're just gonna use the same stacks and repeat the same tools only ecosystem. And there's technical barriers.

12. 2:11

    People do this because there's missing support in the clients and SDKs and documentation and the references.

13. 2:19

    And the clients reflect this most. If you look at the adoption that's from the website of Model Context Protocol, you see everybody goes for tools 'cause that's where the most immediate success is.

14. 2:29

    And if you're honest, actually most of, like, resources and prompts, you can do similar flows just with tools. And VS Code did the same thing. We-- When we launched two weeks-- two months ago now with our MCP support, we started with tools, and we already added discovery and roots because we were working towards actually reading the s-

15. 2:48

    the spec and implementing it. And I'm happy to announce that with VS Code's upcoming release, V one points one zero... [laughs] Gonna get it wrong. But it's already in Insiders now, so download it.

16. 3:00

    We actually have the full spec support, and that's-- I wanna talk about here, about all the other things that people are not using yet.

17. 3:08

    Whoo, whoo.

18. 3:08

    Yes, let's hear them clapping. [audience applauding] [laughs] Okay, so the message is if you go with full MCP spec support, you will-- can unlock these rich, stateful interactions that MCP's vision is really outlining on how agents should work together.

19. 3:25

    Starting with the most obvious, tools. So not getting too deep here, but tools reflect actions, well-defined performing actions and mostly easy mapping to function calling if you're used to that.

20. 3:37

    And on the right side, you see Playwright. You can start a server. It will open the browser and take a screenshot. But tools are often leading to quality problems, and we all struggle with that.

21. 3:46

    Raise your hand if you had, like, some error in your IDE that, that you couldn't add more tools and you couldn't run it or it run wrong tools because you had too many.

22. 3:55

    And there's research from LangChain that nicely underlines that and pointing out the three vectors of, A, it's too many tools. So AI gets confused by that. It's too many domains of tools.

23. 4:05

    So if you suddenly have some different properties for each tool and instructions coming with each tool, then it also gets confused versus just a pure, like, this is UI testing.

24. 4:15

    And lastly, it's, uh, just the repetition. The more repetitions of the A-AI has to do to actually run tools to solve a problem, the easier just it is to get confused as well.

25. 4:25

    So it's really quality over quantity. And clients handle that somewhat. They give you extra controls. Like in VS Code, uh, we added actually per chat tool selection. So there's a little tool packer, and you can actually reduce down the tools of what you actually need in the moment versus all the tools.

26. 4:44

    It has nice keyboard accessibility. It's really quick to set up and will persist for the session. So that's one way. We have actually mentioning of tools. Like, sometimes you, like, pull this issue and trying to, like, verb out whatever tool you're trying to in-invoke.

27. 4:57

    Like, why not just use this tool and please make up all the right parameters to use it properly and then use the other tool? So that's what we allow as well.

28. 5:04

    And then lastly, just in this Insiders actually, we're shipping user-defined tool sets, and that's more of a u- reusable concept. Once you get into the mode, like, these are all the tools I need for a front-end testing flow, then you just put those into a tool set and then use my front-end testing flow.

29. 5:20

    So that's coming as well. So these are all user controls, but actually that spec has dynamic discovery built in. And that means on the fly a server can say...

30. 5:29

    But actually that spec hack are gonna give you these other tools. And on the right, you see GitHub modmcp. It's on GitHub. You can check it out. And this starts with a chat mode that I created that puts the agent into a game master prompt, and it has the modmcp installed.

31. 5:45

    So now with the mode active, I can go into the agent, switch to mod, and play the game. And what dynamic tool discovery does here, it actually makes it aware of which room I am in.

32. 5:57

    So dungeon crawler, you walk from room to room. Like, you can go east and north. You can pick up stuff. And if there's a monster, I can battle the monster.

33. 6:04

    But the tool for battling shouldn't be there when there's no monster. Eventually, I advance through the game- And I finally find a goblin I can battle. Where a tool for battling shouldn't be there when there's no monster.

34. 6:18

    Eventually, I advance through the game, and I finally find a goblin I can battle, and the battle tool appears. I can battle the goblin. So imagine those, those MCP you wanna work on.

35. 6:31

    Those are coming up to give servers and clients a little bit more. Really, tools or actions, actually the add context return a giant file from your server, but you wanna return a reference to the file, and that could be something the LLM could follow up on or the user can actually act upon.

36. 6:47

    Then the other use case is actually giving files to the users. So if you take a screenshot via Playwright, you wanna expose it to both the LLM and the user, and resources provide that semantic layer.

37. 7:00

    And now you in. What are the issues? Oh, I found new issues. That's... They wanna understand the Python environment and maybe look at your settings of how you set it up so they can customize it.

38. 7:10

    And that makes it more dynamic and stateful out of the box.

39. 7:15

    The other one is, like if you can look at actual, the packages and your libraries installed, that's a great way to customize it to a React setup versus a Svelte setup, and really acknowledging what the user's looking at and not asking constantly like, "What framework are you working on?"

40. 7:28

    Like, just you, you work in my folder, so just look at it.

41. 7:33

    And lastly, I think the idea of like what, what is that CICD pipeline? That's where MCP servers really shine to connect the end to end of a developer experience, and you can also read those out.

42. 7:45

    Sampling. Who has heard about sampling? Is really excited about sampling. Okay, so you understand what I mean. So sampling, sampling is one of the oddly named, uh, primitives as well.

43. 7:56

    And if it had a better name, maybe more people would use it. Uh, but it's actually now in Play Insiders, and it's so much fun to use. So it allows the server to request LLM completions from the client.

44. 8:08

    What I'm showing here on the right is the permission dialog that pops up to allow the server to access the LLM. Right now, it's wired up by default to GPT 4.1.

45. 8:17

    There's more spec improvements to make it with structured formatting. There's some ideas out there. So there's a lot of things to make it better, but right now nobody has implemented it, so there wasn't really a need to make it better, but implementation's now here, so please use sampling.

46. 8:30

    That's a nice progressive enhancement. Maybe by default you return the kitchen sink, and once you have sampling, you can do interesting things like summarizing resources in, into more tangible things.

47. 8:41

    You can format a website that you fetch into markdown for the LLM, or you can even think about agentic server tools that w-one run via the LLM from the client.

48. 8:53

    If you look beyond the primitives, there's a few things that are also interesting. So far we have roots and tools and resources and prompts, and they-- with dynamic discovery, you can update them at any time.

49. 9:06

    The client will send new roots as the VS Code workspace changes. You can send new roots, uh, new servers, uh, new tools and prompts from the server as you update and you change.

50. 9:18

    So it's a really dynamic environment already. But there's more pain points to make these servers really powerful.

51. 9:25

    One is the developer experience. Who's been struggling with working on MCP servers and debugging and logging and everything? Yeah. One of the-- hands up. Yeah. There's some. Apparently it's really easy, so maybe it's not a problem. [laughs]

52. 9:39

    Okay, so we have a now dev mode in VS Code, which is a little dev toggle, and you already see the console that always works for all MCP servers.

53. 9:47

    So once you hit a snag, that just works. And then now, n-now it's in debugging mode, so it actually has the debugger attached. So once I run the prompt, which is dynamically generated on a server, I can now hit the breakpoint and step through it.

54. 10:02

    And that's really hard usually because your server is not owned usually by any process that you run manually. It's owned by whatever client and host is running the MCP server.

55. 10:13

    So because VS Code is both, it can just put it into debug mode and attach its debugger, and that works for Python and Node right now out of the box.

56. 10:22

    So super exciting. And it's, yeah, it has changed how I work on MCPs, definitely.

57. 10:28

    The latest spec, uh, was already called out. I just wanna call it out again because it's so important that people stay on the tip of the spec on what's coming and understand what's in draft.

58. 10:39

    Those things that are in draft only become stable because people provide feedback that it's useful and that it's working. And if they're in draft and nobody provides feedback, then they will still go into stable, and they might need revisions like the auth spec.

59. 10:53

    So the updated auth spec on the right gives this enterprise-grade authorization. There's a talk tomorrow about building protected MCP server that I can highly recommend from Ben who actually worked on the auth spec.

60. 11:05

    So if you wanna talk to one of the people behind it and wanna dive really deep into auth, you can do that. Then streamable HTTP has been working in VS Code since two versions as well, but then it's been really hard to test because there's no servers out there.

61. 11:21

    So if you work on hosting, you're really excited about streamable HTTP, you should really get everybody that is hosting MCP servers to, to get onto it and not use SSE anymore.

62. 11:31

    SSE is still possible to use with HTTP, so you get both benefits, but you're avoiding this really stateful churn on your servers.

63. 11:40

    Last one already mentioned, there's a community registry happening, and that's been the other big pain point. Like if I build a server and nobody finds it, or what is the discovery experience?

64. 11:48

    Like how do I send people? Like do I send JSON blobs around for people to discover my server? There's a lot of community work around this to make this discovery easy.

65. 11:57

    So it's a big shout-out to everybody on the steering committee, the community working groups, and everybody involved here. Um, if you wanna check it out, it's on Model Context Protocol/registry on GitHub, and it's all happening out in the open.

66. 12:10

    And lastly, I'm really excited about elicitations. Um, that's actually coming in the next draft, um, spec reference. Spec, draft, release, whatever. [laughs] And this is a way for tools to finally reach out back to the user when they need more information.

67. 12:24

    Right now, tools are all controlled by the LM, and you get all the information from them. But then when it actually needs more concrete specific input from the user, then you, you can just throw them into another chat experience and ask for it, but why not just give them an input to provide it directly?

68. 12:39

    So it's, it's again, more statefulness in the tools on top.

69. 12:46

    So your help is needed. Um, progressive enhancement in MCP is possible. I think we wanna have more best practices out there, maybe even in the references servers to show it off, but everything is now ready to be used.

70. 13:01

    There's clients supporting the latest spec that you can run it in and test it in. Those clients are used by users, and as more users showcase how great the stateful servers can be and outline these best practices, this interoperability gap will close and clients will catch up.

71. 13:19

    It's a very fast-moving ecosystem. People are complaining like, "Oh, you shipped this two weeks after the other person." [laughs] Um, but it's all coming together and as, as people use these and learn and bring feedback, it becomes better.

72. 13:31

    So make action-oriented, context-aware, semantic-aware servers using the full spec. And then lastly, contribute to the ecosystem. If you have the time, read up on some of the open RFCs I shared, like namespaces and search, to kinda see what's coming.

73. 13:49

    Make sure they get into the SDKs you're using by following the issues, and just share back on your experience. I think a lot of people aren't mis- misunderstand how much influence they have on clients and SDKs and everything by filing issues, by providing feedback.

74. 14:05

    I'm helping to triage a lot of the MCP issues coming into VS Code. We read all of them, we learn from them, and really that drives our roadmap. And that happens probably with every other, uh, team out there.

75. 14:16

    So really make your voice heard of, like, you-- everybody should support sampling, so. So there's a transformative potential in MCP that we all can unlock with the spec that is already there, so the ecosystem catches up to the spec.

76. 14:31

    So with that, let's go. Um, and feel free to hit us up on the Microsoft booth. There's two VS Code people there, Tyler and Rob. You can also talk to, or talk to me, or talk to your friendly MCP steering committee members.

77. 14:46

    Thank you. [outro music]