So we’re back to programming?
OpenAI adds MCP support to Agents SDK
71–80 of 281 posts
Re: OpenAI adds MCP support to Agents SDK
#72claude needed these those tools in 2024, so having the community contribute for free was actually a smart move. service providers get more traffic, so they’re into it. makes sense. claude 3.5 was great at the time, especially for stuff like web dev. but now deepseek v3 (0324) is way better value. gemini's my default for multimodal. openai still feels smartest overall. i’ve got qwq running locally. for deep research,…
You should take a look at how Claude Code does its permissioning. It's totally fine to connect it right up to your GitHub MCP server because it'll ask each time it wants to take an action (and you can choose "don't ask again for this tool" if it's an obviously safe operation like searching your PRs).
First, I don't want to pay Claude Code at all...
Second, isn't that doable with API calling :)
Re: OpenAI adds MCP support to Agents SDK
#73I'm curious what the revenue plan is for MCP authors. I mean, I can see wanting to add support for existing products (like an code/text editor, image/sound/video editor, etc.)
But is there a market for stand-alone paid MCP services? It seems these will mostly be usurped by the models themselves sooner or later. I mean if you create a MCP popular enough to actually make money, the foundation model will soon be able to just do it without your service. Almost like you are doing experimentation on high-value agent features for free.
Also, something about the format just reeks of SOAP to me. It feels over-engineered. Time will tell, obviously.
Re: OpenAI adds MCP support to Agents SDK
#74Earlier 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…
Tool calls in any of the agent frameworks are just wrappers around native functions.
MCP let's you handle the processing outside of the agent context, redistribute tools independently, and provide them as either private or public hosted services.
Basically, add an HTTP layer on the existing concept of tools. It is not a replacement for a framework, it is an enhancement of a well established pattern.
Re: OpenAI adds MCP support to Agents SDK
#75Today 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 believe it is the right approach at all. A simpler HTTP-based OpenAPI service would have been a lot better and it is already well supported in all frameworks.
The only way I can make sense of MCP in the context of an STDIO.
Re: OpenAI adds MCP support to Agents SDK
#76MCP is great. But what i'd like to understand is whats the difference between MCP and manually prompting the model a list of tools with description and calling the specific function based on the llm response ?
Re: OpenAI adds MCP support to Agents SDK
#77This seems to be just implementing tools functionality, no resources or prompts, roots or sampling. I can't blame them.
I'm wondering though about progress notifications and pagination. Especially the latter should be supported as otherwise some servers might not return the full list of tools. Has anyone tested this?
Re: OpenAI adds MCP support to Agents SDK
#78I'm curious what the revenue plan is for MCP authors. I mean, I can see wanting to add support for existing products (like an code/text editor, image/sound/video editor, etc.) But is there a market for stand-alone paid MCP services? It seems these will mostly be usurped by the models themselves sooner or later. I mean if you create a MCP popular enough to actually make money, the foundation model will soon be able to…
Not asked contentiously, why does a MCP revenue plan need to exist?
It feels like any kind of api-client work any organization or project would build to make users/customers happy and sticky.
Re: OpenAI adds MCP support to Agents SDK
#79Today 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…
The `stdio` approach for local services makes complete sense to me. Including using JSONRPC.
But for remote HTTP MCP servers there should be a dead simple solution. A couple years ago OpenAI launched plugins as `.well-known/ai-plugin.json`, where it'd contain a link to your API spec, ChatGPT could read it, and voila. So all you needed to implement was this endpoint and ChatGPT could read your whole API. It was pretty cool.
ChatGPT Plugins failed, however. I'm confident it wasn't because of the tech stack, it was due to the fact that the integration demand wasn't really there yet: companies were in the early stages of building their own LLM stacks, ChatGPT desktop didn't exist. It also wasn't marketed as a developer-first global integration solution: little to no consistent developer advocacy was done around it. It was marketed towards consumers and it was pretty unwieldy.
IMO the single-endpoint solution and adhering to existing paradigms is the simplest and most robust solution. For MCP, I'd advocate that this is what the `mcp/` endpoint should become.
Edit: Also tool calling in models circa 2023 was not nearly as good as it is now.
Re: OpenAI adds MCP support to Agents SDK
#80> 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…
I can’t express how much I agree with your perspective. It’s a completely different/total shift in how we might deliver functionality and… composability to users.
Well said.