18 ms·

OpenAI adds MCP support to Agents SDK

807 points by gronky_ 2y ago

gronky_ 2y ago
They’re all in. They announced they’ll add support for it in the desktop app and the API in the coming months: https://x.com/OpenAIDevs/status/1904957755829481737 https://x.com/OpenAIDevs/status/1904957755829481737
- emmanueloga_ 2y ago
  I'm surprised this was announced in a random tweet instead of a blog post with a release roadmap or something like that.
  - swyx 2y ago
    because its a lil embarrassing oai didnt come up with it
esafak 2y ago
That makes it table stakes for any agent framework.
tcdent 2y ago
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.
- fsndz 2y ago
  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 https://www.lycee.ai/blog/why-mcp-is-mostly-bullshit
  - esafak 2y ago
    I could not find the actual criticism in that article. What's the problem with MCP again? It's the first standard for agents.
    - fsndz 2y ago
      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.
      - esafak 2y ago
        That is not mentioned in the article. I am just becoming familiar with MCP myself so I suggest raising the issue: https://github.com/orgs/modelcontextprotocol/discussions https://github.com/orgs/modelcontextprotocol/discussions
      - paulgb 2y ago
        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.
      - mindwok 2y ago
        This is just moving the goalposts, MCP is not supposed to solve every problem with agents. It's meant to make it easier to provide easier, standardised ways for LLMs to interact with external tools, which it has done. Reliability is a completely different problem.
    - mkagenius 2y ago
      http endpoint + function calling can do what MCP do, this extra bad named layer is just jargon festish
      - knowaveragejoe 2y ago
        Okay, but we should have a standard around that, right? Something like... a protocol?
- otabdeveloper4 2y ago
  > MCP is now the industry standard for connecting LLMs to external tools. No it isn't. We're still five or ten years away from real standards. (Anyways it's clear that the future is smaller self-hosted LLMs, so whatever standard eventually emerges will be based on that paradigm.)
  - greyman 2y ago
    1) It isn't a standard yet, but what else apart from filesystem-mcp can be used for prompts like "write me README.md for this repo" (like really produce the file) 2) For me it is not clear the future is smaller self-hosted LLMs. As of today, most useful for me is to use best models, and those are not self-hosted.
    - otabdeveloper4 2y ago
      Once we get used to the fact that LLMs exist they won't be sold on the gee-whiz "wow, a talking assistant just like in my sci-fi movies!" factor. They'll be used for particular language classification and search tasks, and for that you'd want several lighter, faster, cheaper and more specialized models. Not one with an arbitrary "best" score that's based on tricking the Turing test.
  - liamwire 2y ago
    Sure, like how we all self-host our own email servers and photo albums? Honestly, I think you’re about as wrong as you could possibly be, both on timelines, and in that I’d argue the arc of consumer tech adoption bends towards centralisation most often. Standards are already emerging, including MCP, and to say that simply because they’ll evolve and be replaced over time means they’re not ‘real’ now is ridiculous. Look at the early internet and web as examples. Local models, even accounting for reasonable progress and device performance improvements, will always, inherently, be behind the eight ball compared to SOTA models. While they may be sufficient for the low hanging fruit, I’d not bet against the frontier models being every bit as compelling relatively speaking. Using weasel words like ‘real’ and ‘x is the future’ is astoundingly arrogant, and anyone claiming with confidence that they’ve got any idea where we’re heading is almost assuredly wrong.
simonw 2y ago
"Think of MCP like a USB-C port for AI applications." Given the enormous amounts of pain I've heard are involved in actually implementing any form of USB, I think the MCP community may want to find a different analogy!
- PufPufPuf 2y ago
  Since I've worked with the official MCP SDK, I find this analogy quite accurate
jswny 2y ago
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?
- peterldowns 2y ago
  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 https://modelcontextprotocol.io/quickstart/client There are a variety of available clients documented here https://modelcontextprotocol.io/clients 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://github.com/evalstate/fast-agent https://github.com/evalstate/fast-agent EDIT: I may have misunderstood your question. If you're asking "how can I make an API call to OpenAI, and have OpenAI call an MCP server I'm running as part of generating its response to me", the answer is "you can't". You'll want a proxy API that you call which is actually an MCP client, responsible for coordinating between the MCP servers and the OpenAI API upstream agent.
  - knowaveragejoe 2y ago
    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-servers-mcp/ https://blog.cloudflare.com/remote-model-context-protocol-se...
- bibryam 2y ago
  command mode is for local, and SSE for remote
larodi 2y ago
Claude is like years ahead of everyone else with tools and agentic caps.
- MoonGhost 2y ago
  Can't be. "It was launched by Anthropic back in November 2024," about MCP
  - senko 2y ago
    That's a few decades in AI time.
jtrn 2y ago
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 another standard.
- dartos 2y ago
  > 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.
  - nsonha 2y ago
    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.
    - dartos 2y ago
      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-26/#base-protocol https://spec.modelcontextprotocol.io/specification/2025-03-2...
      - nsonha 2y ago
        Higher in what way? But HOW is it stateful? That "mandate" the only occurence of that string "state" in that document.
