# Full Spec MCP: Hidden Capabilities of the MCP spec — Harald Kirschner, Microsoft/VSCode AI Engineer · 2025-07-18 Harald Kirschner from Microsoft/VSCode argues that MCP's full specification unlocks powerful stateful interactions beyond the common 'tools-only' implementations, transforming AI assistants into more contextual and efficient agents. He highlights underused primitives like resources for rich data context and sampling for server-requested LLM completions, demonstrated via a dungeon game where dynamic tool discovery adapts to game state. VS Code's upcoming full spec support includes dynamic tool discovery, user-defined tool sets, a debug mode for server development, and support for streamable HTTP to reduce stateful server churn. Upcoming features like elicitations will allow tools to request user input directly. Kirschner calls on developers to build progressive, full-spec servers and contribute feedback to the open ecosystem, emphasizing that client and SDK support will follow as usage grows. ## Questions this episode answers ### What is dynamic tool discovery in the Model Context Protocol and how does it work? Dynamic tool discovery lets MCP servers change the set of available tools on the fly based on context, rather than providing a fixed list. Harald Kirschner demonstrated this with a dungeon game where the “battle” tool appears only when a monster is present, reducing confusion by exposing only relevant actions and avoiding tool overload. [5:33](https://aie.addtry.com/4f508534-afb9-4939-96cc-1a330b76d0aa?t=333000) ### How does sampling work in MCP and why is it underused? Sampling allows an MCP server to request LLM completions from the client. Kirschner showed a permission dialog in VS Code Insiders where the server accesses GPT‑4.1 to summarize resources or reformat fetched websites into Markdown. Underused due to its odd name and lack of client support, sampling enables powerful agentic server tools once adopted. [7:42](https://aie.addtry.com/4f508534-afb9-4939-96cc-1a330b76d0aa?t=462000) ### How can I debug an MCP server in VS Code? VS Code has a dev mode toggle that attaches its debugger to any MCP server. When a prompt triggers server logic, you can set breakpoints and step through the code, with an always‑available console for logging. Kirschner confirmed this works out‑of‑the‑box for Python and Node, transforming how developers troubleshoot MCP servers. [9:34](https://aie.addtry.com/4f508534-afb9-4939-96cc-1a330b76d0aa?t=574000) ## Key moments - **[0:00] Intro** - [1:15] MCP steering committee held its first in-person meeting at the MCP Dev Summit 10 days ago. - **[1:41] API Wrapper Syndrome** - **[2:51] Full Spec Support** - [2:51] VS Code v1.10 adds full MCP spec support, including tools, resources, and sampling, announces Harald Kirschner. - **[3:47] Tool Challenges** - [3:47] LangChain research identifies three vectors causing AI tool confusion: too many tools, too many domains, and repetition. - [5:33] GitHub MCP dungeon game demonstrates dynamic tool discovery: battle tool appears only when a goblin is present. - **[6:35] Resources** - [7:41] Sampling enables MCP servers to request client LM completions; Harald Kirschner says 'please use sampling' now that VS Code supports it. - **[7:42] Sampling** - **[9:18] Dev Experience** - [9:18] VS Code dev mode now attaches a debugger to MCP servers, supporting Python and Node for improved developer experience. - **[10:40] Future Spec** - [10:54] Updated MCP auth spec delivers enterprise-grade authorization, to be detailed in tomorrow's talk on building protected MCP servers. - [12:11] Next MCP spec draft will introduce elicitations, enabling tools to request direct user input rather than prompting through chat. - **[12:46] Call to Action** - [14:06] Harald Kirschner: filing issues on MCP implementations directly influences client and SDK roadmaps. ## Speakers - **Harald Kirschner** (guest) ## Topics Model Context Protocol (MCP) ## Mentioned Microsoft (company), Discord (product), GPT (product), GitHub (product), LangChain (product), Node (product), Playwright (product), React (product), Svelte (product), VS Code (product) ## Transcript ### Intro **Harald Kirschner** [0:15] Since all the questions already got asked, who built an MCP server and it didn't work? Okay, Sam, go. So we're here to commissorate on, like, how to actually build with the full spec. What are the hidden capabilities, why they matter, and how they light up. 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. It's all about, it's MCPs on high velocities, 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. 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. And just 10 days ago, on a Friday, we had actually this first in-real-life gathering of the MCP steering committee during the MCP Dev Summit. So that's how early it is. We haven't even met before. We just talked 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. And all the basics are kind of 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. There's roots in the client, there's sampling, there's prompts, and tools and resources. ### API Wrapper Syndrome **Harald Kirschner** [1:41] 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. There's this, like, MCP is just another API wrapper syndrome that's happening because people just want to ship. They want to build products and they're actually building really excellent products with just tools. And that creates this reinforcing loop because once you see how MCP works, you're just going to use the same stacks and repeat the same tools only ecosystem. And there's technical barriers. People do this because there's missing support in the clients and SDKs and documentation and the references. 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 because that's where the most immediate success is. And if you're honest, actually most of, like, resources and prompts, you can do similar flows just with tools. And VS Code, that's the same thing. 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 spec and implementing it. And I'm happy to announce that with VS Code's upcoming release v1.10, I'm going to get it wrong, but it's already in insiders now, so download it. We actually have the full spec support and that's I want to talk about here, about all the other things that people are not using yet. ### Full Spec Support **Harald Kirschner** [3:09] Yes, that's what I'm clapping. 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. Starting with the most obvious, tools. So not going too deep here, but tools reflect actions. Well-defined performing actions and mostly easy mapping to function calling if you're used to that. And on theright 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. 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 run wrong tools because you had too many. 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. ### Tool Challenges **Harald Kirschner** [4:04] It's too many domains of tools. 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. And lastly, it's just the repetition. The more repetitions the AI has to do to actually run tools to solve a problem, the easier it is to get confused as well. 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 picker and you can actually reduce down the tools of what you actually need in the moment versus all the tools. 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're like, pull this issue and try to, like, verb out whatever tool you're trying to invoke. Like, why not just use this tool and please make up all theright parameters to use it properly and then use the other tool. So that's what we allow as well. And then lastly, just in this insiders, actually we're shipping user-defined tool sets. And that's more of a 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 said, use my front-end testing flow. 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. But actually that spec has. Are going to give you these other tools. And on theright, you see GitHub MCP. 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 MCP installed. 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. So dungeon quality, 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. 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. Aware of tools 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. And the battle tool appears. I can battle the goblin. So imagine those, those MCP. Want to work on. Those are coming up to give servers and clients a little bit more. Really tools and actions. Actually the add context. Return a giant file from your server, but you want to return a reference to the file. ### Resources **Harald Kirschner** [6:43] And that could be something the LM could follow up on or the user can actually act upon. Then the other use case is actually giving files to the user. So if you take a screenshot via Playwright, it. Want to expose it to both the LM and the user and resources provide that semantic layer. And. You in. What are the issues? Oh, I found your issue. That's. They want to understand the Python environment and maybe look at your settings of how you set it up so they can customize. And that makes it more dynamic and stateful out of the box. 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? Like just, you work in my folder, so just look at it. 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. Sampling. Who has heard about sampling? It's really excited about sampling. Okay, so you understand what I mean. So sampling, sampling is one of the oddly named, uh, primitives as well. And if it had a better name, maybe more people would use it. ### Sampling **Harald Kirschner** [7:59] Uh, but it's actually now implemented insiders and it's so much fun to use. So it allows the server to request LM completions from the client. And what I'm showing here on theright is the permission dialog that pops up to allow the server to access the LM. Right now it's wired up by default to GPT-4.1. There's more spec improvements to make it more structured formatting. There's some ideas out there. So there's a lot of things to make it better, butright now nobody has implemented it. So there wasn't really need to make it better, but implementation is now here. So please use sampling. 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 into more tangible things. You can format a website that you fetch into Markdown for the LM. Or you can even think about agentic server tools that run via the LM from the client. 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 with dynamic discovery, you can update them at any time. The client will send new roots as the VS Code workspace changes. You can send new roots, uh, new servers, new tools and prompts from the server as you update and you change. So it's a really dynamic environment already. But there's more pain points to make these servers really powerful. 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. ### Dev Experience **Harald Kirschner** [9:34] Yeah. Yes, Sam. Apparently it's really easy, so maybe it's not a problem. Okay, so we have it now a dev mode in VS Code, which is a little dev toggle. And you already see the console that always works for all MCP servers. So once you hit a snack, that just works. And then now, now it's in debugging mode. 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. 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. So because VS Code is both, it can just put it into debug mode and attach its debugger. And that works for Python and Noderight now out of the box. So super exciting. And it's, yeah, it has changed how I work on MCPs definitely. The latest spec, uh, was already called out. I just want to 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. 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. ### Future Spec **Harald Kirschner** [10:54] So the updated auth spec on theright gives this enterprise grade authorization. There's a talk tomorrow about building protected MCP server that I can highly recommend from then who actually worked on the auth spec. So if you want to talk to one of the people behind it and want to 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. 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. SSE is still possible to use with HTTP, so you get both benefits, but you're avoiding this really stateful churn on your servers. 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? 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. So it's a big shout out to everybody on the steering committee, the community working groups, and everybody involved here. Um, if you want to check it out, it's on Model Context Protocol slash registry on GitHub. And it's all happening out in the open. And lastly, I'm really excited about elicitations. Um, that's actually coming in the next draft, um, spec reference, spec draft, release, whatever. And this is a way for tools to finally reach out back to the user when they need more information. 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 throw them into another chat experience and ask for it, but why not just give them an input to provide it directly? So it's, it's again more statefulness in the tools on top. ### Call to Action **Harald Kirschner** [12:46] So your help is needed. Um, progressive enhancement in MCP is possible. I think we want to have more best practices out there, maybe even in the references servers to show it off. But everything is now ready to be used. 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 these stateful servers can be and outline these best practices, this interoperability gap will close and clients will catch up. It's a very fast moving ecosystem. People are complaining like, oh, you shipped this two weeks after the other person. Um, but it's all coming together and as, as people use these and learn and bring feedback, it becomes better. 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 kind of see what's coming. Make sure they get into the SDKs you're using by following the issues and just share back on your experience. I mean, a lot of people mis-misunderstand how much influence they have on clients and SDKs and everything by filing issues, by providing feedback. 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. 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. 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. Thank you. --- This library is powered by PodHood (https://podhood.com), the podcast website platform.