Search for a command to run...
I have been in the Engineering space for over 15 years working on SRE principals of Observability, Eliminating Toil, and Streamlining Processes to reduce risk.
No comments yet. Be the first to comment.
As I am getting more into working with AI agents through the use of AI powered environments. I set out this weekend to make an MCP server to help with local environment management but it ended with a mountain of research.
I researched the MCP spec https://modelcontextprotocol.io/specification/2025-06-18 to learn what it could do. What tools did I have in my tool chest to build with. I was off with a plan of all the cool things I could build and the features that would help my users and really make mine stand out.
This was going great until it was time to test and nothing worked. All the advanced things I coded were not even getting processed in Windsurf and after debugging I find that Windsurf doesn't support the feature I need that is clearly defined in the spec.
Now knowing that Windsurf didn't support the roots call maybe I would look into the leader in this area — the one whose engineers created the spec — Claude Code. To my utter astonishment they don't support the entire set of MCP features.
Looking at a few resources that track the adoption of these features I was blown away that almost EVERY AI tool has only selected a few features to implement.
However one provider stood out — VS Code. They even published a post saying they finally implemented the full spec. https://code.visualstudio.com/blogs/2025/06/12/full-mcp-spec-support
Adoption according to mcp-availability.com (community-tracked, self-reported — if you have a better source I'd genuinely love to see it):
tools - 100%
resources - 39%
prompts - 38%
discovery - 19%
sampling - 12%
elicitation - 11%
roots - 8%
When we look into the spec it turns out this fragmentation is intentional. The spec explicitly separates what servers can offer from what clients may support:
From https://modelcontextprotocol.io/specification/2025-06-18#features:
"Servers offer any of the following features to clients: Resources, Prompts, Tools"
"Clients may offer the following features to servers: Sampling, Roots, Elicitation"
The words "any" and "may" are doing a lot of work there. Nothing is mandatory. A client that only implements tool calls is fully spec-compliant. So the protocol just says use whatever you want but you have no obligation to support all of it.
The handshake does let clients publish what they support, but there's a gap — clients declare what they offer to servers (roots, sampling, elicitation), but nothing in the handshake tells the server whether the client will actually use the server's resources, react to dynamic tool updates, or read anything beyond a basic tool response. There's an open proposal (SEP-1381) trying to fix this by letting both sides declare what they actually intend to consume, not just what they technically support.
All of this boils down to the lowest common denominator effect where if you want to build a server with the most support you target the base tools that are most commonly supported. Anything else and you're mostly coding for a specific environment or VS Code users.
Anthropic created this spec and their own flagship products don't implement it fully. Claude Desktop explicitly states in their own docs it does not support sampling. Claude Code is better but still missing features. Meanwhile VS Code shipped full spec support and documented it. If you want to actually use MCP to its fullest today, VS Code is where you should be.
I'm starting to think the real solution isn't waiting for every IDE to implement the full spec.
I think I have my next project...