AI Engineer World's Fair 2025
Full Spec MCP: Hidden Capabilities of the MCP Spec — Harald Kirschner, Microsoft/VS Code
Read the talk
Full Spec MCP: Building Servers That Respond to Context
MCP can do more than expose functions: dynamic discovery, resources, sampling and user input let servers adapt as a task and its context change.
From a talk by Harald Kirschner
Before you start: You should be familiar with MCP clients and servers, model tool calling, and basic Python.
Why does an MCP server fail to work?
Who has built an MCP server and found that it did not work? That opening question reaches beyond connection errors. A server can expose valid tools and still leave the model choosing the wrong action, missing relevant context or struggling through an interaction that the protocol could support more directly. Harald Kirschner approaches that problem from his work on VS Code and local development, with lessons that apply beyond the IDE.
The ecosystem in this recording is still forming its working practices. Kirschner describes its first in-person MCP steering committee gathering as having happened ten days earlier, after collaboration largely through Discord. The missing pieces are opportunities for implementation and feedback, rather than evidence that the specification has failed.
MCP already includes roots, sampling, prompts, tools and resources. Together, these support dynamic discovery, persistent resources and richer interactions. Yet the fastest path to a useful product is often to wrap an API in tools. Successful products establish examples that other developers copy, reinforcing a tools-only ecosystem. Missing support in clients, SDKs, documentation and reference implementations makes that choice harder to escape.
Tools can approximate some prompt and resource workflows, so starting there is understandable. VS Code did the same: its initial MCP implementation concentrated on tools, with discovery and roots already included. Kirschner then announces broader specification support in Insiders and an upcoming release, documented in the VS Code 1.101 release notes. This is the historical implementation context of the demonstrations; experimental sampling and later draft additions should not be read as a claim that every future capability was already shipped. The goal is richer, stateful interactions, not merely a larger inventory of callable functions.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Give the model the tools it needs now
Tools represent actions and map naturally to function calling. In the Playwright example, a server opens a browser and takes a screenshot. But adding more tools does not automatically improve the model’s ability to complete a task: the IDE may reject the inventory, or the model may select an inappropriate action.
Kirschner points to LangChain research on three sources of difficulty: tool count, the diversity of domains and instructions, and repeated tool-use steps. Benchmarking Single Agent Performance examines these pressures in a particular ReAct assistant, rather than establishing a universal tool-count limit. A focused UI-testing tool set gives the model a more coherent task environment than a mixture of unrelated actions, properties and instructions. Longer sequences also give it more opportunities to lose track of the task.
VS Code exposes several ways to narrow or direct tool use:
| Control | What it changes |
|---|---|
| Per-chat tool picker | Limits the tools available in the current session |
| Explicit tool mentions | Names the intended action while the model supplies parameters |
| User-defined tool sets | Saves a reusable selection, such as front-end testing tools |
The picker supports keyboard interaction and preserves the selection for the session. Tool sets make the same decision reusable: once the relevant testing tools are identified, the user can invoke that collection without rebuilding it for every conversation. These controls put quality of selection ahead of quantity of exposure.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make available actions follow the game state
Manual selection is only one way to control the tool inventory. Dynamic discovery lets the server change the tools it exposes while an interaction is underway. In the dungeon crawler demonstration, a custom chat mode gives the agent a game-master prompt. The user switches to the MUD mode and begins playing; the server adapts the available actions to the current room.
The player can move between rooms, travel east or north, and pick up items. Fighting makes sense only when a monster is present, so the battle tool should be absent in an empty room. When the player eventually encounters a goblin, the battle tool appears. Availability expresses the game’s current state instead of requiring the model to infer that an always-visible action is temporarily invalid.
The selection rule can be expressed directly in Python. This small example isolates the inventory decision: entering the goblin encounter exposes battle; it does not execute a battle.
python
from dataclasses import dataclass
@dataclass(frozen=True)
class Room:
exits: tuple[str, ...]
items: tuple[str, ...] = ()
monster: str | None = None
def available_tools(room: Room) -> list[str]:
tools = []
if room.exits:
tools.append("move")
if room.items:
tools.append("pick_up")
if room.monster is not None:
tools.append("battle")
return tools
empty_room = Room(exits=("east", "north"))
goblin_room = Room(exits=("east", "north"), monster="goblin")
assert available_tools(empty_room) == ["move"]
assert available_tools(goblin_room) == ["move", "battle"]
The MCP integration must expose the changed inventory through discovery so the client can make the new action available to the model. The useful boundary is between an action becoming possible and the agent choosing to perform it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Expose artifacts and understand the workspace
An action may produce context without needing to place all of it in the immediate tool response. Instead of returning a giant file, a server can return a reference that the model follows when needed or that the user acts on directly. Resource links in tool results were still prospective here and subsequently appeared in the June 2025 specification revision.
Resources give artifacts meaning beyond a text response. A screenshot captured through Playwright should be accessible to both the model and the user. Treating it as a resource preserves that shared role: the artifact is something to inspect or use, rather than merely content buried inside an action’s output.
A development server can also adapt to information already present in the workspace. It can inspect the Python environment and settings, then use installed packages and libraries to distinguish a React project from a Svelte project. This avoids repeatedly asking the user to identify a framework that the project itself reveals. Reading CI/CD configuration extends the same approach through the delivery pipeline, connecting local development with the rest of the workflow.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Request model work through the client
Sampling lets an MCP server request an LLM completion from the client. The sampling specification calls this operation sampling/createMessage. “From the client” identifies who mediates access; it does not require the model to run locally. In the demonstration, VS Code displays a permission dialog before allowing the server to access the model. Kirschner identifies GPT-4.1 as that implementation’s default, not a protocol requirement. The client retains control over model selection and permissions.
Structured formatting for sampling is described as further specification work. That distinction matters because a server requesting a completion still needs to handle the response format its client supports; later structured tool output is a separate capability.
Sampling provides a natural path to progressive enhancement:
- Summarize resources: turn a large resource into a more focused representation instead of always returning everything.
- Prepare fetched content: convert a website into Markdown suitable for the model’s next step.
- Run agentic server tools: let a server’s workflow request model work through the client.
The server can supply useful content without sampling, then perform additional processing when the client supports it. This makes model access an enhancement to the interaction rather than an assumption hidden inside every tool.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keep both sides of the connection current
The dungeon’s changing tool set is one instance of a broader pattern. Roots, resources, tools and prompts participate in an interaction whose context can change after the connection begins.
| Origin | What changes |
|---|---|
| Client | Workspace roots as the VS Code workspace changes |
| Server | Available resources, tools and prompts as server state changes |
Discovery therefore needs to be treated as an ongoing exchange, not just an initial inventory. The client keeps the server informed about the workspace, while the server keeps the client informed about what it can currently provide.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Debug the process the host launches
Richer server behavior also needs a workable development loop. VS Code provides an MCP server console for diagnostic output, then adds a development-mode toggle that enables debugger attachment. In the demonstration, invoking a prompt generated by the server reaches a breakpoint in its implementation.
The difficulty is process ownership: an MCP server is often launched by its client or host, rather than by a command the developer starts manually under a debugger. VS Code occupies both roles, so it can launch the server and attach its debugger. The historical automatic debugging support covers Node.js and Python servers launched with node and python, respectively.
That turns debugging into a direct loop:
- Enable development mode for the server.
- Set a breakpoint in the server implementation.
- Invoke the server-generated prompt from chat.
- Step through the handler and inspect its state.
The important improvement is that the interaction being debugged comes from the actual MCP host, rather than requiring a separate manual reproduction of the server call.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Exercise authorization and transport before they harden
Draft specifications need implementation feedback before they become stable. Otherwise, a feature can advance without enough real use to expose its problems, leaving a later revision to repair them. Kirschner uses authorization as the example and characterizes its update as enabling enterprise-grade authorization. He points to Ben’s protected-server session for a deeper discussion.
Transport support has a similar dependency on adoption. Kirschner says VS Code had supported Streamable HTTP for two releases, but the small number of hosted servers using it made interoperability difficult to test. His recommendation to hosting providers is to move from the older HTTP+SSE transport to Streamable HTTP.
This is not a recommendation to abandon SSE itself. The Streamable HTTP transport specification retains optional SSE streaming and permits stateful sessions. The distinction is between the older transport arrangement and the newer HTTP-based one, not between streaming and non-streaming, or stateful and inherently stateless servers. Kirschner’s stated operational benefit is avoiding the older arrangement’s stateful server churn.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Help users find servers and supply missing information
Discovery also has a meaning outside an active connection: how does a user find a server in the first place? Passing configuration JSON blobs from developer to user is a cumbersome distribution mechanism. The community MCP Registry is presented as public work toward making servers easier to discover. This complements dynamic capability discovery: one helps users find a server; the other helps a connected client understand what that server currently offers.
Once a tool is running, another gap can appear: the model has supplied arguments, but the workflow still needs concrete information from the user. Elicitation, presented here as an upcoming draft capability and later included in the June revision, lets the server reach back for that information. Instead of sending the user into another chat experience, the client can offer a direct input interaction. The tool workflow can then continue with information supplied by the person who actually knows it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make richer implementations useful enough to spread
Progressive enhancement gives server authors a way to build beyond tools without waiting for every client to catch up. Implement richer behavior in clients that support the relevant capabilities, test it with real users, and publish examples that show why stateful interactions are useful. Reference servers and shared practices can turn isolated implementations into patterns other developers can adopt. As users demonstrate those benefits, they create demand for missing client support.
The design target is an action-oriented server that understands context and exposes meaningful artifacts. Contributing to that target includes reading open proposals such as namespaces and search, following the corresponding SDK issues, and reporting implementation experience. Kirschner emphasizes that this feedback has practical influence: the VS Code team reads incoming MCP issues and uses them to shape its roadmap.
Sampling is his final example of a capability worth asking clients to support. The remaining work is not only to extend the specification, but to make its existing capabilities usable across implementations. A server that demonstrates a better interaction—and supplies concrete feedback when a client cannot support it—helps close that gap.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
The March 2025 protocol contract for servers requesting model generations through clients, including permissions and model preferences.
Streamable HTTP's request flow, optional SSE streaming and session management in the March 2025 specification.
The community registry project for publishing and discovering MCP servers.
Further reading
Historical release documentation for MCP prompts, resources, experimental sampling, tool sets and server debugging.
A dungeon game server illustrating tools that appear as game state changes, alongside resources, prompts and sampling.
LangChain's experiments on how additional tools and instructions affect a ReAct assistant's calendar and customer-support tasks.
Updates since the talk
- MCP June 2025 specification changesDocumentation
The subsequent specification revision adding elicitation, resource links, structured tool output and revised authorization requirements.
Read the complete timestamped transcript
- 0:00
[upbeat music] Since all the questions already got asked, who built an MCP server and it didn't work?
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 2:11
People do this because there's missing support in the clients and SDKs and documentation and the references.
- 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.
- 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-
- 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.
- 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.
- 3:08
Whoo, whoo.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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...
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 7:10
And that makes it more dynamic and stateful out of the box.
- 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?"
- 7:28
Like, just you, you work in my folder, so just look at it.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 9:18
So it's a really dynamic environment already. But there's more pain points to make these servers really powerful.
- 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]
- 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.
- 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.
- 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.
- 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.
- 10:22
So super exciting. And it's, yeah, it has changed how I work on MCPs, definitely.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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?
- 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.
- 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.
- 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.
- 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?
- 12:39
So it's, it's again, more statefulness in the tools on top.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 14:46
Thank you. [outro music]