TIPSIO 2y ago
I know Cloudflare has been talking about remote MCP for a while, does anyone have a solid example of this in practice?
jauntywundrkind 2y ago
I assume they're (for now at least) targeting the old HTTP+SSE version of MCP, and not the new Streaming HTTP version? https://github.com/modelcontextprotocol/specification/pull/206 https://github.com/modelcontextprotocol/specification/pull/2... There's some other goodies too. OAuth 2.1 support, JSON-RPC Batching... https://github.com/modelcontextprotocol/specification/blob/main/docs/specification/2025-03-26/changelog.md#major-changes https://github.com/modelcontextprotocol/specification/blob/m...
bob1029 2y ago
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.
- nlarew 2y ago
  > 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?
  - bob1029 2y ago
    > 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.
    - Spivak 2y ago
      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/main/schema/2025-03-26/schema.json https://github.com/modelcontextprotocol/specification/blob/m... and even then it's a bit much.
talles 2y ago
> 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.
- olddustytrail 2y ago
  You spend time with some weirdly technical moms.
- votick 2y ago
  I thought this was a "your mom is compatible with everyone" joke
  - nova22033 2y ago
    [flagged]
    - stavros 2y ago
      I don't know whether to laugh at the joke or be triggered that USB takes three turns to insert.
- jchw 2y ago
  Maybe they used an LLM to explain it. Gemini in particular is obsessed with these utterly useless analogies for everything, when I would prefer something closer to Wikipedia with more context. (Needless to say, I currently don't find LLMs useful for learning about things. That's a shame because that use case feels promising.)
  - colechristensen 2y ago
    LLMs are like an unlimited, poorly written encyclopedia. Often inaccurate or not entirely helpful, but will get you enough of an idea to find better sources. Sort of solving the "I don't know what I don't know" gap.
    - 2y ago
ginko 2y ago
Master Control Program?
- jtimdwyer 2y ago
  Who does he calculate he is?!?
- neilv 2y ago
  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 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 https://www.youtube.com/watch?v=lAcYUt2QbAo
unit149 2y ago
[dead]
shrisukhani 2y ago
MCP is now the standard everyone must conform to. Couldn't possibly have predicted that 2 months ago.
- todsacerdoti 2y ago
  Amazing how fast things are happening atm
- nilslice 2y ago
  We launched mcp.run in December ‘24 with that prediction (err, gamble ;) )
- otabdeveloper4 2y ago
  Wait two more months and there will be a different the standard.
keithwhor 2y ago
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": { "location": "New York" } } } Which traditionally would just be HTTP POST to `/get_weather` with `{ "location": "New York" }`. I've made the suggestion to remove some of this complexity [1] and fall back to just a traditional HTTP server, where a session can be negotiated with an `Authorization` header and we rely on traditional endpoints / OpenAPI + JSON Schema endpoint definitions. I think it would make server construction a lot easier and web frameworks would not have to materially be updated to adhere to the spec -- perhaps just adding a single endpoint. [0] https://spec.modelcontextprotocol.io/specification/2025-03-26/basic/transports/ https://spec.modelcontextprotocol.io/specification/2025-03-2... [1] https://github.com/modelcontextprotocol/specification/issues/236 https://github.com/modelcontextprotocol/specification/issues...
- _pdp_ 2y ago
  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.
  - keithwhor 2y ago
    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.
cruffle_duffle 2y ago
Was wondering if this would ever happen. I wrote an MCP server that hooked up Azure Monitor (or whatever the hell microsoft is calling it) via Microsoft's python SDK so I could get it to query our logs without using command line tools. Took about half a day, mostly due to writing against the wrong Microsoft SDK. It will be nice to let ChatGPT have a crack a this too!
chaosprint 2y ago
claude 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, free grok 3 and perplexity work fine. funny enough, claude 3.7 being down these two days didn’t affect me at all. i checked mcp since i contribute to open source, but decided to wait. few reasons: - setup’s kind of a mess. it’s like running a local python or node bridge, forwarding stuff via sse or stdio. feels more like bridging than protocol innovation - I think eventually we need all the app to be somehow built-in AI-first protocol. I think only Apple (maybe Google) have that kind of influence. Think about the lightening vs usb-c. - performance might be a bottleneck later, especially for multimodal. - same logic as no.2 but the question is that do you really want every app to be AI-first? main issue for me: tools that really improve productivity are rare. a lot of mcp use cases sound cool, but i'll never give full github access to a black box. same for other stuff. so yeah—interesting idea, but hard ceiling.
- striking 2y ago
  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).
  - chaosprint 2y ago
    First, I don't want to pay Claude Code at all... Second, isn't that doable with API calling :)
Tteriffic 2y ago
So we’re back to programming?
zoogeny 2y ago
I'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.
- amerine 2y ago
  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.
  - zoogeny 2y ago
    Right, that is why I said it makes sense for existing products. I mentioned desktop apps, but it would apply to any existing project. Like JIRA, or HubSpot, Wordpress, or Figma, etc. But there is hype around MCP as if independent devs could do something with it. And some will just for fun, some will for open source cred. But it is my experience that longevity is usually the result of stable revenue. I guess what I predict happening here is a few people will build some useful MCPs, realize there is no way to monetize despite generating a lot of interest and the most useful/popular MCPs will be integrated directly into the offerings of the foundational AI companies. And in a few years we won't even remember the acronym unless you happen to work for some big corp that wants to integrate your existing service into LLMs.
    - imtringued 2y ago
      The revenue plan for hosted services is that every user with an MCP client will count as a billable user.
