> Think of MCP like a USB-C port for AI applications. That analogy may be helpful for mom, but not for me as a software engineer.
I see it as service discovery for AI applications
OpenAI adds MCP support to Agents SDK
181–190 of 281 posts
Re: OpenAI adds MCP support to Agents SDK
#182> Think of MCP like a USB-C port for AI applications. That analogy may be helpful for mom, but not for me as a software engineer.
The full quote is better: > 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.
No, it's actually a lot worse. "USB-C port for AI applications" sounds like something written by an insane person.
Re: OpenAI adds MCP support to Agents SDK
#183Big question in my mind was if OpenAI was going to formally endorse this (since it was created by Anthropic) but we have our answer. MCP is now the industry standard for connecting LLMs to external tools.
> MCP is now the industry standard for connecting LLMs to external tools.
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.)
Re: OpenAI adds MCP support to Agents SDK
#184MCP is now the standard everyone must conform to. Couldn't possibly have predicted that 2 months ago.
Wait two more months and there will be a different the standard.
Re: OpenAI adds MCP support to Agents SDK
#185Today 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": {…
"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.
Re: OpenAI adds MCP support to Agents SDK
#186Earlier 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.
Doesn't mean it's not all the same or boring drudge work :).
Though I disagree with GP's reply to you about being product-oriented and such - 90% of products are just "system integration" with some custom marketing graphics and a sprinkle of vendor lock in :).
Combination of standardization and AI will end in a great carnage of software developer jobs, as system integration is basically the poster child of a job that should not exist in ideal world - i.e. all problems are problems of insufficient automation or insufficient ability to cope with complexity. But there's only so much demand for R&D and creating bona fide new capabilities, and not everyone wants to be a manager or a salesperson...
IDK, might be really the time to pick some trade skills, as manual labor in the field is likely the last thing to be automated away.
Re: OpenAI adds MCP support to Agents SDK
#187> Think of MCP like a USB-C port for AI applications. That analogy may be helpful for mom, but not for me as a software engineer.
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.
Re: OpenAI adds MCP support to Agents SDK
#188Earlier quoted context omitted.
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 wher…
Oh, it’s the new HATEOAS? A pluggable framework for automatic discoverability of HTTP APIs is incredibly useful, and not just for AI :)
No, you can't understand it until you understand that the world isn't all webshit and not everything is best used via REST.
(Not even webshit is best used by REST, as evidenced by approximately every "REST" API out there, designed as RPC over HTTP pretending it's not.)
Re: OpenAI adds MCP support to Agents SDK
#189Today 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": {…
I fully agree. 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 bel…
Exactly my points: https://taoofmac.com/space/notes/2025/03/22/1900
Re: OpenAI adds MCP support to Agents SDK
#190Earlier quoted context omitted.
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 wher…
I think this is a good explanation on the client side of MCP. But most developers are not building MCP clients (I think?). Only a few companies like OpenAI, Anthropic, Cursor and Goose are building MCP client. Most developers are currently building MCP servers that wrap a 3rd party or wrap their own service. And in this case, they are still at deciding on the tools in design-time, not runtime. Also I want to mention…
The concept of design-time vs. runtime applies to both clients and servers.
I believe you're implying that server developers can focus less on this concept (or sometimes even ignore it) when building a server. This is true.
However, the fact that end-users can now run MCP servers directly — rather than having to wait for developers to bundle them into applications — is a significant paradigm shift that directly benefits MCP server authors.