> modern MCP clients do smart tool search that obviates the entire "I am sending the full list of tools back and forth" mode of operation
This has always surprised me as this always comes up in MCP discussions.
To me, it just seem like a matter of updating the protocol to not have that context hungry behaviour. Doesn't seem like an insurmountable problem technically.
Glad you say it has already been addressed. Was the protocol itself updated to reflect that? Or are you just referring to off-spec implementations?
The idea that all customer data will be deleted is far fetched, but I feel like there have been some massive incidents. Crowdstrike comes to mind, but I feel its entirely possible that Apple/Google/etc could push out some kind of config update which bricks phones in a way they are unable to download another update to fix them.
Though I'm sure the major players are all over this risk which is why it hasn't happened.
I'm not sure how much sandboxing can help here. Presumably you're giving the tool access to a repo directory, and that's where a juicy .env file can live. It will also have access to your environment variables.
I suspect a lot of people permanently allow actions and classes of commands to be run by these tools rather than clicking "yes" a bunch of times during their workflows. Ride the vibes.
That’s exactly what it is in essence.
The MCP protocol simply doesn’t have any mechanism specifications (yet) for not loading tools completely in the context.
There’s nothing really strange about it. It’s just a protocol update issue.
The MCP standard will and has to evolve to address this context issue. It’s a no brainer and this is a perfect example of the direction mcp is going / will go.
There’s fundamentally nothing wrong, it’s just protocols updates that have to occur.
I'm struggling with this right now. 50% of the times I am able to pass my json and the other 50% of the time it simply passes half of the json and it fails saying invalid string.
In also interested in n8n. From what I gathered it’s a everything baked in app, not a lib. Meaning that unless you re doing upstream contributions you don’t actually code anything. Just manage big configs. How are you planning to use this toolkit with it?
I don't really see why they had to create a different concept. Maybe makes sense "marketing-wise" for their chat UI, but in Claude Code? Especially when CLAUDE.md is a thing?
MCP Prompts are meant to be user triggered, whereas I believe a Skill is meant to be an LLM-triggered, use-case centric set of instructions for a specific task.
- MCP Prompt: "Please solve GitHub Issue #{issue_id}"
- Skills:
- React Component Development (React best practices, accessible tools)
- REST API Endpoint Development
- Code Review
This will probably result in:
- Single "CLAUDE.md" instructions are broken out into discoverable instructions that the LLM will dynamically utilize based on the user's prompt
- rather than having direct access to Tools, Claude will always need to go through Skill instructions first (making context tighter since it cant use Tools without understanding \*how\* to use them to achieve a certain goal)
- Clients will be able to add infinite MCP servers / tools, since the Tools themselves will no longer all be added to the context window
It's basically a way to decouple User prompts from direct raw Tool access, which actually makes a ton of sense when you think of it.
I see this as a lower overhead replacement for MCP. Rather than managing a bunch of MCP's, use the directory structure to your advantage, leverage the OS's capability to execute
Narrowly focused semantics/affordances (for both LLM and users/future package managers/communities, ease of redistribution and context management:
- skills are plain files that are injected contextually whereas prompts would come w the overhead of live, running code that has to be installed just right into your particular env, to provide a whole mcp server. Tbh prompts also seem to be more about literal prompting, too
- you could have a thousand skills folders for different softwares etc but good luck with having more than a few mcp servers that are loaded into context w/o it clobbering the context
reply