- victorbjorklund 2y ago
izwasm 2y ago
MCP 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 ?
- victorbjorklund 2y ago
  None. Kind of like the difference of using a REST api or inventing your own api format. Both will work. One is standard.
  - esafak 2y ago
    Where are the community-created server APIs for your format? Why would you re-invent the wheel and rewrite them all yourself?
- aurumque 2y ago
  1. it makes tool discovery and use happen elsewhere so programs become more portable 2. it standardizes the method so every LLM doesn't need to do it differently 3. it creates a space for further shared development beyond tool use and discovery 4. it begins to open up hosted tool usage across LLMs for publicly hosted tools 5. for better or worse, it continues to drive the opinion that 'everything is a tool' so that even more functionality like memory and web searching can be developed across different LLMs 6. it offers a standard way to set up persistent connections to things like databases instead of handling them ad-hoc inside of each LLM or library If you are looking for anything more, you won't find it. This just standardizes the existing tool use / function calling concept while adding minimal overhead. People shouldn't be booing this so much, but nor should they be dramatically cheering it.
  - philomath_mn 2y ago
    Great breakdown, appreciate it. I think most of the hype around MCP is just excitement that tool use can actually work and seeing lots of little examples where it does. Watching Claude build something in Blender was pure magic, even if it is rough around the edges.
ondrsh 2y ago
This 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?
nomilk 2y ago
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).
- consumer451 2y ago
  I only use one regularly, but I use it a lot. (Supabase) Example use case: https://news.ycombinator.com/item?id=43466434 https://news.ycombinator.com/item?id=43466434
  - nomilk 2y ago
    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!
    - consumer451 2y ago
      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.
    - Xelynega 2y ago
      Is this not just hiding the "complexity" of SQL behind an LLM and hoping for the best? If you know SQL and know what you're trying to find, what can the LLM do quickly that you couldn't just constructing a query to get what you want? Alternatively if you don't know SQL, aren't you never going to learn it if every opportunity you have you bust out an LLM and hope for the best?
      - deleted 2y ago
        [deleted]
    - georgeashworth 2y ago
      Yes, I have used that workflow to fix a tricky data corruption issue earlier this week. A buggy feature left DB in invalid state, I described the issue to Claude + Postgres MCP to both query the DB to analyze and then generate SQL scripts to fix, and validation and rollback scripts. Easy enough to do without the tooling... but with the tooling, it took probably a quarter or less of the time.
