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:
Which traditionally would just be HTTP POST to `/get_weather` with `{ "location": "New York" }`.
I've made the suggestion to remove some of this complexity [1] and fall back to just a traditional HTTP server, where a session can be negotiated with an `Authorization` header and we rely on traditional endpoints / OpenAPI + JSON Schema endpoint definitions. I think it would make server construction a lot easier and web frameworks would not have to materially be updated to adhere to the spec -- perhaps just adding a single endpoint.
MCP is just too complex for what it is supposed to do. I don't get what's the benefit. It is the kind of thing that has the potential to be a huge time waste because it requires custom dev tools to develop and troubleshoot.
It is not even a protocol in the traditional sense - more of a convention.
And of course we will implement it, like everyone else, because it is gathering momentum, but I do not believe it is the right approach at all. A simpler HTTP-based OpenAPI service would have been a lot better and it is already well supported in all frameworks.
The only way I can make sense of MCP in the context of an STDIO.
"Tool calling" is just one part of MCP, there are more things like "Sampling" which allow the server itself to initiate stuff on the client. As for tool calling, having a layer like MCP makes sense because there a lot of things which don't have a REST-API + may need direct access to the computer (filesystem, processes, etc).
Examples:
* Running SQL commands on a DB or a Redis instance.
* Launching Docker containers, SSHing to a server an running some command.
* Reading a file and extracting relevant information from it, like OCR.
* Controlling a remote browser using the WebDriver protocol, have some kind of persistent connection to a backend.
As for just pure REST-API usecases, I think MCP serves what Swagger/OpenApi-Spec are meant to do, i.e. enforce some kind of format and give each endpoint a "Name" + list of Params which the LLM can invoke.
The issue is that there is no standardised way to pass these API specs to LLMs as tools (maybe something can be built in this space). In the future, I can easily see some kind of library/abstraction that allows an MCP server to parse an existing API spec file to expose those APIs as tools which can be combined with some local state on the computer to allow stateful interactions with a REST API.
ad hoc RPC[1] that involves JSON request/response payloads and is wed to HTTP transport is arguably worse than conforming to the JSON-RPC 2.0 specification[2].
[1] if it’s not REST (even giving a pass on HATEOAS) then it’s probably, eventually, effectively RPC, and it’s still ad hoc even if it’s well documented
Yeah, I always thought MCP was a bit verbose. It reminds me of the WSDL and SOAP mess of the 2000s. Model tool calls are just RPCs into some other service, so JSON-RPC makes sense. Is there anything else has wide adoption and good client support? XML-RPC? gRPC? Protobufs? I mean, it shouldn't need extra libraries to use. You can handroll a JSON-RPC request/response pretty easily from any programming language.
Regarding the verbosity, yeah, it's interesting how model providers make more money from more tokens used, and you/we end up paying for it somehow. When you're doing lots of tool calls, it adds up!
Totally agree - a well-defined REST API "standard" for tool listing and tool execution would have been much better. Could extend as needed to websockets for persistent connections / streaming data.
fully agree, and that's what we do at ACI.dev as a managed authenticated tool calling platform. https://www.aci.dev/
And we expose more tool discovery flexibility rather than just list_tools()
It is essentially a standard (has a schema) that has an ecosystem of tools around it.
(completely opensource, no protocol/bridge lockin, no vendor/provider lockin, no ide/client/auton lockin, http/sse/jsonrpc/whatever, local/remote, composable)
So far I'm categorically calling MCP a "bridge", because BLAH supports other bridges such as SLOP (https://github.com/agnt-gg/slop/blob/main/README.md) and conceptually OpenAPI (or simply HTTP) is a bridge.
So blah can orchestra/compose any number of bridges, and it can list any tools it style/format of any bridge. (sorry that sounds so dumb)
For example, you can run `blah mcp start --config blah.json`, and add that to your cursor/claude mcp servers. When you fetch the tools, it loops over all your tools in your blah.json and fetches them whether it is an mcp server, slop server or openapi, it's agnostic and will return a full list of tools pulling from all bridges.
And then you can do `blah slop start`, which will do the same, but the opposite, start a slop server but it will boot up mcp servers and serve them over http too.
So essentially a bridge/protocol agnostic system, you ask for a list of tools, and it traverses everything that can list tools and splats them all together.
That's a little of the main pitch but there are larger plans to try build an ecosystem like npmjs where there is a public registry of any tool (which are just functions at the end of the day). Clouldflare AI team is really getting it right now (https://blog.cloudflare.com/remote-model-context-protocol-se...), most people would rather just tools being hosted for them, and workers is perfect for that.
It also means you just have to add one MCP server and use one configuration file to manage your tools. (Also has way more control over logging which MCP devs would love)
---
And that all maybe sounds complicated, but it's meant to make things A LOT easier. The README.md is horrible, just lots of random ideas and my comment isn't much better, but I'm aiming to have an alpha version in a week or so. Would absolutely love feedback!
To really understand MCP you need to think about application design in a different way.
In traditional applications, you know at design-time which functionality will end up in the final product. For example, you might bundle AI tools into the application (e.g. by providing JSON schemas manually). Once you finish coding, you ship the application. Design-time is where most developers are operating in, and it's not where MCP excels. Yes, you can add tools via MCP servers at design-time, but you can also include them manually through JSON schemas and code (giving you more control because you're not restricted by the abstractions that MCP imposes).
MCP-native applications on the other hand can be shipped, and then the users can add tools to the application — at runtime. In other words, at design-time you don't know which tools your users will add (similar to how browser developers don't know which websites users will visit at runtime). This concept — combined with the fact that AI generalizes so well — makes designing this kind of application extremely fascinating, because you're constantly thinking about how users might end up enhancing your application as it runs.
As of today, the vast majority of developers aren't building applications of this kind, which is why there's confusion.
> MCP is an open protocol that standardizes how applications provide context
> to LLMs. Think of MCP like a USB-C port for AI applications. Just as USB-C
> provides a standardized way to connect your devices to various peripherals
> and accessories, MCP provides a standardized way to connect AI models to
> different data sources and tools.
I want to know in which way is USB-C applicable here. The complicated plug that's actually 30 different protocol's that's difficult understand what capabiltiies a plug/cable actually has?
Maybe they used an LLM to explain it. Gemini in particular is obsessed with these utterly useless analogies for everything, when I would prefer something closer to Wikipedia with more context. (Needless to say, I currently don't find LLMs useful for learning about things. That's a shame because that use case feels promising.)
The closest software analogy I’ve heard is like passing around a callable/function with a standard interface. An LLM can call the callable and work with the returned data without needing to go back and forth between your application logic.
they probably mean it’s going to be difficult early on to find standards compliant implementations. and then always very annoying to make sure all involved components support the correct feature set.
It's a beautiful and deep analogy, and works for both software engineer and their mom.
Mom-level: ChatGPT ("or that other ChatGPT with a human name, Klaus I think? No, it was Claude.") can use software that says it supports MCP. If it says "MCP", I can use it with my AI.
Software dev level: MCP servers and MCP clients should just work, like USB. I don't really have to care about this, I expect them to connect just fine. Like with USB, there's a crap ton of complexity dumped on implementers of the spec to make it work reliably and cheaply - as it should be. That's literally their job: to take all the "secret sauce" that makes their product "special" and hide it behind a standard, because they're not special and nobody cares.
As another software engineer: if it ain't USB, I ain't buying, because I'm too old to deal with the proprietary per-device unique connectors bullshit. The standard exists so I don't have to think about it.
I am really struggling with what the value-add is with MCP. It feels like another distraction in the shell game of contemporary AI tech.
> MCP is an open protocol that standardizes how applications provide context to LLMs.
What is there to standardize? Last I checked, we are using a text-to-text transformer that operates on arbitrary, tokenized strings. Anything that seems fancier than tokens-to-tokens is an illusion constructed by the marketing wizards at these companies. Even things like tool/function calling are clever heuristics over plain-ass text.
> Currently, the MCP spec defines two kinds of servers, based on the transport mechanism they use: ...
This looks like micro services crossed with AI. I don't think many are going to have a happy time at the end of this adventure.
If you're interested, I'd encourage you to implement an MCP integration and see if you change your mind.
For instance, I have a little 'software team in a box' tool. v1 integrated github and three different llms manually (react + python backend). This is fine. You can call github commands via CLI on the backend, and add functionality somewhat easily, depending on the LLM's knowledge.
Pain points -- if you want workflow to depend on multiple outputs from these pieces, (e.g. see that there's a pull request, and assess it, or see that a pull request is signed off on / merged, and update something) -- you must code most of these workflows manually.
v2, I wiped that out and have a simple git, github and architect MCP protocol written up. Now I can have claude as a sort of mastermind, and just tell it "here are all the things you can do, please XXX". It wipes out most of the custom workflow coding and lets me just tell Claude what I'd look to do -- on the backend, my non-LLM MCP server can deal with things it's good at, API calls, security checks, etc.
At a high level, the request format and endpoints. Instead of needing to write a bespoke connector for every type of context that matches their preferred API standards, I just tell my client that the server exists and the standard takes care of the rest.
Do you have similar doubts about something like gRPC?
> This looks like micro services crossed with AI.
Seems like a cynical take with no substance to me. What about a standard request protocol implies anything about separation of concerns, scaling, etc?
Right now your typical interaction in chat is limited with some exceptions of out of box tooling that most current platforms provide: file attachment, web search, etc.
MCP is a way to extend this toolbox, but the cooler thing is AI will be able to determine _at inference time_ what tools to use to fulfill the user's prompt.
You could say the same thing about almost any protocol, e.g. HTTP, which runs on arbitrary streams of bytes over TCP; and the headers, methods and status codes are just illusions on top of that.
I hoped OpenAI would support OpenAPI for connecting to tools. Having created a couple of MCP servers, it feels like a less flexible and worse documented API to me. I can’t really see anything that is made better by MCP over OpenAPI. It’s a little bit less code for a lot less options. Give it some time and it will also get Swagger built in.
It’s solving a problem that was already robustly solved. So get we go with another standard.
There's already swagger MCP service out there, I don't know how production ready it is, but I saw something the other day when searching through GitHu. One of several implementations: https://github.com/dcolley/swagger-mcp
Can't I do function calling in OpenAPI? I also feel like MCP is reinventing the wheel.
I have been converting OpenAPI documents into function calling schemas and doing tool calling since function calling first came out in 2023, but it's not easy to recreate a backend server to fit MCP.
Also, these days, I'm making a compiler-driven function calling specialized framework, but I'm a little cautious about whether MCP will support it. It enables zero-cost tool calling for TypeScript classes based on the compiler, and it also supports OpenAPI.
However, in the case of MCP, in order to fit this to the compiler-driven philosophy, I need to create a backend framework for MCP development first, or create an add-on library for a famous framework like NestJS. I can do the development, but there's so much more to do compared to OpenAPI tool calling, so it's a bit like that.
How should an MCP server like git work in your opinion? Should it then be written as a FastAPI server so that you have an openapi spec instead of just a CLI?
"Think of MCP like a USB-C port for AI applications."
Given the enormous amounts of pain I've heard are involved in actually implementing any form of USB, I think the MCP community may want to find a different analogy!
What are people using MCPs for? I search on youtube and see a lot of videos explaining how MCPs work, but none showing practical uses for a programmer (aside from getting the weather via cursor).
I have two that I use a lot:
- Postgres one connected to my local db
- A browser (Playwright)
That way I can ask cursor something like: "Find an object with xxx property in the db, open its page in the browser, fix console errors"
And it's able to query my db, find relevant object, open the browser, check logs, fix the code based on errors.
Even simpler stuff:
- copying pasting a broken local url in cursor, and asking it to fix all console errors. Works really well.
- or when you have a complex schema, and need to find some kind of specific record, you can just ask cursor "find me a user that has X transactions, matches Y condition, etc..". I found it much faster than me at finding relevant records
- filesystem, read(and occasionally write) to local disk
- mcp-perplexity, so I can essentially have Claude sample from perplexity's various models and/or use it for web search. Somewhat superseded by Claude's own new web search capability, but perplexity's is generally better.
If you want to try out mcp (model context protocol) with little to no setup:
I built https://skeet.build/mcp where anyone can try out mcp for cursor and now OpenAI agents!
We did this because of a painpoint I experienced as an engineer having to deal with crummy mcp setup, lack of support and complexity trying to stand up your own.
Mostly for workflows like:
* start a PR with a summary of what I just did
* slack or comment to linear/Jira with a summary of what I pushed
* pull this issue from sentry and fix it
* Find a bug a create a linear issue to fix it
* pull this linear issue and do a first pass
* pull in this Notion doc with a PRD then create an API reference for it based on this code
* Postgres or MySQL schemas for rapid model development
Everyone seems to go for the hype but ease of use, practical pragmatic developer workflows, and high quality polished mcp servers are what we’re focused on
Call it a protocol and suddenly it sounds like a foundational technology.
Nah, it's just a fancy JSON schema that lets LLMs play hot potato with metadata.
Shamelessly promoting in here, I created an architecture that allows an AI agent to have those so called "tools" available locally (under the user control), and works with any kind of LLMs, and with any kind of LLM server (in theory). I've been showing demos about it for months now. Works as a middle-ware, in stream, between the LLM server and the chat client, and works very well. The project is open source, even the repo is outdated, but simply because no one is expressing interest in looking into the code. But here is the repo: https://github.com/khromalabs/Ainara. There's a link to a video in there. Yesterday just recorded a video showcasing DeepSeek V3 as the LLM backend (but could be any from OpenAI as well, or Anthropic, whatever).
The lack of interest may be from the crypto aspect:
> While the project will always remain open-source and aims to be a universal AI assistant tool, the officially developed 'skills' and 'recipes' (allowing AI to interact with the external world through Ainara's Orakle server) will primarily focus on cryptocurrency integrations. The project's official token will serve as the payment method for all related services.
I'm new to "MCP"... It says here that even IDE plug into this MCP server [1], as in you don't edit files directly anymore but go through a client/server?
It wasn't bad enough that we now run servers locally to constantly compile code and tell us via json we made a typo... Soon we won't even be editing files on a disk, but accessing them through a json-rpc client/server? Am I getting this wrong?
I think you are getting it wrong. Some IDEs like Cursor and VS Code extensions like Cline support MCP servers, meaning you can give them access to your databases, Jira tickets, Notion notes, Slack messages, etc.
This is great, I was debating whether I should do my latest project using the new OpenAI Responses API (optimized for agent workflows) or using MCP, but now it seems even more obvious that MCP is the way to go.
I was able to make a pretty complex MCP server in 2 days for LLM task delegation:
claude needed these those tools in 2024, so having the community contribute for free was actually a smart move.
service providers get more traffic, so they’re into it. makes sense.
claude 3.5 was great at the time, especially for stuff like web dev. but now deepseek v3 (0324) is way better value. gemini's my default for multimodal. openai still feels smartest overall. i’ve got qwq running locally. for deep research, free grok 3 and perplexity work fine. funny enough, claude 3.7 being down these two days didn’t affect me at all.
i checked mcp since i contribute to open source, but decided to wait. few reasons:
- setup’s kind of a mess. it’s like running a local python or node bridge, forwarding stuff via sse or stdio. feels more like bridging than protocol innovation
- I think eventually we need all the app to be somehow built-in AI-first protocol. I think only Apple (maybe Google) have that kind of influence. Think about the lightening vs usb-c.
- performance might be a bottleneck later, especially for multimodal.
- same logic as no.2 but the question is that do you really want every app to be AI-first?
main issue for me: tools that really improve productivity are rare. a lot of mcp use cases sound cool, but i'll never give full github access to a black box. same for other stuff. so yeah—interesting idea, but hard ceiling.
You should take a look at how Claude Code does its permissioning. It's totally fine to connect it right up to your GitHub MCP server because it'll ask each time it wants to take an action (and you can choose "don't ask again for this tool" if it's an obviously safe operation like searching your PRs).
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 being aware of this protocol and how to pump the message bus loop, but I'd rather not reinvent it.
Is there a standard way of doing this already? Is it considered user logic that's "out of scope" for the MCP specification?
I'm curious what the revenue plan is for MCP authors. I mean, I can see wanting to add support for existing products (like an code/text editor, image/sound/video editor, etc.)
But is there a market for stand-alone paid MCP services? It seems these will mostly be usurped by the models themselves sooner or later. I mean if you create a MCP popular enough to actually make money, the foundation model will soon be able to just do it without your service. Almost like you are doing experimentation on high-value agent features for free.
Also, something about the format just reeks of SOAP to me. It feels over-engineered. Time will tell, obviously.
Most MCP servers are thin wrappers around an API, I don't think there will be a big paid market. I imagine they will be released like SDKs are now, either by companies themselves, or by individuals when there's no official implementation. A few dev agents can even write MCP servers for themselves.
MCP is great. But what i'd like to understand is whats the difference between MCP and manually prompting the model a list of tools with description and calling the specific function based on the llm response ?
1. it makes tool discovery and use happen elsewhere so programs become more portable
2. it standardizes the method so every LLM doesn't need to do it differently
3. it creates a space for further shared development beyond tool use and discovery
4. it begins to open up hosted tool usage across LLMs for publicly hosted tools
5. for better or worse, it continues to drive the opinion that 'everything is a tool' so that even more functionality like memory and web searching can be developed across different LLMs
6. it offers a standard way to set up persistent connections to things like databases instead of handling them ad-hoc inside of each LLM or library
If you are looking for anything more, you won't find it. This just standardizes the existing tool use / function calling concept while adding minimal overhead. People shouldn't be booing this so much, but nor should they be dramatically cheering it.
You can build all the tools yourself, or you can just go to a "tools store", install it and use it. MCP is just the standard everyone can use to build, share and use these tools.
Just like an app store, a chrome extension store, we can have a LLM tools store.
If you haven't tried any of these yet, the first place to start is Claude Desktop. If you'd like to write your own agents, consider https://github.com/evalstate/fast-agent
EDIT: I may have misunderstood your question. If you're asking "how can I make an API call to OpenAI, and have OpenAI call an MCP server I'm running as part of generating its response to me", the answer is "you can't". You'll want a proxy API that you call which is actually an MCP client, responsible for coordinating between the MCP servers and the OpenAI API upstream agent.
Was wondering if this would ever happen. I wrote an MCP server that hooked up Azure Monitor (or whatever the hell microsoft is calling it) via Microsoft's python SDK so I could get it to query our logs without using command line tools. Took about half a day, mostly due to writing against the wrong Microsoft SDK. It will be nice to let ChatGPT have a crack a this too!
This seems to be just implementing tools functionality, no resources or prompts, roots or sampling. I can't blame them.
I'm wondering though about progress notifications and pagination. Especially the latter should be supported as otherwise some servers might not return the full list of tools. Has anyone tested this?
Ideally in the future we won't need an MCP server when the AI can just write Unix terminal code to do anything it needs to get the job done? It seems using an MCP server and having the AI know about its "tools" is more of training wheels approach.
If you have a clean, well-documented API that can be understood in under 30 minutes by a decent software engineer, congrats: you are MCP ready. I wonder how many discussions there will be about "adding MCP support" to software without this prerequisite.
Kinda naive question. All you need is a way to convince the LLM to output json according to your schema, then call the function. So what is the use of MCP servers? Why complicate things by adding another layer?
hopefully they integrate it with their customGPT approach! I think they already work fantastically especially since the addition of the @ sign and automatic completion to easily include them in normal conversations. the only thing that was missing was access to the local machine.
keithwhor|11 months ago
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:
Which traditionally would just be HTTP POST to `/get_weather` with `{ "location": "New York" }`.I've made the suggestion to remove some of this complexity [1] and fall back to just a traditional HTTP server, where a session can be negotiated with an `Authorization` header and we rely on traditional endpoints / OpenAPI + JSON Schema endpoint definitions. I think it would make server construction a lot easier and web frameworks would not have to materially be updated to adhere to the spec -- perhaps just adding a single endpoint.
[0] https://spec.modelcontextprotocol.io/specification/2025-03-2...
[1] https://github.com/modelcontextprotocol/specification/issues...
_pdp_|11 months ago
MCP is just too complex for what it is supposed to do. I don't get what's the benefit. It is the kind of thing that has the potential to be a huge time waste because it requires custom dev tools to develop and troubleshoot.
It is not even a protocol in the traditional sense - more of a convention.
And of course we will implement it, like everyone else, because it is gathering momentum, but I do not believe it is the right approach at all. A simpler HTTP-based OpenAPI service would have been a lot better and it is already well supported in all frameworks.
The only way I can make sense of MCP in the context of an STDIO.
pulkitsh1234|11 months ago
Examples:
* Running SQL commands on a DB or a Redis instance. * Launching Docker containers, SSHing to a server an running some command. * Reading a file and extracting relevant information from it, like OCR. * Controlling a remote browser using the WebDriver protocol, have some kind of persistent connection to a backend.
As for just pure REST-API usecases, I think MCP serves what Swagger/OpenApi-Spec are meant to do, i.e. enforce some kind of format and give each endpoint a "Name" + list of Params which the LLM can invoke. The issue is that there is no standardised way to pass these API specs to LLMs as tools (maybe something can be built in this space). In the future, I can easily see some kind of library/abstraction that allows an MCP server to parse an existing API spec file to expose those APIs as tools which can be combined with some local state on the computer to allow stateful interactions with a REST API.
ants_everywhere|11 months ago
(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.
michaelsbradley|11 months ago
[1] if it’s not REST (even giving a pass on HATEOAS) then it’s probably, eventually, effectively RPC, and it’s still ad hoc even if it’s well documented
[2] https://www.jsonrpc.org/specification
ammmir|11 months ago
Regarding the verbosity, yeah, it's interesting how model providers make more money from more tokens used, and you/we end up paying for it somehow. When you're doing lots of tool calls, it adds up!
antupis|11 months ago
pacjam|11 months ago
croes|11 months ago
0x008|10 months ago
or is there more to it?
thisisfixer|11 months ago
unknown|11 months ago
[deleted]
cyanydeez|11 months ago
thomasfromcdnjs|11 months ago
It is essentially a standard (has a schema) that has an ecosystem of tools around it.
(completely opensource, no protocol/bridge lockin, no vendor/provider lockin, no ide/client/auton lockin, http/sse/jsonrpc/whatever, local/remote, composable)
So far I'm categorically calling MCP a "bridge", because BLAH supports other bridges such as SLOP (https://github.com/agnt-gg/slop/blob/main/README.md) and conceptually OpenAPI (or simply HTTP) is a bridge.
An example blah.json looks like this
So blah can orchestra/compose any number of bridges, and it can list any tools it style/format of any bridge. (sorry that sounds so dumb)For example, you can run `blah mcp start --config blah.json`, and add that to your cursor/claude mcp servers. When you fetch the tools, it loops over all your tools in your blah.json and fetches them whether it is an mcp server, slop server or openapi, it's agnostic and will return a full list of tools pulling from all bridges.
And then you can do `blah slop start`, which will do the same, but the opposite, start a slop server but it will boot up mcp servers and serve them over http too.
So essentially a bridge/protocol agnostic system, you ask for a list of tools, and it traverses everything that can list tools and splats them all together.
That's a little of the main pitch but there are larger plans to try build an ecosystem like npmjs where there is a public registry of any tool (which are just functions at the end of the day). Clouldflare AI team is really getting it right now (https://blog.cloudflare.com/remote-model-context-protocol-se...), most people would rather just tools being hosted for them, and workers is perfect for that.
It also means you just have to add one MCP server and use one configuration file to manage your tools. (Also has way more control over logging which MCP devs would love)
---
And that all maybe sounds complicated, but it's meant to make things A LOT easier. The README.md is horrible, just lots of random ideas and my comment isn't much better, but I'm aiming to have an alpha version in a week or so. Would absolutely love feedback!
4.5 Deep Research Report on BLAH - https://gist.github.com/thomasdavis/3827a1647533e488c107e64a...
thanatropism|11 months ago
talles|11 months ago
That analogy may be helpful for mom, but not for me as a software engineer.
ondrsh|11 months ago
In traditional applications, you know at design-time which functionality will end up in the final product. For example, you might bundle AI tools into the application (e.g. by providing JSON schemas manually). Once you finish coding, you ship the application. Design-time is where most developers are operating in, and it's not where MCP excels. Yes, you can add tools via MCP servers at design-time, but you can also include them manually through JSON schemas and code (giving you more control because you're not restricted by the abstractions that MCP imposes).
MCP-native applications on the other hand can be shipped, and then the users can add tools to the application — at runtime. In other words, at design-time you don't know which tools your users will add (similar to how browser developers don't know which websites users will visit at runtime). This concept — combined with the fact that AI generalizes so well — makes designing this kind of application extremely fascinating, because you're constantly thinking about how users might end up enhancing your application as it runs.
As of today, the vast majority of developers aren't building applications of this kind, which is why there's confusion.
dotancohen|11 months ago
madeofpalk|11 months ago
jchw|11 months ago
votick|11 months ago
gnfargbl|11 months ago
https://norahsakal.com/blog/mcp-vs-api-model-context-protoco...
elamje|11 months ago
riemannzeta|11 months ago
https://modelcontextprotocol.io/quickstart/server
I don't think it's terribly difficult to drill down into their GitHub to see what's happening under the hood if you need that level of detail.
TechDebtDevin|11 months ago
https://modelcontextprotocol.io/introduction
whazor|11 months ago
In LSP, you have editor (vscode, neovim), and language servers (rust, typescript, python).
In MCP, you have the client (chat window), and servers (providing context, tools, and prompts).
tb1989|11 months ago
MCP Isn’t the USB-C of AI — It’s Just a USB-C(laude) Dongle
https://dev.to/internationale/mcp-is-not-ai-usb-c-its-usb-cl...
The illustrations are on their official website.
I find it hard to respect a company that invented dongle and claims to have invented USB
atonse|11 months ago
It’s a common set of APIs/protocols that includes a way to share data, capabilities, etc.
That’s pretty much exactly what USB is.
skavi|11 months ago
monkeydust|11 months ago
beardedwizard|11 months ago
amannm|11 months ago
zombiwoof|11 months ago
deepak_leanmvp|11 months ago
soulofmischief|11 months ago
Do modern developers not know what "standards" means? Is this marketing slop or did an engineer seriously write that for other engineers?
TeMPOraL|11 months ago
Mom-level: ChatGPT ("or that other ChatGPT with a human name, Klaus I think? No, it was Claude.") can use software that says it supports MCP. If it says "MCP", I can use it with my AI.
Software dev level: MCP servers and MCP clients should just work, like USB. I don't really have to care about this, I expect them to connect just fine. Like with USB, there's a crap ton of complexity dumped on implementers of the spec to make it work reliably and cheaply - as it should be. That's literally their job: to take all the "secret sauce" that makes their product "special" and hide it behind a standard, because they're not special and nobody cares.
As another software engineer: if it ain't USB, I ain't buying, because I'm too old to deal with the proprietary per-device unique connectors bullshit. The standard exists so I don't have to think about it.
matthewmacleod|11 months ago
olddustytrail|11 months ago
bob1029|11 months ago
> MCP is an open protocol that standardizes how applications provide context to LLMs.
What is there to standardize? Last I checked, we are using a text-to-text transformer that operates on arbitrary, tokenized strings. Anything that seems fancier than tokens-to-tokens is an illusion constructed by the marketing wizards at these companies. Even things like tool/function calling are clever heuristics over plain-ass text.
> Currently, the MCP spec defines two kinds of servers, based on the transport mechanism they use: ...
This looks like micro services crossed with AI. I don't think many are going to have a happy time at the end of this adventure.
vessenes|11 months ago
For instance, I have a little 'software team in a box' tool. v1 integrated github and three different llms manually (react + python backend). This is fine. You can call github commands via CLI on the backend, and add functionality somewhat easily, depending on the LLM's knowledge.
Pain points -- if you want workflow to depend on multiple outputs from these pieces, (e.g. see that there's a pull request, and assess it, or see that a pull request is signed off on / merged, and update something) -- you must code most of these workflows manually.
v2, I wiped that out and have a simple git, github and architect MCP protocol written up. Now I can have claude as a sort of mastermind, and just tell it "here are all the things you can do, please XXX". It wipes out most of the custom workflow coding and lets me just tell Claude what I'd look to do -- on the backend, my non-LLM MCP server can deal with things it's good at, API calls, security checks, etc.
nlarew|11 months ago
At a high level, the request format and endpoints. Instead of needing to write a bespoke connector for every type of context that matches their preferred API standards, I just tell my client that the server exists and the standard takes care of the rest.
Do you have similar doubts about something like gRPC?
> This looks like micro services crossed with AI.
Seems like a cynical take with no substance to me. What about a standard request protocol implies anything about separation of concerns, scaling, etc?
ripped_britches|11 months ago
orangebread|11 months ago
Right now your typical interaction in chat is limited with some exceptions of out of box tooling that most current platforms provide: file attachment, web search, etc.
MCP is a way to extend this toolbox, but the cooler thing is AI will be able to determine _at inference time_ what tools to use to fulfill the user's prompt.
Hope this helped!
oefnak|11 months ago
unknown|11 months ago
[deleted]
analyte123|11 months ago
tcdent|11 months ago
MCP is now the industry standard for connecting LLMs to external tools.
otabdeveloper4|11 months ago
No it isn't. We're still five or ten years away from real standards.
(Anyways it's clear that the future is smaller self-hosted LLMs, so whatever standard eventually emerges will be based on that paradigm.)
fsndz|11 months ago
jtrn|11 months ago
It’s solving a problem that was already robustly solved. So get we go with another standard.
dartos|11 months ago
Well it’s transport agnostic, for one.
I think a big part of it is defining a stateful connection and codifying the concepts of prompts and tools.
Another issue with OpenAPI / swagger is that you still need to create a client per API, but with MCP it’s all uniform.
PeterStuer|11 months ago
taude|11 months ago
bjtitus|11 months ago
https://github.com/loopwork-ai/emcee
OrangeMusic|11 months ago
samchon|11 months ago
I have been converting OpenAPI documents into function calling schemas and doing tool calling since function calling first came out in 2023, but it's not easy to recreate a backend server to fit MCP.
Also, these days, I'm making a compiler-driven function calling specialized framework, but I'm a little cautious about whether MCP will support it. It enables zero-cost tool calling for TypeScript classes based on the compiler, and it also supports OpenAPI.
However, in the case of MCP, in order to fit this to the compiler-driven philosophy, I need to create a backend framework for MCP development first, or create an add-on library for a famous framework like NestJS. I can do the development, but there's so much more to do compared to OpenAPI tool calling, so it's a bit like that.
prometheon1|11 months ago
https://github.com/modelcontextprotocol/servers/blob/main/sr...
F7F7F7|11 months ago
dan-kwiat|11 months ago
[deleted]
gronky_|11 months ago
emmanueloga_|11 months ago
simonw|11 months ago
Given the enormous amounts of pain I've heard are involved in actually implementing any form of USB, I think the MCP community may want to find a different analogy!
PufPufPuf|11 months ago
jauntywundrkind|11 months ago
There's some other goodies too. OAuth 2.1 support, JSON-RPC Batching... https://github.com/modelcontextprotocol/specification/blob/m...
nomilk|11 months ago
antoinec|11 months ago
Even simpler stuff: - copying pasting a broken local url in cursor, and asking it to fix all console errors. Works really well. - or when you have a complex schema, and need to find some kind of specific record, you can just ask cursor "find me a user that has X transactions, matches Y condition, etc..". I found it much faster than me at finding relevant records
consumer451|11 months ago
Example use case: https://news.ycombinator.com/item?id=43466434
knowaveragejoe|11 months ago
- fetch, essentially curl any webpage or endpoint
- filesystem, read(and occasionally write) to local disk
- mcp-perplexity, so I can essentially have Claude sample from perplexity's various models and/or use it for web search. Somewhat superseded by Claude's own new web search capability, but perplexity's is generally better.
johnjungles|11 months ago
I built https://skeet.build/mcp where anyone can try out mcp for cursor and now OpenAI agents!
We did this because of a painpoint I experienced as an engineer having to deal with crummy mcp setup, lack of support and complexity trying to stand up your own.
Mostly for workflows like:
* start a PR with a summary of what I just did * slack or comment to linear/Jira with a summary of what I pushed * pull this issue from sentry and fix it * Find a bug a create a linear issue to fix it * pull this linear issue and do a first pass * pull in this Notion doc with a PRD then create an API reference for it based on this code * Postgres or MySQL schemas for rapid model development
Everyone seems to go for the hype but ease of use, practical pragmatic developer workflows, and high quality polished mcp servers are what we’re focused on
Lmk what you think!
polishdude20|11 months ago
Although the name is a bit unfortunate.
pfista|11 months ago
goaaron|11 months ago
rgomez|11 months ago
nomel|11 months ago
> While the project will always remain open-source and aims to be a universal AI assistant tool, the officially developed 'skills' and 'recipes' (allowing AI to interact with the external world through Ainara's Orakle server) will primarily focus on cryptocurrency integrations. The project's official token will serve as the payment method for all related services.
keyle|11 months ago
It wasn't bad enough that we now run servers locally to constantly compile code and tell us via json we made a typo... Soon we won't even be editing files on a disk, but accessing them through a json-rpc client/server? Am I getting this wrong?
[1] https://modelcontextprotocol.io/introduction
NicuCalcea|11 months ago
larodi|11 months ago
MoonGhost|11 months ago
eigenvalue|11 months ago
I was able to make a pretty complex MCP server in 2 days for LLM task delegation:
https://github.com/Dicklesworthstone/llm_gateway_mcp_server
chaosprint|11 months ago
service providers get more traffic, so they’re into it. makes sense.
claude 3.5 was great at the time, especially for stuff like web dev. but now deepseek v3 (0324) is way better value. gemini's my default for multimodal. openai still feels smartest overall. i’ve got qwq running locally. for deep research, free grok 3 and perplexity work fine. funny enough, claude 3.7 being down these two days didn’t affect me at all.
i checked mcp since i contribute to open source, but decided to wait. few reasons:
- setup’s kind of a mess. it’s like running a local python or node bridge, forwarding stuff via sse or stdio. feels more like bridging than protocol innovation
- I think eventually we need all the app to be somehow built-in AI-first protocol. I think only Apple (maybe Google) have that kind of influence. Think about the lightening vs usb-c.
- performance might be a bottleneck later, especially for multimodal.
- same logic as no.2 but the question is that do you really want every app to be AI-first?
main issue for me: tools that really improve productivity are rare. a lot of mcp use cases sound cool, but i'll never give full github access to a black box. same for other stuff. so yeah—interesting idea, but hard ceiling.
striking|11 months ago
TIPSIO|11 months ago
avaer|11 months ago
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 being aware of this protocol and how to pump the message bus loop, but I'd rather not reinvent it.
Is there a standard way of doing this already? Is it considered user logic that's "out of scope" for the MCP specification?
EDIT: added an example here https://github.com/avaer/mcp-message-bus
tonyhb|11 months ago
Does all of the event stuff and state stuff for you. Plus the orchestration.
paradite|11 months ago
It benefits MCP clients (ChatGPT, Claude, Cursor, Goose) more than the MCP servers and the service behind the MCP servers (GitHub, Figma, Slack).
zoogeny|11 months ago
But is there a market for stand-alone paid MCP services? It seems these will mostly be usurped by the models themselves sooner or later. I mean if you create a MCP popular enough to actually make money, the foundation model will soon be able to just do it without your service. Almost like you are doing experimentation on high-value agent features for free.
Also, something about the format just reeks of SOAP to me. It feels over-engineered. Time will tell, obviously.
NicuCalcea|11 months ago
https://www.reddit.com/r/ClaudeAI/comments/1hcrxl6/cline_can...
amerine|11 months ago
It feels like any kind of api-client work any organization or project would build to make users/customers happy and sticky.
victorbjorklund|11 months ago
izwasm|11 months ago
aurumque|11 months ago
2. it standardizes the method so every LLM doesn't need to do it differently
3. it creates a space for further shared development beyond tool use and discovery
4. it begins to open up hosted tool usage across LLMs for publicly hosted tools
5. for better or worse, it continues to drive the opinion that 'everything is a tool' so that even more functionality like memory and web searching can be developed across different LLMs
6. it offers a standard way to set up persistent connections to things like databases instead of handling them ad-hoc inside of each LLM or library
If you are looking for anything more, you won't find it. This just standardizes the existing tool use / function calling concept while adding minimal overhead. People shouldn't be booing this so much, but nor should they be dramatically cheering it.
mercenario|11 months ago
Just like an app store, a chrome extension store, we can have a LLM tools store.
victorbjorklund|11 months ago
jswny|11 months ago
I thought they ran locally only, so how would the OpenAI API connect to them when handing a request?
peterldowns|11 months ago
There are a variety of available clients documented here https://modelcontextprotocol.io/clients
If you haven't tried any of these yet, the first place to start is Claude Desktop. If you'd like to write your own agents, consider https://github.com/evalstate/fast-agent
EDIT: I may have misunderstood your question. If you're asking "how can I make an API call to OpenAI, and have OpenAI call an MCP server I'm running as part of generating its response to me", the answer is "you can't". You'll want a proxy API that you call which is actually an MCP client, responsible for coordinating between the MCP servers and the OpenAI API upstream agent.
bibryam|11 months ago
cruffle_duffle|11 months ago
esafak|11 months ago
ondrsh|11 months ago
I'm wondering though about progress notifications and pagination. Especially the latter should be supported as otherwise some servers might not return the full list of tools. Has anyone tested this?
ginko|11 months ago
neilv|11 months ago
https://tron.fandom.com/wiki/Master_Control_Program
Don't hook up the MCP to any lab equipment:
https://www.youtube.com/watch?v=lAcYUt2QbAo
jtimdwyer|11 months ago
polishdude20|11 months ago
analyte123|11 months ago
ursaguild|11 months ago
By writing mcp servers for our services/apps we are allowing a standardized way for ai assistants to integrate with tools and services across apps.
unknown|11 months ago
[deleted]
nurettin|11 months ago
customllm|11 months ago
singularity2001|11 months ago
__mharrison__|11 months ago
spiritplumber|11 months ago
Tewboo|11 months ago
Tteriffic|11 months ago
unknown|11 months ago
[deleted]
dhanushreddy29|11 months ago
shrisukhani|11 months ago
nilslice|11 months ago
otabdeveloper4|11 months ago
todsacerdoti|11 months ago
ogundipeore|11 months ago
...based on code generated from an agent that understands it.
...I think cursor editor gets closer to this experience but for a single task
unit149|11 months ago
[deleted]
unknown|11 months ago
[deleted]
hodanouri|11 months ago
[deleted]