151–160 of 281 posts
I was able to make a pretty complex MCP server in 2 days for LLM task delegation:
Does anyone have any prior art for an MCP server "message bus" with an agent framework like Mastra? E.g. suppose I want my agent to operate as Discord bot listening on channel via an MCP server subscribed to the messages. i.e. the MCP server itself is driving the loop, not the framework, with the agent doing the processing. I can see how this could be implemented using MCP resource pubsub, with the plugin and agent b…
Does all of the event stuff and state stuff for you. Plus the orchestration.
Today MCP added Streamable HTTP [0] which is a huge step forward as it doesn't require an "always-on" connection to remote HTTP servers. However, if you look at the specification it's clear bringing the LSP-style paradigm to remote HTTP servers is adding a bunch of extra complexity. This is a tool call, for example: { "jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": { "name": "get_weather", "arguments": {…
(1) an RPC to call a (remote) method called "tools/call", which is a method that
(2) calls a method called get_weather
Both methods have arguments. But the arguments of "tools/call" are called "params" and the arguments of "get_weather" are called "arguments".
I realize this is a common pattern when you have to shell out, e.g. in python's subprocess.run().
But it also seems like there could be a cleaner API with better types.
Earlier quoted context omitted.
This sounds like a security nightmare.
As it currently stands, MCP is absolutely a security nightmare. Combine this with a general lack of appreciation for security culture amongst developers, and the emerging vibe coding paradigm where non-security-minded people automatically generate and fail to properly audit production-facing code, and it's a disaster waiting to happen. Feels like we've slid back into the 90s in this regard. Great time to be a securit…
Today MCP added Streamable HTTP [0] which is a huge step forward as it doesn't require an "always-on" connection to remote HTTP servers. However, if you look at the specification it's clear bringing the LSP-style paradigm to remote HTTP servers is adding a bunch of extra complexity. This is a tool call, for example: { "jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": { "name": "get_weather", "arguments": {…
My bias is I generally think RPC is much nicer than REST. But what's kind of funny here is that we have (1) an RPC to call a (remote) method called "tools/call", which is a method that (2) calls a method called get_weather Both methods have arguments. But the arguments of "tools/call" are called "params" and the arguments of "get_weather" are called "arguments". I realize this is a common pattern when you have to she…
What I realized was that these specs are valuable because they’re stable over long periods of time and handle many sorts of edge cases. Also from a systems integration perspective, everybody already knows and is trained in them. Over many years I accepted the wisdom of commons.
A lot of tooling already exists to make development of these sorts of systems easy to implement and debug. Hence why I think for Remote MCP servers, HTTP as it exists is a great choice.
Earlier quoted context omitted.
Only a certain subset of developer spends most of their time "connecting things", and if that's the kind of developer you consider yourself, I'd be looking to either upskill or change professions as this will be the first kind of developer eliminated if we continue to see decent progress in automation.
Would disagree there — system integration probably accounts for like 90% of development work; just at different layers of abstraction. It’s evergreen work that companies are endlessly trying to eliminate or automate yet keep running headfirst into.
MCP is now the standard everyone must conform to. Couldn't possibly have predicted that 2 months ago.
Earlier quoted context omitted.
Would disagree there — system integration probably accounts for like 90% of development work; just at different layers of abstraction. It’s evergreen work that companies are endlessly trying to eliminate or automate yet keep running headfirst into.
I would urge you to not think this way: https://www.osmos.io/fabric