rgomez 2y ago
Shamelessly promoting in here, I created an architecture that allows an AI agent to have those so called "tools" available locally (under the user control), and works with any kind of LLMs, and with any kind of LLM server (in theory). I've been showing demos about it for months now. Works as a middle-ware, in stream, between the LLM server and the chat client, and works very well. The project is open source, even the repo is outdated, but simply because no one is expressing interest in looking into the code. But here is the repo: https://github.com/khromalabs/Ainara https://github.com/khromalabs/Ainara. There's a link to a video in there. Yesterday just recorded a video showcasing DeepSeek V3 as the LLM backend (but could be any from OpenAI as well, or Anthropic, whatever).
- nomel 2y ago
  The lack of interest may be from the crypto aspect: > While the project will always remain open-source and aims to be a universal AI assistant tool, the officially developed 'skills' and 'recipes' (allowing AI to interact with the external world through Ainara's Orakle server) will primarily focus on cryptocurrency integrations. The project's official token will serve as the payment method for all related services.
  - rgomez 2y ago
    Thank you for the feedback... actually I need to update that, the crypto part of my project will be closed source (an specific remote server) but the idea behind the project itself is universal and open since the very beginning, I already developed dozens of skills including a meta-search engine (searches in several engines at once and combines results dynamically, all balanced by the AI) which are open source as well. Crypto just kind of showed itself as way of funding project, with no strings attached, and till this very day no one else showed up.
keyle 2y ago
I'm new to "MCP"... It says here that even IDE plug into this MCP server [1], as in you don't edit files directly anymore but go through a client/server? It wasn't bad enough that we now run servers locally to constantly compile code and tell us via json we made a typo... Soon we won't even be editing files on a disk, but accessing them through a json-rpc client/server? Am I getting this wrong? [1] https://modelcontextprotocol.io/introduction https://modelcontextprotocol.io/introduction
- NicuCalcea 2y ago
  I think you are getting it wrong. Some IDEs like Cursor and VS Code extensions like Cline support MCP servers, meaning you can give them access to your databases, Jira tickets, Notion notes, Slack messages, etc.
avaer 2y ago
Does anyone have any prior art for an MCP server "message bus" with an agent framework like Mastra? E.g. suppose I want my agent to operate as Discord bot listening on channel via an MCP server subscribed to the messages. i.e. the MCP server itself is driving the loop, not the framework, with the agent doing the processing. I can see how this could be implemented using MCP resource pubsub, with the plugin and agent being aware of this protocol and how to pump the message bus loop, but I'd rather not reinvent it. Is there a standard way of doing this already? Is it considered user logic that's "out of scope" for the MCP specification? EDIT: added an example here https://github.com/avaer/mcp-message-bus https://github.com/avaer/mcp-message-bus
- tonyhb 2y ago
  https://inngest.com https://inngest.com and agentkit. disclaimer is I work on it. Does all of the event stuff and state stuff for you. Plus the orchestration.
  - punkpeye 2y ago
    Big fan of Inngest! Most of http://glama.ai/mcp http://glama.ai/mcp logic is built on top of Inngest.
deleted 2y ago
[deleted]
__mharrison__ 2y ago
Awesome. I'm preparing an AI course and it looks like the APIs are starting to converge finally...
johnjungles 2y ago
If you want to try out mcp (model context protocol) with little to no setup: I built https://skeet.build/mcp https://skeet.build/mcp where anyone can try out mcp for cursor and now OpenAI agents! We did this because of a painpoint I experienced as an engineer having to deal with crummy mcp setup, lack of support and complexity trying to stand up your own. Mostly for workflows like: * start a PR with a summary of what I just did * slack or comment to linear/Jira with a summary of what I pushed * pull this issue from sentry and fix it * Find a bug a create a linear issue to fix it * pull this linear issue and do a first pass * pull in this Notion doc with a PRD then create an API reference for it based on this code * Postgres or MySQL schemas for rapid model development Everyone seems to go for the hype but ease of use, practical pragmatic developer workflows, and high quality polished mcp servers are what we’re focused on Lmk what you think!
- polishdude20 2y ago
  This looks super cool and I can see myself using this! Although the name is a bit unfortunate.
- pfista 2y ago
  my favorite is implementing issues from linear
ogundipeore 2y ago
context: a future I'd want re:coding experience is receiving pull requests for the issues I have in my code repo ...based on code generated from an agent that understands it. ...I think cursor editor gets closer to this experience but for a single task
analyte123 2y ago
If you have a clean, well-documented API that can be understood in under 30 minutes by a decent software engineer, congrats: you are MCP ready. I wonder how many discussions there will be about "adding MCP support" to software without this prerequisite.
spiritplumber 2y ago
We need to also add Tron support, otherwise who's going to fight for the users?
eigenvalue 2y ago
This is great, I was debating whether I should do my latest project using the new OpenAI Responses API (optimized for agent workflows) or using MCP, but now it seems even more obvious that MCP is the way to go. I was able to make a pretty complex MCP server in 2 days for LLM task delegation: https://github.com/Dicklesworthstone/llm_gateway_mcp_server https://github.com/Dicklesworthstone/llm_gateway_mcp_server
deleted 2y ago
[deleted]
Tewboo 2y ago
Impressive move by OpenAI. MCP support in Agents SDK will greatly enhance AI agent capabilities. Can't wait to see how developers leverage it.
deleted 2y ago
[deleted]
goaaron 2y ago
Call it a protocol and suddenly it sounds like a foundational technology. Nah, it's just a fancy JSON schema that lets LLMs play hot potato with metadata.
samchon 2y ago
Can't I do function calling in OpenAPI? I also feel like MCP is reinventing the wheel. I have been converting OpenAPI documents into function calling schemas and doing tool calling since function calling first came out in 2023, but it's not easy to recreate a backend server to fit MCP. Also, these days, I'm making a compiler-driven function calling specialized framework, but I'm a little cautious about whether MCP will support it. It enables zero-cost tool calling for TypeScript classes based on the compiler, and it also supports OpenAPI. However, in the case of MCP, in order to fit this to the compiler-driven philosophy, I need to create a backend framework for MCP development first, or create an add-on library for a famous framework like NestJS. I can do the development, but there's so much more to do compared to OpenAPI tool calling, so it's a bit like that.
- F7F7F7 2y ago
  You’re way over thinking the use cases for MCPs. That tells me you should stick to functions.
  - mkagenius 2y ago
    > That tells me you should stick to functions. probably we all should ¯\_(ツ)_/¯
- prometheon1 2y ago
  How should an MCP server like git work in your opinion? Should it then be written as a FastAPI server so that you have an openapi spec instead of just a CLI? https://github.com/modelcontextprotocol/servers/blob/main/src/git/src/mcp_server_git/server.py https://github.com/modelcontextprotocol/servers/blob/main/sr...
- dan-kwiat 2y ago
  [dead]
singularity2001 2y ago
hopefully they integrate it with their customGPT approach! I think they already work fantastically especially since the addition of the @ sign and automatic completion to easily include them in normal conversations. the only thing that was missing was access to the local machine.
nurettin 2y ago
Kinda naive question. All you need is a way to convince the LLM to output json according to your schema, then call the function. So what is the use of MCP servers? Why complicate things by adding another layer?
dhanushreddy29 2y ago
is this the new langchain?
paradite 2y ago
MCP is basically commoditizing SaaS and software by abstracting them away behind the AI agent interface. It benefits MCP clients (ChatGPT, Claude, Cursor, Goose) more than the MCP servers and the service behind the MCP servers (GitHub, Figma, Slack).
ursaguild 2y ago
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.
polishdude20 2y ago
Ideally in the future we won't need an MCP server when the AI can just write Unix terminal code to do anything it needs to get the job done? It seems using an MCP server and having the AI know about its "tools" is more of training wheels approach.
customllm 2y ago
JSON-RPC over HTTP just to make a tool call? At some point, MCP starts to feel like a wrapper around a wrapper.
hodanouri 2y ago
[dead]

807 points by gronky_ 2y ago

They’re all in. They announced they’ll add support for it in the desktop app and the API in the coming months: https://x.com/OpenAIDevs/status/1904957755829481737 https://x.com/OpenAIDevs/status/1904957755829481737

emmanueloga_ 2y ago
I'm surprised this was announced in a random tweet instead of a blog post with a release roadmap or something like that.
- swyx 2y ago
  because its a lil embarrassing oai didnt come up with it

esafak 2y ago

That makes it table stakes for any agent framework.

tcdent 2y ago

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.

fsndz 2y ago
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 https://www.lycee.ai/blog/why-mcp-is-mostly-bullshit
- esafak 2y ago
  I could not find the actual criticism in that article. What's the problem with MCP again? It's the first standard for agents.
  - fsndz 2y ago
    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.
    - esafak 2y ago
      That is not mentioned in the article. I am just becoming familiar with MCP myself so I suggest raising the issue: https://github.com/orgs/modelcontextprotocol/discussions https://github.com/orgs/modelcontextprotocol/discussions
    - paulgb 2y ago
      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.
    - mindwok 2y ago
      This is just moving the goalposts, MCP is not supposed to solve every problem with agents. It's meant to make it easier to provide easier, standardised ways for LLMs to interact with external tools, which it has done. Reliability is a completely different problem.
  - mkagenius 2y ago
    http endpoint + function calling can do what MCP do, this extra bad named layer is just jargon festish
    - knowaveragejoe 2y ago
      Okay, but we should have a standard around that, right? Something like... a protocol?
otabdeveloper4 2y ago
> MCP is now the industry standard for connecting LLMs to external tools. No it isn't. We're still five or ten years away from real standards. (Anyways it's clear that the future is smaller self-hosted LLMs, so whatever standard eventually emerges will be based on that paradigm.)
- greyman 2y ago
  1) It isn't a standard yet, but what else apart from filesystem-mcp can be used for prompts like "write me README.md for this repo" (like really produce the file) 2) For me it is not clear the future is smaller self-hosted LLMs. As of today, most useful for me is to use best models, and those are not self-hosted.
  - otabdeveloper4 2y ago
    Once we get used to the fact that LLMs exist they won't be sold on the gee-whiz "wow, a talking assistant just like in my sci-fi movies!" factor. They'll be used for particular language classification and search tasks, and for that you'd want several lighter, faster, cheaper and more specialized models. Not one with an arbitrary "best" score that's based on tricking the Turing test.
- liamwire 2y ago
  Sure, like how we all self-host our own email servers and photo albums? Honestly, I think you’re about as wrong as you could possibly be, both on timelines, and in that I’d argue the arc of consumer tech adoption bends towards centralisation most often. Standards are already emerging, including MCP, and to say that simply because they’ll evolve and be replaced over time means they’re not ‘real’ now is ridiculous. Look at the early internet and web as examples. Local models, even accounting for reasonable progress and device performance improvements, will always, inherently, be behind the eight ball compared to SOTA models. While they may be sufficient for the low hanging fruit, I’d not bet against the frontier models being every bit as compelling relatively speaking. Using weasel words like ‘real’ and ‘x is the future’ is astoundingly arrogant, and anyone claiming with confidence that they’ve got any idea where we’re heading is almost assuredly wrong.

simonw 2y ago

"Think of MCP like a USB-C port for AI applications." Given the enormous amounts of pain I've heard are involved in actually implementing any form of USB, I think the MCP community may want to find a different analogy!

PufPufPuf 2y ago
Since I've worked with the official MCP SDK, I find this analogy quite accurate

jswny 2y ago

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?

peterldowns 2y ago
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 https://modelcontextprotocol.io/quickstart/client There are a variety of available clients documented here https://modelcontextprotocol.io/clients 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://github.com/evalstate/fast-agent https://github.com/evalstate/fast-agent EDIT: I may have misunderstood your question. If you're asking "how can I make an API call to OpenAI, and have OpenAI call an MCP server I'm running as part of generating its response to me", the answer is "you can't". You'll want a proxy API that you call which is actually an MCP client, responsible for coordinating between the MCP servers and the OpenAI API upstream agent.
- knowaveragejoe 2y ago
  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-servers-mcp/ https://blog.cloudflare.com/remote-model-context-protocol-se...
bibryam 2y ago
command mode is for local, and SSE for remote

larodi 2y ago

Claude is like years ahead of everyone else with tools and agentic caps.

MoonGhost 2y ago
Can't be. "It was launched by Anthropic back in November 2024," about MCP
- senko 2y ago
  That's a few decades in AI time.

jtrn 2y ago

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

dartos 2y ago
> 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.
- nsonha 2y ago
  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.
  - dartos 2y ago
    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-26/#base-protocol https://spec.modelcontextprotocol.io/specification/2025-03-2...
    - nsonha 2y ago
      Higher in what way? But HOW is it stateful? That "mandate" the only occurence of that string "state" in that document.

TIPSIO 2y ago

I know Cloudflare has been talking about remote MCP for a while, does anyone have a solid example of this in practice?

jauntywundrkind 2y ago

I assume they're (for now at least) targeting the old HTTP+SSE version of MCP, and not the new Streaming HTTP version? https://github.com/modelcontextprotocol/specification/pull/206 https://github.com/modelcontextprotocol/specification/pull/2... There's some other goodies too. OAuth 2.1 support, JSON-RPC Batching... https://github.com/modelcontextprotocol/specification/blob/main/docs/specification/2025-03-26/changelog.md#major-changes https://github.com/modelcontextprotocol/specification/blob/m...

bob1029 2y ago

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.

nlarew 2y ago
> 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?
- bob1029 2y ago
  > 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.
  - Spivak 2y ago
    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/main/schema/2025-03-26/schema.json https://github.com/modelcontextprotocol/specification/blob/m... and even then it's a bit much.

talles 2y ago

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

olddustytrail 2y ago
You spend time with some weirdly technical moms.
votick 2y ago
I thought this was a "your mom is compatible with everyone" joke
- nova22033 2y ago
  [flagged]
  - stavros 2y ago
    I don't know whether to laugh at the joke or be triggered that USB takes three turns to insert.
jchw 2y ago
Maybe they used an LLM to explain it. Gemini in particular is obsessed with these utterly useless analogies for everything, when I would prefer something closer to Wikipedia with more context. (Needless to say, I currently don't find LLMs useful for learning about things. That's a shame because that use case feels promising.)
- colechristensen 2y ago
  LLMs are like an unlimited, poorly written encyclopedia. Often inaccurate or not entirely helpful, but will get you enough of an idea to find better sources. Sort of solving the "I don't know what I don't know" gap.
  - 2y ago

ginko 2y ago

Master Control Program?

jtimdwyer 2y ago
Who does he calculate he is?!?
neilv 2y ago
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 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 https://www.youtube.com/watch?v=lAcYUt2QbAo

unit149 2y ago

[dead]

shrisukhani 2y ago

MCP is now the standard everyone must conform to. Couldn't possibly have predicted that 2 months ago.

todsacerdoti 2y ago
Amazing how fast things are happening atm
nilslice 2y ago
We launched mcp.run in December ‘24 with that prediction (err, gamble ;) )
otabdeveloper4 2y ago
Wait two more months and there will be a different the standard.

