I don't think this is correct because AI output can be constrained to a fixed format (such as JSON) during inference. Then MCP is useful because the "tool_calls" section of that fixed JSON output can be restricted to only mention tools that are included in the MCP input, their input parameters might also be constrained etc. Free text input wouldn't give you any of that!
Yeah, and it's only useful if uiu want to to use multiple tools and the adding MCP complexity in your app makes sense. If all your app needs few internal calls, MCP may be an overkill in beginning.
MCP seems just like a rushed concept that Anthropic shoved out there just so they could own the standard. I've been working with it a lot lately, in Go with mcp-go[0]. Very un-intuitive at first, and I constantly ask myself why I wouldn't just write this in my own way, but admittedly it can be fun.
I've been building agents for a bit (RA.Aid OSS coding agent, now Gobii web browsing agents).
The main problem with MCP is that it just makes tools available for the agent to use. We get the best performance when there's a small set of tools and we actively prompt the agent on the best way to use the tools.
Simply making more tools available can give the agent more capabilities, but it can easily trash performance.
The question I’m wrestling with is will anybody care about MCP? I’m working on my own MCP proxy to manage security, auditing, and server management and the more I think deeply about the actual use cases the more I wonder if I’m wasting my time.
Can anyone think of a world where MCP is relevant if generic chatbots (ChatGPT, Claude Desktop) don’t become the primary human-AI interface? If LLMs are still wrapped in application wrappers, isn’t ̶a̶n̶ ̶a̶p̶p̶r̶o̶a̶c̶h̶ ̶l̶i̶k̶e̶ ̶L̶a̶n̶g̶C̶h̶a̶i̶n̶ a more traditional agentic approach going to make more sense?
Something like containerized apps are going to be important for security with MCPs or whatever it becomes, comes from it, or comes afterwards.
Getting in reps on thinking through these kinds of problems are valuable since LLMs are a new type of software and existing software axioms don't always fit.
> But here’s the important part: LLMs don’t know how to use tools. They don’t have native tool calling support. They just generate text that represents a function call.
This terrifies me. This whole time I was writing bash commands into my terminal, I thought I knew how to use the tools. Now, I’ve just learned that I had no idea how to use tools at all! I just knew how to write text that /represented/ tool use.
If you're a large org with an API that an ecosystem of other partners use then you should host a remote MCP and then people should connect LLMs to it.
The current model of someone bundling tools into an MCP and then you download and run that MCP locally feels a bit like the wrong path. Tool definitions for LLMs are already pretty standardized if things are just running locally why am I not just importing a package of tools, I'm not sure what the MCP server is adding.
> "Context engineering is about giving your LLM the right inputs so it can generate useful outputs."
No.
If we're going to elevate and reimagine new disciplines every year (RIP prompt engineering), let's at least be thoughtful about it.
Context Engineering is not just "enhanced prompt engineering".
It is creating the context in which an agent operates such that its outcomes are realized.
Yes, this is partly about the input that an agent receives, but increasingly is more about creating a context-rich environment that an agent can effectively determine relevant context within.
That is a much more valuable and difficult problem space than "Shove the square context in the square hole"
I've been building MCP servers so I can grant local LM Studio LLMs access to the internet and to my local files. The way I've been thinking about MCP has been how you unshackle the local models as I believe the future will be inference at the edge. Just look at Rednote dots.ocr, that thing is like 1.7b parameters and is the best OCR out there.
> But here’s the important part: LLMs don’t know how to use tools. They don’t have native tool calling support. They just generate text that represents a function call.
Its not a completely true statement. Eg openAI uses libraries like llguidance to get LLM to produce structured output, its not completely unguided free form text that happens to mimic a function call with parameters, truly.
19 comments
[ 2.5 ms ] story [ 48.8 ms ] threadso it seems kind of pointless. I would imagine it could ingest soap or a module definition or swagger just as easily and still make calls.
Something like https://github.com/simonw/llm seems way more intuitive (to me)
[0]: https://github.com/mark3labs/mcp-go
The main problem with MCP is that it just makes tools available for the agent to use. We get the best performance when there's a small set of tools and we actively prompt the agent on the best way to use the tools.
Simply making more tools available can give the agent more capabilities, but it can easily trash performance.
Getting in reps on thinking through these kinds of problems are valuable since LLMs are a new type of software and existing software axioms don't always fit.
Write a restapi, add a description field.
done.
And as replacements for AppleScript, COM Automation, and friends on desktop systems.
This terrifies me. This whole time I was writing bash commands into my terminal, I thought I knew how to use the tools. Now, I’ve just learned that I had no idea how to use tools at all! I just knew how to write text that /represented/ tool use.
If you're a large org with an API that an ecosystem of other partners use then you should host a remote MCP and then people should connect LLMs to it.
The current model of someone bundling tools into an MCP and then you download and run that MCP locally feels a bit like the wrong path. Tool definitions for LLMs are already pretty standardized if things are just running locally why am I not just importing a package of tools, I'm not sure what the MCP server is adding.
No.
If we're going to elevate and reimagine new disciplines every year (RIP prompt engineering), let's at least be thoughtful about it.
Context Engineering is not just "enhanced prompt engineering".
It is creating the context in which an agent operates such that its outcomes are realized.
Yes, this is partly about the input that an agent receives, but increasingly is more about creating a context-rich environment that an agent can effectively determine relevant context within.
That is a much more valuable and difficult problem space than "Shove the square context in the square hole"
Its not a completely true statement. Eg openAI uses libraries like llguidance to get LLM to produce structured output, its not completely unguided free form text that happens to mimic a function call with parameters, truly.