Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenAI adds MCP support to Agents SDK

openai.github.io

Post reply on HN
Print view View original

191–200 of 281 posts

Re: OpenAI adds MCP support to Agents SDK

#191

Post by TeMPOraL »

soulofmischief wrote: post #128
anonymousDan wrote: post #109

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…

> Feels like we've slid back into the 90s in this regard.

Thank $deity. 90s and early 2000s were the times software was designed to do useful work and empower users, as opposed to lock them into services and collect telemetry, both of which protected by the best of advancement in security :).

I'm only half-joking here. Security is always working against usefulness; MCP is designed to be useful first (like honest to $deity useful, not "exploit your customers" useful), so it looks like security nightmare. Some of that utility will need to go away, because complete lack of security is also bad for the users - but there's a tradeoff to be made, hopefully one that doesn't just go by modern security zeitgeist, because that is already deep into protecting profits by securing services against users.

> 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

There is also a general lack of consideration of who is being protected from whom, and why in the security culture. MCP, vibe coding, and LLMs in general are briefly giving end-users back some agency, bringing back the whole idea of "bicycle for the mind" that was completely and intentionally destroyed when computing went mainstream. Let's not kill it so eagerly this time.

Re: OpenAI adds MCP support to Agents SDK

#192

Post by jinushaun »

gnatolf wrote: post #169
soulofmischief wrote: post #119

Earlier quoted context omitted.

LangChain is an objectively terrible Frankenstein's monster of an API. If you were a good developer in your youth, you'd have still held it in contempt, and treat MCP with caution. The MCP API is pretty bad, too, it's just that a paradigm is starting to emege regarding modularity, integration and agentic tooling, and MCP happens to be the only real shot in that direction st this particular moment.

Could you elaborate on your issues with LangChain? We're kinda headed towards using it as it seems to be a flexible enough abstraction that is relatively stable to work with, so I'd like to know if I'm overlooking something..?

You spend more time fighting the tool/framework than working on the product you’re trying to build.

Re: OpenAI adds MCP support to Agents SDK

#193

Post by davedx »

tlrobinson wrote: post #111
_pdp_ wrote: post #75

Earlier quoted context omitted.

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…

100%. I know I’m in the “get off my lawn” phase of my career when I see things like MCP and LangChain, but know I would have been excited about them earlier in my career.

I’m seriously considering getting out of IT because of it

Re: OpenAI adds MCP support to Agents SDK

#194

Post by davedx »

gnatolf wrote: post #169
soulofmischief wrote: post #119

Earlier quoted context omitted.

LangChain is an objectively terrible Frankenstein's monster of an API. If you were a good developer in your youth, you'd have still held it in contempt, and treat MCP with caution. The MCP API is pretty bad, too, it's just that a paradigm is starting to emege regarding modularity, integration and agentic tooling, and MCP happens to be the only real shot in that direction st this particular moment.

Could you elaborate on your issues with LangChain? We're kinda headed towards using it as it seems to be a flexible enough abstraction that is relatively stable to work with, so I'd like to know if I'm overlooking something..?

A big soup of untyped json blobs and python, all working highly asynchronously in complicated ways.

Is this variable available in my agent’s state?

Depends! Is it an agent that started an hour ago before you made that other change? Is it in the manager state or not? Did the previous agent run correctly or not? Did something else go wrong?

Re: OpenAI adds MCP support to Agents SDK

#195

Post by ondrsh »

freeone3000 wrote: post #89
ondrsh wrote: post #70

Earlier 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 :)

Unfortunately, MCP is not HATEOAS. It doesn't need to be, because it's not web-like. I wish it were.

HATEOAS is great for web-like structures because in each response it not only includes the content, but also all actions the client can take (usually via links). This is critical for architectures without built-in structure — unlike Gopher which has menus and FTP and Telnet which have stateful connections — because otherwise a client arriving at some random place has no indication on what to do next. MCP tackles this by providing a stateful connection (similar to FTP) and is now moving toward static entry points similar to Gopher menus.

I specifically wrote about why pure HATEOAS should come back instead of MCP: https://www.ondr.sh/blog/ai-web

Re: OpenAI adds MCP support to Agents SDK

#197

Post by paradite »

ondrsh wrote: post #190
paradite wrote: post #179

Earlier quoted context omitted.

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 benef…

I see what you mean. It is a paradigm shift indeed if you look from the user's perspective.