keithwhor 2y ago

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": { "location": "New York" } } } Which traditionally would just be HTTP POST to `/get_weather` with `{ "location": "New York" }`. I've made the suggestion to remove some of this complexity [1] and fall back to just a traditional HTTP server, where a session can be negotiated with an `Authorization` header and we rely on traditional endpoints / OpenAPI + JSON Schema endpoint definitions. I think it would make server construction a lot easier and web frameworks would not have to materially be updated to adhere to the spec -- perhaps just adding a single endpoint. [0] https://spec.modelcontextprotocol.io/specification/2025-03-26/basic/transports/ https://spec.modelcontextprotocol.io/specification/2025-03-2... [1] https://github.com/modelcontextprotocol/specification/issues/236 https://github.com/modelcontextprotocol/specification/issues...

_pdp_ 2y ago
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.
- keithwhor 2y ago
  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.

cruffle_duffle 2y ago

Was wondering if this would ever happen. I wrote an MCP server that hooked up Azure Monitor (or whatever the hell microsoft is calling it) via Microsoft's python SDK so I could get it to query our logs without using command line tools. Took about half a day, mostly due to writing against the wrong Microsoft SDK. It will be nice to let ChatGPT have a crack a this too!

chaosprint 2y ago

claude 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, free grok 3 and perplexity work fine. funny enough, claude 3.7 being down these two days didn’t affect me at all. i checked mcp since i contribute to open source, but decided to wait. few reasons: - setup’s kind of a mess. it’s like running a local python or node bridge, forwarding stuff via sse or stdio. feels more like bridging than protocol innovation - I think eventually we need all the app to be somehow built-in AI-first protocol. I think only Apple (maybe Google) have that kind of influence. Think about the lightening vs usb-c. - performance might be a bottleneck later, especially for multimodal. - same logic as no.2 but the question is that do you really want every app to be AI-first? main issue for me: tools that really improve productivity are rare. a lot of mcp use cases sound cool, but i'll never give full github access to a black box. same for other stuff. so yeah—interesting idea, but hard ceiling.

