# Full Spec MCP: Hidden Capabilities of the MCP Spec Harald Kirschner, Microsoft/VS Code | AI Engineer World's Fair 2025 | 14:53 Source: https://www.youtube.com/watch?v=ExeD-8gFUMM Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/full-spec-mcp-hidden-capabilities-of-the-mcp-spec Published: 2025-07-18 Tags: debugging, mcp, tool-use ## TL;DR - MCP servers can provide stateful interactions when clients implement roots, resources, prompts, sampling, and dynamic tool discovery alongside tools. - Dynamic discovery can expose only the tools relevant to the user's current state, such as showing a battle tool only when a game character encounters a monster. - VS Code's full MCP implementation adds practical support for tool selection, workspace-aware roots, server debugging, sampling, and other features that are still underused. ## Summary Harald Kirschner argues that MCP is often used as a thin tool-calling layer because clients, SDKs, documentation, and examples do not yet cover the full specification. VS Code started with tools, then added discovery and roots, and its upcoming 1.10 release has full spec support. He demonstrates how dynamic tool discovery can adapt available actions to the current state of a dungeon game. Resources can give both the model and the user access to files, screenshots, project settings, and installed packages. Sampling lets a server request an LLM completion through the client, with a permission dialog. Kirschner also shows VS Code's developer mode, which provides console output and attaches a debugger to Python and Node MCP servers. He asks developers to try draft features, support streamable HTTP, use the community registry, provide feedback on SDKs and clients, and experiment with elicitations, which let tools request specific information directly from users. ## Key ideas ### MCP is often reduced to tools because the ecosystem makes the other primitives harder to use [01:35](https://www.youtube.com/watch?v=ExeD-8gFUMM&t=95s) Kirschner says many teams have fallen into an "MCP is just another API wrapper syndrome" because they want to ship products and tools provide immediate results. Clients, SDKs, documentation, and reference implementations have less support for the rest of the specification. Adoption therefore concentrates on tools, even though resources and prompts can sometimes be recreated with tool calls. VS Code followed the same path at first, launching MCP support with tools before adding discovery and roots. His point is about ecosystem maturity, not a criticism of MCP itself. The steering committee had only recently held its first in-person meeting, which he uses to show how early the project still is. ### Full spec support gives clients stateful interactions beyond ordinary function calling [02:51](https://www.youtube.com/watch?v=ExeD-8gFUMM&t=171s) Tools map fairly directly to actions and function calling, but Kirschner says the full MCP specification adds richer interactions. He describes roots in the client, sampling, prompts, tools, and resources as parts of a system that can keep track of context and state. VS Code's upcoming 1.10 release, already available in Insiders, supports the full specification. The practical difference is that a server and client can exchange changing context over time instead of presenting the model with one fixed list of functions. Kirschner frames this as the direction MCP describes for agents working together. ### Dynamic tool discovery can keep irrelevant actions away from the model [05:12](https://www.youtube.com/watch?v=ExeD-8gFUMM&t=312s) Kirschner demonstrates dynamic discovery with a GitHub Mud MCP dungeon crawler. A chat mode puts the agent into a game-master prompt, and the available actions change with the room. The agent can move, pick up items, and fight monsters, but the battle tool does not appear while no monster is present. When the character reaches a goblin, the battle tool becomes available. He contrasts this server-driven approach with manual tool selection, where users choose a tool pack or invoke a named tool. The example shows how a server can expose actions in response to the current state rather than publishing every possible action at once. ### Resources let servers share references and workspace facts with both the model and the user [06:22](https://www.youtube.com/watch?v=ExeD-8gFUMM&t=382s) Kirschner describes resources as a semantic layer for returning or exposing files. A server could give the model a reference to a large file for later follow-up instead of returning the whole file immediately. A Playwright screenshot could be made available to the language model and directly to the user. Resources can also expose the Python environment, settings, installed packages, and project structure. That information lets an assistant adapt to a React or Svelte setup and inspect the user's folder instead of repeatedly asking which framework or environment is in use. He also points to CI/CD data as another way MCP servers can connect an end-to-end developer workflow. ### Sampling lets a server request a model completion through the client [07:41](https://www.youtube.com/watch?v=ExeD-8gFUMM&t=461s) Sampling is an MCP primitive that allows a server to request an LLM completion from the client. VS Code's Insiders build implements it with a permission dialog, and it is wired by default to GPT-4.1 in the demonstration. Kirschner says structured formatting still needs spec work, but the basic implementation is ready for people to try. He describes sampling as a progressive enhancement. A server could return a large amount of material by default, then use sampling to summarize resources into something more useful, convert a fetched website into Markdown for the model, or support server tools that run through the client's model. ### VS Code's developer mode makes MCP server debugging practical [09:33](https://www.youtube.com/watch?v=ExeD-8gFUMM&t=573s) MCP servers are often launched and owned by the client and host process, which makes ordinary debugging difficult. VS Code addresses this with a development toggle, a console that works across MCP servers, and a debugger that can attach to the running server. In Kirschner's example, a prompt is generated dynamically on the server, a breakpoint is hit, and he steps through the code. He says this works out of the box for Python and Node. Because VS Code is both the client and the host in this setup, it can place the server in debug mode and attach its debugger. ### Draft features need real users before they become stable parts of the ecosystem [10:37](https://www.youtube.com/watch?v=ExeD-8gFUMM&t=637s) Kirschner asks developers to follow the latest MCP specification and test features that are still in draft. Draft features become stable when people report whether they are useful and whether they work. Without that feedback, a feature can move to stable while still needing revisions, as he says happened with the authorization specification. He also calls for adoption of streamable HTTP instead of relying only on SSE, while noting that SSE remains usable with HTTP. A community registry is being developed to make MCP server discovery easier, so server authors do not have to distribute JSON blobs manually. ### Elicitations can let tools ask users for specific missing information [12:06](https://www.youtube.com/watch?v=ExeD-8gFUMM&t=726s) Kirschner is excited about elicitations, which he says are coming in the next draft. Current tools are controlled by the language model, and a tool that needs a concrete user answer may have to send the user into another chat interaction. Elicitations would let the tool request that input directly. He presents this as another way to add statefulness to tool use. He closes by asking developers to use the full specification, read open RFCs such as namespaces and search, follow issues in their SDKs, and file feedback. He says the VS Code team reads incoming MCP issues and uses them to shape its roadmap. ## Notable quotes - "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." (01:34) - "So it's really quality over quantity and clients handle that somewhat." (04:12) - "Sampling is one of the oddly named primitives as well." (07:49) - "Everything is now ready to be used." (12:41) - "I think a lot of people misunderstand how much influence they have on clients and SDKs and everything by filing issues by providing feedback." (13:45) ## Tools & references mentioned - Model Context Protocol - VS Code - Microsoft - Playwright - LangChain - GitHub Mud MCP - GPT-4.1 - MCP steering committee - MCP community registry - streamable HTTP - SSE - Python - Node - React - Svelte ## Who should watch - You are building an MCP server with tools and want to understand what resources, roots, sampling, and dynamic discovery add. - Your MCP integration works, but tool overload, missing workspace context, or poor debugging makes it hard to use in practice. - You maintain an MCP client or SDK and want concrete examples of draft features and areas where implementation feedback is needed. ## Related talks - [Bending a Public MCP Server Without Breaking It](https://aietalks.com/talks/bending-a-public-mcp-server-without-breaking-it) (Nimrod Hauser, Baz, 40:50) - [MCP is all you need](https://aietalks.com/talks/mcp-is-all-you-need) (Samuel Colvin, Pydantic, 15:24) - [MCP Apps: Primitives, Discovery, and the Future of Software](https://aietalks.com/talks/mcp-apps-primitives-discovery-and-the-future-of-software) (Pietro Zullo, Manufact, Inc, 28:54) - [The State of MCP Observability: Observable.tools](https://aietalks.com/talks/the-state-of-mcp-observability-observable-tools) (Alex Volkov, Weights & Biases & Benjamin Eckel, Dylibso, 16:56) - [The Future of MCP](https://aietalks.com/talks/the-future-of-mcp) (David Soria Parra, Anthropic, 18:46)