JSON-RPC over HTTP just to make a tool call? At some point, MCP starts to feel like a wrapper around a wrapper.
OpenAI adds MCP support to Agents SDK
261–270 of 281 posts
Re: OpenAI adds MCP support to Agents SDK
#262[dead]
Re: OpenAI adds MCP support to Agents SDK
#263Earlier quoted context omitted.
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?
Exactly, any generic GraphQL server can be turned into a set of LLM tools with minimal overhead and complexity.
Re: OpenAI adds MCP support to Agents SDK
#264Earlier 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?
the blog is hosted on substack which supports feeds.
Re: OpenAI adds MCP support to Agents SDK
#265Earlier 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.
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
* Stateful connections
* Server and client capability negotiation
There's a draft [1] maybe about resolving this.
https://github.com/modelcontextprotocol/specification/pull/2...
Re: OpenAI adds MCP support to Agents SDK
#266Today 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've been working on BLAH - Barely Logical Agent Host ( https://github.com/thomasdavis/blah/blob/master/packages/cli... ) for the past few weeks. It is essentially a standard (has a schema) that has an ecosystem of tools around it. (completely opensource, no protocol/bridge lockin, no vendor/provider lockin, no ide/client/auton lockin, http/sse/jsonrpc/whatever, local/remote, composable) So far I'm categorically call…
I agree, people don't want to manually add all MCP servers they want to connect to. I think we're headed in a direction where dynamic tool discovery will be important. E.g. I want to do "x" which requires doing "y" and "z". The client or server should then search for the tools (or agents as tools) that can do the job. So this would basically be a semantic search for which tools are most likely to do the job, then use those tools, and search for more tools if it needs to. RAG for tools, essentially. I wrote an article on how to give ChatGPT unlimited functions a year ago, where I implemented this method.
I basically created a vector database for functions, and created the store based on the tool description, then added the tool definition as metadata. Then for every request I ran a lookup for tools, added them to the tools list. Since tool definitions are added to the context we would have to do something like this at some stage when we want to implement a lot of tools.
https://blogg.bekk.no/function-retrieval-add-unlimited-funct...
Re: OpenAI adds MCP support to Agents SDK
#267Earlier quoted context omitted.
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.
Could you elaborate on your issues with LangChain? We're kinda headed towards using it as it seems to be a flexible enough abstraction that is relatively stable to work with, so I'd like to know if I'm overlooking something..?
Cryptic errors that will make you tear your hair out and docs that are constantly changing
Re: OpenAI adds MCP support to Agents SDK
#268Earlier quoted context omitted.
> 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 wit…
> At a high level, the request format and endpoints. I think we fundamentally disagree on what "request format" means in context of a large language model.
Because it's not a request format for LLMs, it's a request format for client software that is instrumenting LLMs. If you make a connector to say HomeAssistant to turn on/off your lights you're exposing a tool definition which is really just a JSON schema. The agent will present that tool to the LLM as one it's allowed to use, validate that the LLM matched your change_light_state tool schema and send off the appropriate API call to your server.
The spec is genuinely a hot fucking mess that looks like a hobby project by an overeager junior dev but conceptually it's just a set of JSON schemas to represent common LLM things (prompts, tools, files) and some verbs.
The useful content of the spec is literally just https://github.com/modelcontextprotocol/specification/blob/m... and even then it's a bit much.
Re: OpenAI adds MCP support to Agents SDK
#269Earlier quoted context omitted.
What’s wrong with this analogy? It’s a common set of APIs/protocols that includes a way to share data, capabilities, etc. That’s pretty much exactly what USB is.
This is what we used to just call "standards", but apparently we need analogies now in order to explain standards to new developers.
but it’s technically not a standard yet. Or not blessed as one by any neutral body or consortium etc.
It’s quickly becoming a de facto standard though, now that OpenAI has added it to their SDK.
It’s likely to be used to create a standard though (like with QUIC and HTTP3)
Re: OpenAI adds MCP support to Agents SDK
#270Earlier quoted context omitted.
This is what we used to just call "standards", but apparently we need analogies now in order to explain standards to new developers.
but it’s technically not a standard yet. Or not blessed as one by any neutral body or consortium etc. It’s quickly becoming a de facto standard though, now that OpenAI has added it to their SDK. It’s likely to be used to create a standard though (like with QUIC and HTTP3)
This is just an ontological issue. Is it a standard because it is designed to be one, or is it only a standard once it actually fulfills its role and is recognized as a standard? That's something we could debate all night. :)