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

231–240 of 281 posts

Re: OpenAI adds MCP support to Agents SDK

#231

Post by OrangeMusic »

jtrn wrote: post #10

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

GraphQL looks like an even better choice - it really looks like they re-invented the wheel here.

Re: OpenAI adds MCP support to Agents SDK

#232

Post by Xelynega »

ondrsh wrote: post #104
kblissett wrote: post #96

Earlier quoted context omitted.

Isn't this just the same paradigm as plugins?

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…

> And because this can now happen at runtime, users (instead of developers) can add arbitrary functionality to applications.

I don't understand what you mean by this. Currently without MCP a server has an API that's documented and to interact with it(thus provide "arbitrary functionality") you call those APIs from your own application code(e.x. python script).

With MCP an LLM connected to your application code calls an API that's documented via MCP to provide "arbitrary functionality".

How are these different, and how does MCP allow me to do anything I couldn't before with API access and documentation? In both cases the application code needs to be modified to account for the new functionality, unless you're also using the LLM to handle the logic which will have very unpredictable results.

Re: OpenAI adds MCP support to Agents SDK

#233

Post by Xelynega »

sethaurus wrote: post #205
slt2021 wrote: post #177

Earlier quoted context omitted.

transport argument is irrelevat when http can be both TCP and UDP, and even if you wanna do one protocol, it can be proxied/tunneled via another protocol transparently via VPN/wireguard/proxy. so transport protocol is moot, especially from latency perspective when most time is spent doing AI inference (seconds) rather than passing packets (milliseconds). I really wish OpenAI just embraced OpenAPI and that would have…

It's transport-agnostic in the sense that it works locally (over stdout), not just remotely. It's not just for web-services. That's why HTTP isn't baked into this.

HTTP also works locally(over local files including stdin/stdout), not just remotely.

Re: OpenAI adds MCP support to Agents SDK

#234

Post by Xelynega »

nomilk wrote: post #143
consumer451 wrote: post #100

Earlier quoted context omitted.

I only use one regularly, but I use it a lot. (Supabase) Example use case: https://news.ycombinator.com/item?id=43466434

I think I’m starting to see the potential.. So I could MPC cursor to my local Postgres (or, after some practice to build confidence, prod Postgres). Then use cursor to help debug. This sounds risky but very useful if it works as intended!

Is this not just hiding the "complexity" of SQL behind an LLM and hoping for the best?

If you know SQL and know what you're trying to find, what can the LLM do quickly that you couldn't just constructing a query to get what you want?

Alternatively if you don't know SQL, aren't you never going to learn it if every opportunity you have you bust out an LLM and hope for the best?

Re: OpenAI adds MCP support to Agents SDK

#235

Post by dan-kwiat »

pulkitsh1234 wrote: post #185
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": {…

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

I just made a tool which parses any OpenAPI spec to MCP spec: https://www.open-mcp.org (literally just deployed so I don't know if the DNS has propagated globally yet..)

Re: OpenAI adds MCP support to Agents SDK

#236

Post by orangebread »

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!

Re: OpenAI adds MCP support to Agents SDK

#237

Post by taude »

fsndz wrote: post #11
tcdent wrote: post #4

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

so we no longer need langchain and stuff like that, that's a win. But MCP also feels a bit overrated: https://www.lycee.ai/blog/why-mcp-is-mostly-bullshit

there's a reason there's MCP plugins for LangChain. Some companies will need massively customized workflows that LangChain is appropriate for, where it only needs to dig into a couple potentially publically accessed MCPS for things.

I could see a future where companies have their developer portal where now they have their APIs document, the pretty in swagger, the samples, etc, but they'll have a MCP endpoint (potentially), where they're safely exposing the data to an LLM. Your langchain node step to to get context, could call out to some of these hosted/shared mcps where you do standard stuff, like post to a Slack channel, grab some data from a SFDC instance, etc....

Re: OpenAI adds MCP support to Agents SDK

#238

Post by michaelsbradley »

imtringued wrote: post #200
michaelsbradley wrote: post #146

Earlier quoted context omitted.

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

Well, like I wrote, "giving a pass on HATEOAS".

With e.g. JSON over HTTP, you can implement an API that satisfies the stateless-ness constraint of REST and so on. Without hypermedia controls it would fit at Level 2 of the RMM, more or less.

In that shape, it would still be a different beast from RPC. And a disciplined team or API overlord could get it into that shape and keep it there, especially if they start out with that intention.

The problem I've seen many times is that a JSON over HTTP API can start out as, or devolve into, a messy mix of client-server interactions and wind up as ad hoc RPC that's difficult to maintain and very brittle.

So, if a team/project isn't committed to REST, and it's foreseeable that the API will end up dominated by RPC/-like interactions, then why not embrace that reality and do RPC properly? Conforming to a specification like JSON-RPC can be helpful in that regard.

Re: OpenAI adds MCP support to Agents SDK

#239

Post by zambachi »

pcarolan wrote: post #85
_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…

Yeah, I had more luck with just giving an ai the openapi spec and letting it figure everything out. I like a lot about MCP (structure, tool guidance, etc), but couldn't it just have been a REST API and a webserver?

I think people often think of their specific use-case and tend to forget the bigger picture. MCP does not force one transport or the other and that is great—use any transport you want as long as it uses JSON RPC as the payload.

The two built in transports are also extremely minimalistic and for SSE transport use regular HTTP—no need for web sockets or other heavier dependencies because SSE events are lightweight and broadly supported.

Re: OpenAI adds MCP support to Agents SDK

#240

Post by zambachi »

soulofmischief wrote: post #119
tlrobinson wrote: post #111

Earlier quoted context omitted.

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.

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.

How is the MCP API bad? It uses simple and widely available standards-based transports while still allowing custom transport implementations, along with a simple API that can be used easily without any libraries, in any programming language under the sun?
Post reply on HN