Live data from Hacker News

OpenAI adds MCP support to Agents SDK

openai.github.io

121–130 of 281 posts

Re: OpenAI adds MCP support to Agents SDK

#121

Earlier quoted context omitted.

This is very cool but definitely has the XKCD standards vibe [0]. If the industry is standardizing on MCP but then we decide it's not good enough, we just end up back where we started. I hope there's enough willpower (and low enough ego) to get to a really tight, single great implementation. [0] https://xkcd.com/927/

Complete with the alt text mentioning USB, which is used in the MCP website to describe it. Someone else said it and I agree, it's not a good analogy. Most of what we do in software development is connecting things. Saying "this is like USB but for X" could cover a huge chunk of what software is. Besides, this "think of" analogies kinda irk me because I don't want you to give me a mental image you think I can digest,…

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.

Re: OpenAI adds MCP support to Agents SDK

#122
post #19
post #15

Earlier quoted context omitted.

I could not find the actual criticism in that article. What's the problem with MCP again? It's the first standard for agents.

the problem of agents is not the lack of standards, but reliability (reliability of tool use and reliability of outcomes). MCP does not solve any of that.

This is just moving the goalposts, MCP is not supposed to solve every problem with agents. It's meant to make it easier to provide easier, standardised ways for LLMs to interact with external tools, which it has done. Reliability is a completely different problem.

Re: OpenAI adds MCP support to Agents SDK

#123
post #75

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": {…

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…

It took me a minute to even understand this comment because for me the “obvious” use-case for MCP is local filesystem tasks, not web requests. Using MCP to manipulate files is my primary LLM use-case and has been ever since Anthropic released it and integrated it into Claude Desktop. I understand where you’re coming from, but I suspect that the idea here is to build something that is more “filesystem first.”

Re: OpenAI adds MCP support to Agents SDK

#124

Earlier quoted context omitted.

I've been working on BLAH - Barely Logical Agent Host ( https://github.com/thomasdavis/blah/blob/master/packages/cli... ) for the past few weeks. 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 call…

This is very cool but definitely has the XKCD standards vibe [0]. If the industry is standardizing on MCP but then we decide it's not good enough, we just end up back where we started. I hope there's enough willpower (and low enough ego) to get to a really tight, single great implementation. [0] https://xkcd.com/927/

aha can't disagree with that sentiment, best I can do is not make the standard suck.

Re: OpenAI adds MCP support to Agents SDK

#125
post #28

> 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.

What's so hard for them to just say "it's a standard"? Why do we need to mention USB? Or USB-C at that, which just confuses the message even more?

Do modern developers not know what "standards" means? Is this marketing slop or did an engineer seriously write that for other engineers?

Re: OpenAI adds MCP support to Agents SDK

#126
post #28

> 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.

Because everyone knows the usb-c protocol

Do they? Like actually, know it cover-to-cover, or do they just know of it? Because the first thing to point out is that USB-C isn't a protocol, it's a connector standard.

Re: OpenAI adds MCP support to Agents SDK

#127

Earlier quoted context omitted.

Complete with the alt text mentioning USB, which is used in the MCP website to describe it. Someone else said it and I agree, it's not a good analogy. Most of what we do in software development is connecting things. Saying "this is like USB but for X" could cover a huge chunk of what software is. Besides, this "think of" analogies kinda irk me because I don't want you to give me a mental image you think I can digest,…

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.

Re: OpenAI adds MCP support to Agents SDK

#128
post #104

Earlier quoted context omitted.

Similar, but one level higher. Plugins have pre-defined APIs. You code your application against the plugin API and plugin developers do the same. Functionality is being consumed directly through this API — this is level 1. MCP is a meta-protocol. Think of it as an API that lets arbitrary plugins announce their APIs to the application at runtime. MCP thus lives one level above the plugin's API level. MCP is just used…

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 security researcher!

Re: OpenAI adds MCP support to Agents SDK

#129
post #5

"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!

Since I've worked with the official MCP SDK, I find this analogy quite accurate

Re: OpenAI adds MCP support to Agents SDK

#130
post #35

Earlier quoted context omitted.

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.)

LLMs are like an unlimited, poorly written encyclopedia. Often inaccurate or not entirely helpful, but will get you enough of an idea to find better sources. Sort of solving the "I don't know what I don't know" gap.

In this regard, they have been extraordinarily fruitful for my research and studies.
Post reply on HN