141–150 of 194 posts
Earlier quoted context omitted.
How are skills vendor lock-in when they're just Markdown files that any LLM can read? You are not locked to Anthropic at all.
The API runs your skills, it's not client side coordinated. You have to replicate the skill-running behavior locally.
I can see where Mario is coming from, but IMO MCP still has a place because it 1) solves authentication+discoverability, 2) doesn't require code execution. MCP shines when you want to add external functionality to an agent quickly, and in situations where it's not practical to let an agent go wild with code execution and network access. Feels like we're in the "backlash to the early hype" part of the hype cycle. MCP…
Oh, I didn't intend this to come across as MCP being useless. I've written this from the perspective of someone who uses LLMs mostly for coding/computer tasks, where I found MCP to be less than ideal for my use cases. I actually think MCP can be a multiplier for non-technical users, where it not for some nits like being a bit too technical and the various security footguns many MCP servers hand you.
Earlier quoted context omitted.
The hate for MCP here is absurd. It's JSON-RPC, with some descriptors. And some comments about OAuth 2. The value is in the consensus. You can make a tool that agents can connect to with no apriori knowledge.
>It's JSON-RPC, with some descriptors. That's not even true. It defines the lifecycle of tool calling. JSON-RPC with some descriptors would have been fine and amazing.
Earlier quoted context omitted.
> They have zero trained data on MCP. They have significant data trained on MCP. > They know how to function & tool call. Right. You can either use MCP to transmit those tool calls, or you can create some other interface.
>They have significant data trained on MCP. No they don't lol.
MCP has been popular for well over a year.
To filter it out of the training data would be laughable.
Earlier quoted context omitted.
> MCP was a really shitty attempt at building a plugin framework Can you go more in depth? The protocol is relatively simple, what about it you feel is "shitty" as a plugin framework?
The hate for MCP here is absurd. It's JSON-RPC, with some descriptors. And some comments about OAuth 2. The value is in the consensus. You can make a tool that agents can connect to with no apriori knowledge.
Also, MCP creates a new problem: providing the model with too much context when trying to combine tools across multiple servers. It works OK with small, very focused servers (like helpers for a specific data set), but if you try to mix and match servers things get out of hand really quickly and the entire workflow becomes very unreliable—too many options to digest and pursue, just like humans.
Earlier quoted context omitted.
MCP is simply a standardized RPC protocol for LLMs. That's it. The value is in all the usual features of standardization -- plug-and-play, observability, pass-through modifications, etc.
>observability Which MCP does the opposite of. It hides information.
You have some weird bone to pick with MCP which is making you irrationally unreceptive to any good-faith attempt to help you understand.
If you want to expose tools to the LLM you have to provide a tool definition to the LLM for each tool and you have to map the LLM's tool calls into the agent executing the tools and returning the results. That's universal for all agent-side tools.
The whole purpose behind MCP was to provide a low-impedance standard where some set of tools could be plugged into an existing agent with no pre-knowledge and all the needed metadata was provided to facilitate linking the tools to the agent. The initial version was clearly focused on local agents running local tools over stdio. The idea of remote tools was clearly an afterthought if you read the specification.
If you want your agent to speak OpenAPI, you are *more* than welcome to make it do so. It'll probably be fine if it's a well-specified API. The context issues won't go away, I guarantee you. OpenAPI specs for APIs with lots of endpoint will result in large tool definitions for the LLM, just like they do with MCP.
A core issue I see with MCP, as someone using it every day, is that most MCP Server developers clearly are missing the point and simply using MCP as a thin translation layer over some existing APIs. The biggest value with MCP is when you realize that an MCP Server should be a *curated* experience for the LLM to interact with and the output should be purposefully designed for the LLM, not just a raw data dump from an API endpoint. Sure, some calls are more like raw data dumps and should have minimal curation, but many other MCP tools should be more like what the OP of this post is doing. The OP is defining a local multi-step workflow where steps feed into other steps and *don't* need LLM mediation. That should be a *single* MCP Server Tool. They could wrap the local bash scripts up into a simple single tool stdio MCP Server and now that tool is easily portable across any agent that speaks MCP, even if the agent doesn't have the ability to directly run local CLI commands.
Anyway, maybe take a breath and be objective about what MCP is and is not meant to do and disconnect what MCP is from how people are *currently* using (and frequently misusing) MCP.
So far I have seen two genuinely good arguments for the use of MCPs: * They can encapsulate (API) credentials, keeping those out of reach of the model, * Contrary to APIs, they can change their interface whenever they want and with little consequences.
> * Contrary to APIs, they can change their interface whenever they want and with little consequences. I already made this argument before, but that's not entirely right. I understand that this is how everybody is doing it right now, but that in itself cause issues for more advanced harnesses. I have one that exposes MCP tools as function calls in code, and it encourages the agent to materialize composed MCP calls in…
Yeah, I'm still confused as to why so many people in "AI engineering" seem to think that MCPs are the key to everything. They are great if you have a UI that you want and it needs a plugin system, obviously. But the benefits become much more marginal for a developer of enterprise AI systems with predefined tool selections. They are actually getting overused in this space, if anything, sometimes with security as a pri…
If you have that nice Agent and suddenly marketing "needs" it to talk to Super Service A, you either go back into a dev cycle to create a new set of curated tools that live inside the Agent around SSA *or* you make the Agent capable of acting as an MCP Host and configure a new MCP Client connection to an MCP Server offered by the SSA team. If SSA doesn't have their own MCP Server you could potentially leverage a 3rd-party one or write your own as a fully encapsulated project that doesn't live inside the Agent.
MCP isn't meant to be *the* way you provide tools for your Agent, it's meant to prove a *standard* that allows you to easily add off-the-shelf tool sets via simply configuring the Agent.
MCP is just an API with docs.
The problem isn’t MCP itself. It’s that each MCP “server” has to expose every tool and docs which consumes context.
I think the tools should use progressive reveal and only give a short summary like the skill does. Then agent can get full API of the tool on request.
Right now loading GitHub MCP takes something like 50k tokens.
Earlier quoted context omitted.
[flagged]
What do all of the links below have in common? Do you know of another way you can control all of those applications via LLMs? Computer use? https://github.com/ahujasid/ableton-mcp https://github.com/ahujasid/blender-mcp https://github.com/CoplayDev/unity-mcp https://github.com/mikechambers/adb-mcp
I mean you just took some examples and went "See MCP!" without any actual understanding of what that code is doing.
All of these have underlying API's that have exactly ZERO need for MCP. All of this functionality already exists and can be used with LLM's.
* https://help.ableton.com/hc/en-us/articles/209072009-Install...
* https://docs.blender.org/api/current/info_quickstart.html
* https://docs.unity3d.com/6000.2/Documentation/ScriptReferenc...
The most hilarious quote from one of those projects:
>The proxy server is required because the public facing API for UXP Based JavaScript plugin does not allow it to listen on a socket connection (as a server) for the MCP Server to connect to (it can only connect to a socket as a client).
Maybe that should have been the sign that this was completely unnecessary and stupid?
>Do you know of another way you can control all of those applications via LLMs?
Seriously. This becoming a bad joke. I mean conceptually, what did you think was happening here? MCP was just magically doing something that didn't already exist before?
It's a waste of effort and time. Do not use MCP.