striking 2y ago
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).
- chaosprint 2y ago
  First, I don't want to pay Claude Code at all... Second, isn't that doable with API calling :)

Tteriffic 2y ago

So we’re back to programming?

zoogeny 2y ago

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

amerine 2y ago
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.
- zoogeny 2y ago
  Right, that is why I said it makes sense for existing products. I mentioned desktop apps, but it would apply to any existing project. Like JIRA, or HubSpot, Wordpress, or Figma, etc. But there is hype around MCP as if independent devs could do something with it. And some will just for fun, some will for open source cred. But it is my experience that longevity is usually the result of stable revenue. I guess what I predict happening here is a few people will build some useful MCPs, realize there is no way to monetize despite generating a lot of interest and the most useful/popular MCPs will be integrated directly into the offerings of the foundational AI companies. And in a few years we won't even remember the acronym unless you happen to work for some big corp that wants to integrate your existing service into LLMs.
  - imtringued 2y ago
    The revenue plan for hosted services is that every user with an MCP client will count as a billable user.
victorbjorklund 2y ago

izwasm 2y ago

MCP 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 ?

victorbjorklund 2y ago
None. Kind of like the difference of using a REST api or inventing your own api format. Both will work. One is standard.
- esafak 2y ago
  Where are the community-created server APIs for your format? Why would you re-invent the wheel and rewrite them all yourself?
