121–130 of 149 posts
I'm getting tired of everyone saying "MCP is dead, use CLIs!". Yes, MCP eats up context windows, but agents can also be smarter about how they load the MCP context in the first place, using similar strategy to skills. The problem with tossing it out entirely is that it leaves a lot more questions for handling security. When using skills, there's no implicit way to be able to apply policies in the sane way across many…
One of the MCP Core Maintainers here, so take this with a boulder of salt if you're skeptical of my biases. The debate around "MCP vs. CLI" is somewhat pointless to me personally. Use whatever gets the job done. MCP is much more than just tool calling - it also happens to provide a set of consistent rails for an agent to follow. Besides, we as developers often forget that the things we build are also consumed by non-…
Earlier quoted context omitted.
There is not a lot to learn to understand the basics, but maybe one step that's not necessarily documented is the overall workflow and why it's arranged this way. You mentioned the LLM "using web search" and it's a related idea: LLMs don't run web searches themselves when you're using an MCP client, they ask the client to do it. You can think of an MCP server as a process exposing some tools. It runs on your machine…
Maybe it's because of the example, but if the LLM knows the GitHub CLI and I bet it knows it, shouldn't it be able to run the commands (or type them for us) to count the open PRs on foo/bar? However I see the potential problem of the LLM not knowing an obscure proprietary API. The traditional solution has been writing documentation, maybe on a popular platform like Postman. In that case the URL of the documentation c…
Where it comes in handy has mostly been in distribution honestly. There's something very "open apis web era" about MCP servers where because every company rushed to publish them, you can write a lot of creative integrations a bit more easily.
Much easier:
{ action: 'help' }
{ action: 'projects.help' }
{ action: 'projects.get', payload: { id: xxxx-xx-x } }
There are other interesting capabilities though, like built in permissions based on HTTP verb, that might be useful to someone.
We built a unified API with a large surface area and ran into a problem when building our MCP server: tool definitions alone burned 50,000+ tokens before the agent touched a single user message. The fix that worked for us was giving agents a CLI instead. ~80 tokens in the system prompt, progressive discovery through --help, and permission enforcement baked into the binary rather than prompts. The post covers the benc…
How is progressive discovery not more expensive due to the increased number of steps?
Why not run the discovery (whether MCP or CLI) in a subagent that returns only the relevant tools. I mean, discovery can be done on a local model, right?