Re: OpenAI adds MCP support to Agents SDK

#198

Post by mattmanser »

keithwhor wrote: post #155
ants_everywhere wrote: post #153

Earlier quoted context omitted.

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…

I don’t disagree. I fought this battle for a long time — ran a company where I tried to simplify SDK development by making every endpoint POST and JSON params; sorta like SOAP / just simple RPC. Why do you need all the HTTP methods when most SDKs simplify everything to .retrieve etc, why not name the endpoints that? What I realized was that these specs are valuable because they’re stable over long periods of time and…

I don't feel that's really true, it's easy to forget how fast things have moved.

For a long time lots of servers didn't really support PUT or DELETE, and it was only the early 2010s that it became common.

It's still a problem sometimes that you have to explicitly enable them (I'm looking at you IIS + WebDAV).

PATCH wasn't even added till 2010 and you still don't see it commonly used.

Perhaps we have different understandings of 'stable' and 'many years'.

I also agree with you on RPC, it's pretty ridiculous that some guys tried to boil every single API down to essentially 4 verbs. I remember when Google went all crazy on implementing pure REST and their APIs were atrocious.

And everyone still goes along with it even though it clearly doesn't work, so you always end up with a mix of REST and RPC in any non-trivial API.

But pure RPC doesn't really work as then you have to change every call to a POST, as you mention. Which is also confusing as everyone is now used to using the really restricted REST CRUD interface.

So now pure REST sucks and pure RPC sucks. Great job HTTP standards team!

To be fair to them, I know it's hard and at some point you can't fix your mistakes. These days I guess I've just accepted that almost all standards are going to suck a bit.

Re: OpenAI adds MCP support to Agents SDK

#199

Post by ondrsh »

vykthur wrote: post #120
ondrsh wrote: post #70

Earlier 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…

This a good characterisation of functionality MCP might enable. Thanks. In your opinion, what percentage of apps might benefit from this model where end users bring their own MCP tools to extend the capabilities of your app. What are some good examples of this - e.g., a development tool like Cursor, WindSurf likely apply, but are there others, preferable with end users? How is the user incentivized to upskill towards…

> In your opinion, what percentage of apps might benefit from this model where end users bring their own MCP tools to extend the capabilities of your app.

Long term close to 100%. Basically all long-running, user-facing applications. I'm looking through my dock right now and I can imagine using AI tools in almost all of them. The email client could access Slack and Google Drive before drafting a reply, Linear could access Git, Email and Slack in an intelligent manner and so on. For Spotify I'm struggling right now, but I'm sure there'll soon be some kind of Shazam MCP server you can hum some tunes into.

> How is the user incentivized to upskill towards finding the right tool to "bring in", installing it and then using it to solve their problem.

This will be done automatically. There will be registries that LLMs will be able to look through. You just ask the LLM nicely to add a tool, it then looks one up and asks you for confirmation. Running servers locally is an issue right now because local deployment is non-trivial, but this could be solved via something like WASM.

> How do we think about about the implications of bring your own tools, knowing that unlike plugin based systems (e.g,. Chrome/extensions), MCP servers can be unconstrained in behaviour - all running within your app

There are actually 3 different security issues here.

#1 is related to the code the MCP server is running, i.e. the tools themselves. When running MCP servers remotely this obviously won't be an issue, when running locally I hope WASM can solve this.

#2 is that MCP servers might be able to extract sensitive information via tool call arguments. Client applications should thus ask for confirmation for every tool call. This is the hardest to solve because in practice, people won't bother checking.

#3 is that client applications might be able to extract sensitive information from local servers via tool results (or resources). Since the user has to set up local servers themselves right now, this is not a huge issue now. Once LLMs set them up, they will need to ask for confirmation.

Re: OpenAI adds MCP support to Agents SDK

#200

Post by imtringued »

michaelsbradley wrote: post #146
keithwhor wrote: post #64

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

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 [2] https://www.jsonrpc.org/specification

The big irony behind HATEOAS is that LLMs are the mythical "evolvable agents" that are necessary to make HATEOAS work in the first place. HATEOAS was essentially built around human level intelligence that can automatically crawl your endpoints and read documentation written in human language and then they scratched their head why it didn't catch on.

Only browser like clients could conform to HATEOAS, because they essentially delegate all the hard parts (dealing with a dynamically changing structureless API) to a human.

Post reply on HN