Live data from Hacker News

OpenAI adds MCP support to Agents SDK

openai.github.io

21–30 of 281 posts

Re: OpenAI adds MCP support to Agents SDK

#21
post #11
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

> But MCP also feels a bit overrated:

VCs invested in AI and agentic companies needed a way to get you guys to accelerate agents this year.

So why not "create" artificial hype for MCPs on the internet, since there were little to no MCP servers for LLMs to use despite it being several months old (November 2024) until Cursor integrated it.

This is the true reason why you see them screaming about MCPs everywhere.

Re: OpenAI adds MCP support to Agents SDK

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

Standards might not have been _the_ problem, but they were _a_ problem. Before MCP I couldn't distribute a tool call that could be configured by end-users to be used with multiple mainstream clients.

Re: OpenAI adds MCP support to Agents SDK

#23
post #16
post #11

Earlier quoted context omitted.

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

That article seems to miss the point by being incurious about _why_ there is hype around MCP instead of LangChain, LangGrah, SmolAgents, LlamaIndex, etc. We've had tool call frameworks before, but we haven't had a way of making tools that our clients actually talked to. There was no way to build tools that other people could download and run locally without getting them to switch to a client that baked those tools in…

> That article seems to miss the point by being incurious about _why_ there is hype around MCP instead of LangChain, LangGrah, SmolAgents, LlamaIndex, etc.

The VCs that were invested in AI companies (like Cursor) would of course need to hype something up like MCPs to get us to build them as little of those tools did not exist.

Cursor already makes $100M+. So why not get behind and integrate this chosen standard to make even more money with more MCP servers.

The last ingredient is to hype it all up on the internet to get everyone building.

A win for the VCs regardless even though it was suspiciously orchestrated as soon as Cursor integrated it.

Re: OpenAI adds MCP support to Agents SDK

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

There's already swagger MCP service out there, I don't know how production ready it is, but I saw something the other day when searching through GitHu. One of several implementations: https://github.com/dcolley/swagger-mcp

Re: OpenAI adds MCP support to Agents SDK

#25
post #21
post #11

Earlier quoted context omitted.

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

> But MCP also feels a bit overrated: VCs invested in AI and agentic companies needed a way to get you guys to accelerate agents this year. So why not "create" artificial hype for MCPs on the internet, since there were little to no MCP servers for LLMs to use despite it being several months old (November 2024) until Cursor integrated it. This is the true reason why you see them screaming about MCPs everywhere.

So the main criticism is a borderline conspiracy theory about VC's creating artificial hype for it?

Re: OpenAI adds MCP support to Agents SDK

#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 constructed by the marketing wizards at these companies. Even things like tool/function calling are clever heuristics over plain-ass text.

> Currently, the MCP spec defines two kinds of servers, based on the transport mechanism they use: ...

This looks like micro services crossed with AI. I don't think many are going to have a happy time at the end of this adventure.

Re: OpenAI adds MCP support to Agents SDK

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

Whatever the current state, if everyone throws their shoulders behind a common interface, we all win.

Re: OpenAI adds MCP support to Agents SDK

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

> What is there to standardize?

At a high level, the request format and endpoints. Instead of needing to write a bespoke connector for every type of context that matches their preferred API standards, I just tell my client that the server exists and the standard takes care of the rest.

Do you have similar doubts about something like gRPC?

> This looks like micro services crossed with AI.

Seems like a cynical take with no substance to me. What about a standard request protocol implies anything about separation of concerns, scaling, etc?

Re: OpenAI adds MCP support to Agents SDK

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

If you're interested, I'd encourage you to implement an MCP integration and see if you change your mind.

For instance, I have a little 'software team in a box' tool. v1 integrated github and three different llms manually (react + python backend). This is fine. You can call github commands via CLI on the backend, and add functionality somewhat easily, depending on the LLM's knowledge.

Pain points -- if you want workflow to depend on multiple outputs from these pieces, (e.g. see that there's a pull request, and assess it, or see that a pull request is signed off on / merged, and update something) -- you must code most of these workflows manually.

v2, I wiped that out and have a simple git, github and architect MCP protocol written up. Now I can have claude as a sort of mastermind, and just tell it "here are all the things you can do, please XXX". It wipes out most of the custom workflow coding and lets me just tell Claude what I'd look to do -- on the backend, my non-LLM MCP server can deal with things it's good at, API calls, security checks, etc.

Post reply on HN