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

271–280 of 281 posts

Re: OpenAI adds MCP support to Agents SDK

#271

Post by davedx »

romankolpak wrote: post #213
davedx wrote: post #193

Earlier quoted context omitted.

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

because of MCP and langchain?

Eh, more the wider cultural effects of them. Vibe coding, everyone now creating kitchen sink apps that do everything under the sun, k8s everywhere, agents everywhere. It feels like a big part of the industry has lost all focus and is sprinting towards some endless vague panacea instead of focusing on solving specific well defined business problems.

It’s always been a bit like this but it feels particularly bad since AI hit mainstream coding tooling. Just my 2c :)

Re: OpenAI adds MCP support to Agents SDK

#272

Post by dartos »

Spivak wrote: post #265
nsonha wrote: post #162

Earlier quoted context omitted.

I feel like we should have transport agnostic RPC by now, GRPC? And MCP is stateless too. And you don't have to create a client per API, it's up to implementation.

Are we reading the same documents? MCP implementations are all websockets so it's not really transport agnostic. They try to talk about how you can use other transports but its just that it's JSON-RPC and if you're willing to code both ends you can do whatever… which is always true. And MCP is explicitly a stateful protocol [1]. https://spec.modelcontextprotocol.io/specification/2025-03-2... * JSON-RPC message format…

https://spec.modelcontextprotocol.io/specification/2025-03-2...

They mention stdio specifically under the transport section of the spec.

Most protocols are transport agnostic, but http APIs tend to require HTTP methods. Http itself is transport agnostic, but truthfully all we’re doing is shuffling bytes around.

If you look at the stateless examples in that PR, they both assume some state (specifically the capabilities) and just behave accordingly.

To get the full features of the protocol (like notifications) a stateful connection would still be required.

Re: OpenAI adds MCP support to Agents SDK

#273

Post by Xelynega »

ondrsh wrote: post #259
Xelynega wrote: post #257

Earlier quoted context omitted.

I don't understand this at all. If my application performs some function dependant on data from an API(e.x. showing tax information, letting a user input tax information, and performing tax calculations and autocomplete), how do I extend that UI easier with MCP than with an HTTP REST API. Even with MCP I need to update my application code to add UI elements(inputs, outputs) for a user to interact with this new functi…

No, MCP does not include any concept of UI (yet). Tool results are usually text only, although there is also the abstraction of an Image (which can be displayed as clients as decide to, e.g. inline).

So no application code needs to be changed because no application code exists.

Isn't that like saying you don't need to modify application code with an REST API if your "application" is just a list of instructions on how to use wget/bash to accomplish the task?

Re: OpenAI adds MCP support to Agents SDK

#274

Post by Ey7NFZ3P0nzAe »

orangebread wrote: post #236
bob1029 wrote: post #26

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…

I would think of MCP as a "plugin" for AI. 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!

More like a "plugin system" than a "plugin"

Re: OpenAI adds MCP support to Agents SDK

#275

Post by vykthur »

_pdp_ wrote: post #75
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": {…

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…

I tend to agree here. Alot of the use cases are around STDIO and using MCPs within existing apps like Cursor/Windsurf etc. Most developers want to build and integrate their own tools and the complexity required here (build out the server, bundle a client, and the additional latency) is probably not worth the ROI. There also seems to be a notion that security is "handled" by MCP which might be premature. I mean, there are several good decisions in the standard (tls with sse, sampling etc), but critical choices around auth and scope for agents or 3rd party mcp providers are still wide open IMO.

Overall, a step in the right direction, but still early. I wrote more on this here. https://newsletter.victordibia.com/p/no-mcps-have-not-won-ye...

Re: OpenAI adds MCP support to Agents SDK

#276

Post by sarthak_chauhan »

_pdp_ wrote: post #84
keithwhor wrote: post #79

Earlier quoted context omitted.

The `stdio` approach for local services makes complete sense to me. Including using JSONRPC. But for remote HTTP MCP servers there should be a dead simple solution. A couple years ago OpenAI launched plugins as `.well-known/ai-plugin.json`, where it'd contain a link to your API spec, ChatGPT could read it, and voila. So all you needed to implement was this endpoint and ChatGPT could read your whole API. It was pretty…

I agree. What OpenAI did was simple and beautiful. Also, I think there is a fundamental misunderstanding that MCP services are plug and play. They are not. Function names and descriptions are literally prompts so it is almost certain you would need to modify the names or descriptions to add some nuances to how you want these to be called. Since MCP servers are not really meant to be extensible in that sort of way, th…

It’s not just about passing prompts — in production systems like Ramp’s, they had to build a custom ETL pipeline to process data from their endpoints, and host a separate database to serve structured transaction data into the LLM context window effectively.

We’ve seen similar pre-processing strategies in many efficient LLM-integrated APIs — whether it’s GraphQL shaping data precisely, SQL transformations for LLM compatibility, or LLM-assisted data shaping like Exa does for Search.

https://engineering.ramp.com/ramp-mcp

PS: When building agents, prompt and context management becomes a real bottleneck. You often need to juggle dynamic prompts, tool descriptions, and task-specific data — all without blowing the context window or inducing hallucinations. MCP servers help solve this by acting as a "plug-and-play" prompt loader — dynamically fetching task-relevant prompts or tool wrappers just-in-time. This leads to more efficient tool selection, reduced prompt bloat, and better overall reasoning for agent workflows.

Re: OpenAI adds MCP support to Agents SDK

#277

Post by sarthak_chauhan »

vykthur wrote: post #275
_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…

I tend to agree here. Alot of the use cases are around STDIO and using MCPs within existing apps like Cursor/Windsurf etc. Most developers want to build and integrate their own tools and the complexity required here (build out the server, bundle a client, and the additional latency) is probably not worth the ROI. There also seems to be a notion that security is "handled" by MCP which might be premature. I mean, there…

How much of this is already addressed by Cloudflare’s Remote MCP setup? https://blog.cloudflare.com/remote-model-context-protocol-se...

Re: OpenAI adds MCP support to Agents SDK

#278

Post by sarthak_chauhan »

rcarmo wrote: post #189
_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…

Exactly my points: https://taoofmac.com/space/notes/2025/03/22/1900

https://engineering.ramp.com/ramp-mcp

https://blog.cloudflare.com/remote-model-context-protocol-se...

Re: OpenAI adds MCP support to Agents SDK

#279

Post by sarthak_chauhan »

soulofmischief wrote: post #207
TeMPOraL wrote: post #191

Earlier quoted context omitted.

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

A non-exhaustive list of concerns: - How does a consumer of a remote MCP server trust that it is not saving/modifying their data, or that it is doing something other than what it said it would? - How does a consumer of a local MCP server trust that it won't wreck their machine or delete data? - How do servers authorize and authenticate end users? How do we create servers which give different permissions to different…

would love your thoughts on this: https://blog.cloudflare.com/remote-model-context-protocol-se...

Re: OpenAI adds MCP support to Agents SDK

#280

Post by 0x008 »

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

so if it does not enforce a particular transport layer, it just defines a couple of methods on top of jsonrpc?

or is there more to it?

Post reply on HN