aurumque 2y ago
1. it makes tool discovery and use happen elsewhere so programs become more portable 2. it standardizes the method so every LLM doesn't need to do it differently 3. it creates a space for further shared development beyond tool use and discovery 4. it begins to open up hosted tool usage across LLMs for publicly hosted tools 5. for better or worse, it continues to drive the opinion that 'everything is a tool' so that even more functionality like memory and web searching can be developed across different LLMs 6. it offers a standard way to set up persistent connections to things like databases instead of handling them ad-hoc inside of each LLM or library If you are looking for anything more, you won't find it. This just standardizes the existing tool use / function calling concept while adding minimal overhead. People shouldn't be booing this so much, but nor should they be dramatically cheering it.
- philomath_mn 2y ago
  Great breakdown, appreciate it. I think most of the hype around MCP is just excitement that tool use can actually work and seeing lots of little examples where it does. Watching Claude build something in Blender was pure magic, even if it is rough around the edges.

ondrsh 2y ago

This 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?

nomilk 2y ago

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

consumer451 2y ago
I only use one regularly, but I use it a lot. (Supabase) Example use case: https://news.ycombinator.com/item?id=43466434 https://news.ycombinator.com/item?id=43466434
- nomilk 2y ago
  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!
  - consumer451 2y ago
    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.
  - Xelynega 2y ago
    Is this not just hiding the "complexity" of SQL behind an LLM and hoping for the best? If you know SQL and know what you're trying to find, what can the LLM do quickly that you couldn't just constructing a query to get what you want? Alternatively if you don't know SQL, aren't you never going to learn it if every opportunity you have you bust out an LLM and hope for the best?
    - deleted 2y ago
      [deleted]
  - georgeashworth 2y ago
    Yes, I have used that workflow to fix a tricky data corruption issue earlier this week. A buggy feature left DB in invalid state, I described the issue to Claude + Postgres MCP to both query the DB to analyze and then generate SQL scripts to fix, and validation and rollback scripts. Easy enough to do without the tooling... but with the tooling, it took probably a quarter or less of the time.

rgomez 2y ago

Shamelessly promoting in here, I created an architecture that allows an AI agent to have those so called "tools" available locally (under the user control), and works with any kind of LLMs, and with any kind of LLM server (in theory). I've been showing demos about it for months now. Works as a middle-ware, in stream, between the LLM server and the chat client, and works very well. The project is open source, even the repo is outdated, but simply because no one is expressing interest in looking into the code. But here is the repo: https://github.com/khromalabs/Ainara https://github.com/khromalabs/Ainara. There's a link to a video in there. Yesterday just recorded a video showcasing DeepSeek V3 as the LLM backend (but could be any from OpenAI as well, or Anthropic, whatever).

