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

241–250 of 281 posts

Re: OpenAI adds MCP support to Agents SDK

#241

Post by richsong »

antupis wrote: post #175
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": {…

Why is this get_weather location "New York" always an example when people talk about tool calling?

1/ pre-trained models don't know current weather

2/ easy enough for people to understand

Re: OpenAI adds MCP support to Agents SDK

#242

Post by dartos »

nsonha wrote: post #162
dartos wrote: post #14

Earlier quoted context omitted.

> I can’t really see anything that is made better by MCP over OpenAPI Well it’s transport agnostic, for one. I think a big part of it is defining a stateful connection and codifying the concepts of prompts and tools. Another issue with OpenAPI / swagger is that you still need to create a client per API, but with MCP it’s all uniform.

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.

I think MCP is a layer higher than grpc. MCP can be implemented on gRPC

Mcp is definitely not stateless. It’s explicitly stateful…

See the 2nd bullet where it says “stateful connections” [1]

And I was saying that with OpenAPI, you need a client per API, or at least a series of http api calls.

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

Re: OpenAI adds MCP support to Agents SDK

#244

Post by neilv »

ginko wrote: post #40

Master Control Program?

Someone at Anthropic might've had a sense of humor when they named integrating LLMs with the outside world... after a pop-culture evil AI.

https://tron.fandom.com/wiki/Master_Control_Program

Don't hook up the MCP to any lab equipment:

https://www.youtube.com/watch?v=lAcYUt2QbAo

Re: OpenAI adds MCP support to Agents SDK

#245

Post by sebazzz »

ondrsh wrote: post #70
talles wrote: 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.

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…

So MCP to an application is like how a WebDriver interface is to a Web browser?

Re: OpenAI adds MCP support to Agents SDK

#246

Post by zomglings »

dan-kwiat wrote: post #235
pulkitsh1234 wrote: post #185

Earlier quoted context omitted.

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

I received a 500 response when I attempted to create an MCP server for an API.

I was using this URL: https://engineapi.moonstream.to/metatx/openapi.json

The response body:

    {success: false, error: "Server URL must start with https:// or http://"}

Re: OpenAI adds MCP support to Agents SDK

#247

Post by _pdp_ »

mbroecheler wrote: post #229
_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…

Second that. A lot of our use cases are "remote tooling", i.e. calling APIs. Implementing an MCP server to wrap APIs seems very complex - both in terms of implementation and infrastructure. We have found GraphQL to be a great "semantic" interface for API tooling definitions since GraphQL schema allows for descriptions in the spec and is very humanly readable. For "data-heavy" AI use cases, the flexibility of GraphQL…

Oh wow. Amazing. I did not think of that. I am not fan of GraphQL but you might be onto something here. I have not checked the code and perhaps this is not the right channel for this but my read is that this library allows any generic GraphQL server to exposed in this sort of way?

Re: OpenAI adds MCP support to Agents SDK

#248

Post by ondrsh »

Xelynega wrote: post #232
ondrsh wrote: 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…

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

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

In the case of MCP, no application code is modified. You first ship the application and then functionality is added. Using plain APIs, it's the other way around. That's the difference.

Re: OpenAI adds MCP support to Agents SDK

#249

Post by ondrsh »

jglamine wrote: post #163
ondrsh wrote: 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…

I really enjoyed both your blog posts. You've clearly thought about this a lot and explained things well. I'd love to subscribe to be updated on your next post (even if it's not for months/years). Any chance you could add an RSS feed to your blog?

Thanks. Added RSS, but WC3 shows some errors. I'll move to plain markdown when I have more time, then this will be easier.

Re: OpenAI adds MCP support to Agents SDK

#250

Post by dan-kwiat »

zomglings wrote: post #246
dan-kwiat wrote: post #235

Earlier quoted context omitted.

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

I received a 500 response when I attempted to create an MCP server for an API. I was using this URL: https://engineapi.moonstream.to/metatx/openapi.json The response body: {success: false, error: "Server URL must start with https:// or http://"}

Thanks, I just added support for relative URLs, try again. Your OpenAPI spec defines a relative base URL for the server /metatx but no domain. You can now specify the full base URL in your MCP client's environment variables:

`OPEN_MCP_BASE_URL="https://engineapi.moonstream.to/metatx"`

Post reply on HN