Don't write MCP off yet. The protocol is fine. The way teams use it is where things fall apart. MC...
- MCP在工具定义过多时易导致上下文窗口耗尽。
- Skills可作为轻量级解决方案，但需额外编写脚本支持复杂功能。
- 结合Skills和MCP能有效解决发现和执行问题。
MCP's actual problems are pretty specific. Load 50 tool definitions into context and the agent struggles to pick the right one. Your context window fills up before the real work https://t.co/6PHLKyu6IS" / X
Post
Conversation
Don't write MCP off yet. The protocol is fine. The way teams use it is where things fall apart. MCP's actual problems are pretty specific. Load 50 tool definitions into context and the agent struggles to pick the right one. Your context window fills up before the real work starts. And half the time, the "tool" is just a wrapper around a playbook that didn't need to be a running service at all. Skills aren't a perfect answer either. They're lightweight, they load only when relevant, and they're easy to update. But if you want Skills to do anything beyond talk, you end up writing the scripts yourself. Auth, retries, rate limits — none of it comes for free with a Markdown file. The smarter setup is to let them cover for each other. 𝗦𝗸𝗶𝗹𝗹𝘀 𝗯𝗲𝗰𝗼𝗺𝗲 𝘁𝗵𝗲 𝗯𝗿𝗮𝗶𝗻. 𝗠𝗖𝗣 𝗯𝗲𝗰𝗼𝗺𝗲𝘀 𝘁𝗵𝗲 𝗵𝗮𝗻𝗱𝘀. What's worked for us is letting a Skill reference MCP tool names directly, so the knowledge layer can orchestrate the capability layer. Skills do the reasoning, MCP does the doing. That combo fixes both sides. MCP's discovery problem goes away because the Skill already knows which tool to call. And Skills stop needing a pile of custom scripts for every live system they touch. If you're standing up a whole server just so the AI knows a process, stop. You probably need a few Markdown files instead.