nomel 2y ago
The lack of interest may be from the crypto aspect: > While the project will always remain open-source and aims to be a universal AI assistant tool, the officially developed 'skills' and 'recipes' (allowing AI to interact with the external world through Ainara's Orakle server) will primarily focus on cryptocurrency integrations. The project's official token will serve as the payment method for all related services.
- rgomez 2y ago
  Thank you for the feedback... actually I need to update that, the crypto part of my project will be closed source (an specific remote server) but the idea behind the project itself is universal and open since the very beginning, I already developed dozens of skills including a meta-search engine (searches in several engines at once and combines results dynamically, all balanced by the AI) which are open source as well. Crypto just kind of showed itself as way of funding project, with no strings attached, and till this very day no one else showed up.

keyle 2y ago

I'm new to "MCP"... It says here that even IDE plug into this MCP server [1], as in you don't edit files directly anymore but go through a client/server? It wasn't bad enough that we now run servers locally to constantly compile code and tell us via json we made a typo... Soon we won't even be editing files on a disk, but accessing them through a json-rpc client/server? Am I getting this wrong? [1] https://modelcontextprotocol.io/introduction https://modelcontextprotocol.io/introduction

NicuCalcea 2y ago
I think you are getting it wrong. Some IDEs like Cursor and VS Code extensions like Cline support MCP servers, meaning you can give them access to your databases, Jira tickets, Notion notes, Slack messages, etc.

avaer 2y ago

Does anyone have any prior art for an MCP server "message bus" with an agent framework like Mastra? E.g. suppose I want my agent to operate as Discord bot listening on channel via an MCP server subscribed to the messages. i.e. the MCP server itself is driving the loop, not the framework, with the agent doing the processing. I can see how this could be implemented using MCP resource pubsub, with the plugin and agent being aware of this protocol and how to pump the message bus loop, but I'd rather not reinvent it. Is there a standard way of doing this already? Is it considered user logic that's "out of scope" for the MCP specification? EDIT: added an example here https://github.com/avaer/mcp-message-bus https://github.com/avaer/mcp-message-bus

tonyhb 2y ago
https://inngest.com https://inngest.com and agentkit. disclaimer is I work on it. Does all of the event stuff and state stuff for you. Plus the orchestration.
- punkpeye 2y ago
  Big fan of Inngest! Most of http://glama.ai/mcp http://glama.ai/mcp logic is built on top of Inngest.

deleted 2y ago

[deleted]

__mharrison__ 2y ago

Awesome. I'm preparing an AI course and it looks like the APIs are starting to converge finally...

johnjungles 2y ago

If you want to try out mcp (model context protocol) with little to no setup: I built https://skeet.build/mcp https://skeet.build/mcp where anyone can try out mcp for cursor and now OpenAI agents! We did this because of a painpoint I experienced as an engineer having to deal with crummy mcp setup, lack of support and complexity trying to stand up your own. Mostly for workflows like: * start a PR with a summary of what I just did * slack or comment to linear/Jira with a summary of what I pushed * pull this issue from sentry and fix it * Find a bug a create a linear issue to fix it * pull this linear issue and do a first pass * pull in this Notion doc with a PRD then create an API reference for it based on this code * Postgres or MySQL schemas for rapid model development Everyone seems to go for the hype but ease of use, practical pragmatic developer workflows, and high quality polished mcp servers are what we’re focused on Lmk what you think!

polishdude20 2y ago
This looks super cool and I can see myself using this! Although the name is a bit unfortunate.
pfista 2y ago
my favorite is implementing issues from linear

ogundipeore 2y ago

context: a future I'd want re:coding experience is receiving pull requests for the issues I have in my code repo ...based on code generated from an agent that understands it. ...I think cursor editor gets closer to this experience but for a single task

analyte123 2y ago

If you have a clean, well-documented API that can be understood in under 30 minutes by a decent software engineer, congrats: you are MCP ready. I wonder how many discussions there will be about "adding MCP support" to software without this prerequisite.

spiritplumber 2y ago

We need to also add Tron support, otherwise who's going to fight for the users?

eigenvalue 2y ago

This is great, I was debating whether I should do my latest project using the new OpenAI Responses API (optimized for agent workflows) or using MCP, but now it seems even more obvious that MCP is the way to go. I was able to make a pretty complex MCP server in 2 days for LLM task delegation: https://github.com/Dicklesworthstone/llm_gateway_mcp_server https://github.com/Dicklesworthstone/llm_gateway_mcp_server

deleted 2y ago

[deleted]

Tewboo 2y ago

Impressive move by OpenAI. MCP support in Agents SDK will greatly enhance AI agent capabilities. Can't wait to see how developers leverage it.

deleted 2y ago

[deleted]

goaaron 2y ago

Call it a protocol and suddenly it sounds like a foundational technology. Nah, it's just a fancy JSON schema that lets LLMs play hot potato with metadata.

samchon 2y ago

Can't I do function calling in OpenAPI? I also feel like MCP is reinventing the wheel. I have been converting OpenAPI documents into function calling schemas and doing tool calling since function calling first came out in 2023, but it's not easy to recreate a backend server to fit MCP. Also, these days, I'm making a compiler-driven function calling specialized framework, but I'm a little cautious about whether MCP will support it. It enables zero-cost tool calling for TypeScript classes based on the compiler, and it also supports OpenAPI. However, in the case of MCP, in order to fit this to the compiler-driven philosophy, I need to create a backend framework for MCP development first, or create an add-on library for a famous framework like NestJS. I can do the development, but there's so much more to do compared to OpenAPI tool calling, so it's a bit like that.

F7F7F7 2y ago
You’re way over thinking the use cases for MCPs. That tells me you should stick to functions.
- mkagenius 2y ago
  > That tells me you should stick to functions. probably we all should ¯\_(ツ)_/¯
prometheon1 2y ago
How should an MCP server like git work in your opinion? Should it then be written as a FastAPI server so that you have an openapi spec instead of just a CLI? https://github.com/modelcontextprotocol/servers/blob/main/src/git/src/mcp_server_git/server.py https://github.com/modelcontextprotocol/servers/blob/main/sr...
dan-kwiat 2y ago
[dead]

singularity2001 2y ago

hopefully they integrate it with their customGPT approach! I think they already work fantastically especially since the addition of the @ sign and automatic completion to easily include them in normal conversations. the only thing that was missing was access to the local machine.

nurettin 2y ago

Kinda naive question. All you need is a way to convince the LLM to output json according to your schema, then call the function. So what is the use of MCP servers? Why complicate things by adding another layer?

dhanushreddy29 2y ago

is this the new langchain?

paradite 2y ago

MCP is basically commoditizing SaaS and software by abstracting them away behind the AI agent interface. It benefits MCP clients (ChatGPT, Claude, Cursor, Goose) more than the MCP servers and the service behind the MCP servers (GitHub, Figma, Slack).

ursaguild 2y ago

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.

polishdude20 2y ago

Ideally in the future we won't need an MCP server when the AI can just write Unix terminal code to do anything it needs to get the job done? It seems using an MCP server and having the AI know about its "tools" is more of training wheels approach.

customllm 2y ago

JSON-RPC over HTTP just to make a tool call? At some point, MCP starts to feel like a wrapper around a wrapper.

hodanouri 2y ago

[dead]