Live data from Hacker News

OpenAI adds MCP support to Agents SDK

openai.github.io

221–230 of 281 posts

Re: OpenAI adds MCP support to Agents SDK

#221

Earlier quoted context omitted.

Oh, it’s the new HATEOAS? A pluggable framework for automatic discoverability of HTTP APIs is incredibly useful, and not just for AI :)

No, you can't understand it until you understand that the world isn't all webshit and not everything is best used via REST . (Not even webshit is best used by REST, as evidenced by approximately every "REST" API out there, designed as RPC over HTTP pretending it's not.)

Nevertheless, MCP is a “webshit” protocol (even in stdio mode), so if web protocols are unsuitable for your problem, MCP would be as well.

Re: OpenAI adds MCP support to Agents SDK

#222
post #61
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.

I prefer this interpretation: MCP Isn’t the USB-C of AI — It’s Just a USB-C(laude) Dongle https://dev.to/internationale/mcp-is-not-ai-usb-c-its-usb-cl... The illustrations are on their official website. I find it hard to respect a company that invented dongle and claims to have invented USB

> MCP, despite its open-source claim, heavily relies on proprietary interfaces from Anthropic's Claude model. Thus, the proclaimed openness is surface-level at best, creating subtle but significant barriers within the ecosystem.

This strikes me as fundamentally untrue, but I'd love to see an example of this in the source code or documentation.

Re: OpenAI adds MCP support to Agents SDK

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

http endpoint + function calling can do what MCP do, this extra bad named layer is just jargon festish

Okay, but we should have a standard around that, right? Something like... a protocol?

Re: OpenAI adds MCP support to Agents SDK

#224

Earlier quoted context omitted.

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

Hype isn’t free. Maybe the benefit is mutual, but I can’t tell how Anthropic gets paid. Anthropic subsidizes an open standard, but proprietary extensions later emerge that lock you into servers from their marketplace or something? I need a sociopath to help me understand this.

There's already like a half dozen such "marketplaces" and they all ultimately point to open source repos. If the goal was to lock people in, they did a bad job of it.

Re: OpenAI adds MCP support to Agents SDK

#225
post #75

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 am actually working on such a thing, and I want to get it righr. This is like RSS or Atom or Jabber or XMPP wars. Or OpenGraph vs Twitter’s meta tags etc. I want interoperability which is cool, but I also want it to seamlessly interoperate with human roles and services.

What is the best way to connect with you? I would like to discuss ideas and protocols if you’re up for that.

Re: OpenAI adds MCP support to Agents SDK

#226
post #93

What are people using MCPs for? I search on youtube and see a lot of videos explaining how MCPs work, but none showing practical uses for a programmer (aside from getting the weather via cursor).

I mainly use simple integrations:

- fetch, essentially curl any webpage or endpoint

- filesystem, read(and occasionally write) to local disk

- mcp-perplexity, so I can essentially have Claude sample from perplexity's various models and/or use it for web search. Somewhat superseded by Claude's own new web search capability, but perplexity's is generally better.

Re: OpenAI adds MCP support to Agents SDK

#227
post #143

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!

AS far as risk, I cannot imagine using an MCP with write capabilities to a DB, the Supabase one is read-only, which is perfect.

Re: OpenAI adds MCP support to Agents SDK

#228
post #6

Does anyone know how MCP servers would be used via the API? I thought they ran locally only, so how would the OpenAI API connect to them when handing a request?

You'd use a client which runs locally to coordinate between the LLM/agent and the available tools, similarly to how it's described here https://modelcontextprotocol.io/quickstart/client There are a variety of available clients documented here https://modelcontextprotocol.io/clients If you haven't tried any of these yet, the first place to start is Claude Desktop. If you'd like to write your own agents, consider https…

You can run remote MCP servers and configure whatever client to use them. This should work even via OpenAI's API(perhaps not yet, but it's just another 'tool' to call)

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

Re: OpenAI adds MCP support to Agents SDK

#229
post #75

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…

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 is nice so you can expose different levels of "data-depth" which is very useful in controlling cost (i.e. context window) and performance of LLM apps.

In case anybody else wants to call GraphQL APIs as tools in their chatbot/agents/LLM apps, we open sourced a library for the boilerplate code: https://github.com/DataSQRL/acorn.js

Re: OpenAI adds MCP support to Agents SDK

#230
The real benefit I see from mcp is that we are now writing programs for users and ai assistants/agents.

By writing mcp servers for our services/apps we are allowing a standardized way for ai assistants to integrate with tools and services across apps.

Post reply on HN