[HN Gopher] OpenAI adds MCP support to Agents SDK
___________________________________________________________________
OpenAI adds MCP support to Agents SDK
Author : gronky_
Score : 328 points
Date : 2025-03-26 18:55 UTC (4 hours ago)
(HTM) web link (openai.github.io)
(TXT) w3m dump (openai.github.io)
| gronky_ wrote:
| 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
| emmanueloga_ wrote:
| I'm surprised this was announced in a random tweet instead of a
| blog post with a release roadmap or something like that.
| swyx wrote:
| because its a lil embarrassing oai didnt come up with it
| esafak wrote:
| That makes it table stakes for any agent framework.
| tcdent wrote:
| 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 wrote:
| 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
| esafak wrote:
| 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 wrote:
| 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 wrote:
| 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
| paulgb wrote:
| 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.
| paulgb wrote:
| 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. It's like the difference
| between static linking and dynamic linking, but for tool
| calls.
| rvz wrote:
| > That article seems to miss the point by being incurious
| about _why_ there is hype around MCP instead of LangChain,
| LangGrah, SmolAgents, LlamaIndex, etc.
|
| The VCs that were invested in AI companies (like Cursor)
| would of course need to hype something up like MCPs to get
| us to build them as little of those tools did not exist.
|
| Cursor already makes $100M+. So why not get behind and
| integrate this chosen standard to make even more money with
| more MCP servers.
|
| The last ingredient is to hype it all up on the internet to
| get everyone building.
|
| A win for the VCs regardless even though it was
| suspiciously orchestrated as soon as Cursor integrated it.
| vessenes wrote:
| I too feel it's bad that companies take VC money and
| build open standards which let me build faster and target
| more providers. Seriously, what? I struggle to understand
| the mindset of someone frequenting HN who can say
| unironically that "getting everyone building" is a bad
| outcome.
|
| I'd like some more of that getting everyone building
| please.
| leonidasv wrote:
| MCPs aren't specific to Cursor. Rather, they enable any
| IDE to become a Cursor competitor.
|
| Example: JetBrains released an MCP server plugin for
| their IDEs recently and it enables Claude Desktop to
| seamlessly use the IDE for reading and writing files and
| even compiling or running tests against it.
|
| And that's just one example; there are MCP servers for
| anything from VSCode to Emacs already. That means almost
| anyone can now use LLMs to generate code in their IDE of
| choice, just as they would do with Cursor.
|
| In fact, MCPs are posing a threat to many startups,
| especially the "wrapper" ones.
| tcdent wrote:
| 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.
| creddit wrote:
| I feel like that article doesn't really live up to its title.
| At the end, its basic point is that MCP isn't a magic bullet
| (I don't think anyone claimed it was?) and that it has a lot
| of hype. It also makes it clear why MCP is good (ie don't
| need to rely on LangChain). Feels like its title should be
| "Why MCP is a Good Step but Doesn't Solve Agents" or
| something. But then, it wouldn't enable the millenial urge to
| use "shit".
| rvz wrote:
| > But MCP also feels a bit overrated:
|
| VCs invested in AI and agentic companies needed a way to get
| you guys to accelerate agents this year.
|
| So why not "create" artificial hype for MCPs on the internet,
| since there were little to no MCP servers for LLMs to use
| despite it being several months old (November 2024) until
| Cursor integrated it.
|
| This is the true reason why you see them screaming about MCPs
| everywhere.
| fkyoureadthedoc wrote:
| So the main criticism is a borderline conspiracy theory
| about VC's creating artificial hype for it?
| AtomBalm wrote:
| 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.
| kschrader wrote:
| The Anthropic models are running underneath everything
| (Claude Code, Windsurf, Cursor, etc). Whenever someone is
| using MCP they (in the generalized case, until now)
| ultimately end up using Anthropic as their LLM and
| Anthropic gets paid whenever someone does that.
| varelaseb wrote:
| This is literally not true. You can leverage MCP using
| any model. Even some of the IDEs you mention let you
| leverage MCP using many model providers.
| simonw wrote:
| "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!
| jswny wrote:
| 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 wrote:
| 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://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.
| bibryam wrote:
| command mode is for local, and SSE for remote
| larodi wrote:
| Claude is like years ahead of everyone else with tools and
| agentic caps.
| MoonGhost wrote:
| Can't be. "It was launched by Anthropic back in November 2024,"
| about MCP
| senko wrote:
| That's a few decades in AI time.
| jtrn wrote:
| 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 wrote:
| > 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.
| taude wrote:
| There's already swagger MCP service out there, I don't know how
| production ready it is, but I saw something the other day when
| searching through GitHu. One of several implementations:
| https://github.com/dcolley/swagger-mcp
| PeterStuer wrote:
| Whatever the current state, if everyone throws their shoulders
| behind a common interface, we all win.
| bjtitus wrote:
| Emcee is a good implementation of this.
|
| https://github.com/loopwork-ai/emcee
| TIPSIO wrote:
| I know Cloudflare has been talking about remote MCP for a while,
| does anyone have a solid example of this in practice?
| jauntywundrkind wrote:
| 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/2...
|
| There's some other goodies too. OAuth 2.1 support, JSON-RPC
| Batching...
| https://github.com/modelcontextprotocol/specification/blob/m...
| bob1029 wrote:
| 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 wrote:
| > 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 wrote:
| > 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.
| vessenes wrote:
| If you're interested, I'd encourage you to implement an MCP
| integration and see if you change your mind.
|
| For instance, I have a little 'software team in a box' tool. v1
| integrated github and three different llms manually (react +
| python backend). This is fine. You can call github commands via
| CLI on the backend, and add functionality somewhat easily,
| depending on the LLM's knowledge.
|
| Pain points -- if you want workflow to depend on multiple
| outputs from these pieces, (e.g. see that there's a pull
| request, and assess it, or see that a pull request is signed
| off on / merged, and update something) -- you must code most of
| these workflows manually.
|
| v2, I wiped that out and have a simple git, github and
| architect MCP protocol written up. Now I can have claude as a
| sort of mastermind, and just tell it "here are all the things
| you can do, please XXX". It wipes out most of the custom
| workflow coding and lets me just tell Claude what I'd look to
| do -- on the backend, my non-LLM MCP server can deal with
| things _it 's_ good at, API calls, security checks, etc.
| digdugdirk wrote:
| Do you have the code available anywhere? I'm working on the
| same thing to learn how to utilize MCP, I'd love to see how
| someone else went about it.
| vessenes wrote:
| this will break, kill your computer and probably result in
| loss of life. Just saying. :)
|
| That said, here's a gist: https://gist.github.com/vessenes/
| ec43b76965eed1b36b3467c598b...
| senko wrote:
| That sounds like v1 was "tool calls llm", while v2 is "llm
| calls tool"?
|
| The fact that the tool call is via mcp and not in-process
| function call seems to be an implementation detail?
| talles wrote:
| > 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 wrote:
| You spend time with some weirdly technical moms.
| votick wrote:
| I thought this was a "your mom is compatible with everyone"
| joke
| nova22033 wrote:
| "You're mom is like USB-A, I have to turn her around 3 times
| before I can get it in the hole"
| jchw wrote:
| 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 wrote:
| 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.
| lelandfe wrote:
| I saw this ChatGPT-created analogy on a JS subreddit the
| other day:
|
| > _Imagine you have a robot in a room, and this robot can
| perform actions like turning on a light, opening a door, or
| picking up objects. Now, if you want to tell the robot to do
| something, you usually say something like, "Robot, pick up
| the pen!" or "Robot, open the door."_
|
| > _In JavaScript, 'this' is like the "robot" in the room_
|
| Terrible.
| zombiwoof wrote:
| Because everyone knows the usb-c protocol
| matthewmacleod wrote:
| Honestly I'm now even more confused
| dotancohen wrote:
| It's got an open socket at the bottom, that accepts many
| different plugs.
|
| I don't know if GP understands that his phrasing might not be
| so flattering for his mother ))
| monkeydust wrote:
| A good analogy I think for those in Trading might be FIX or
| FpML. Those protocols and standards have revolutionized
| electronic trading.
| gnfargbl wrote:
| It's trying to say "you can plug lots of things into this in a
| standardized way."
|
| https://norahsakal.com/blog/mcp-vs-api-model-context-protoco...
| atonse wrote:
| 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.
| skavi wrote:
| they probably mean it's going to be difficult early on to find
| standards compliant implementations. and then always very
| annoying to make sure all involved components support the
| correct feature set.
| dotancohen wrote:
| The full quote is better: > MCP is an open
| protocol that standardizes how applications provide context
| > to LLMs. Think of MCP like a USB-C port for AI applications.
| Just as USB-C > provides a standardized way to connect
| your devices to various peripherals > and accessories,
| MCP provides a standardized way to connect AI models to >
| different data sources and tools.
| beardedwizard wrote:
| That's the same analogy anthropic uses to describe it.
| elamje wrote:
| The closest software analogy I've heard is like passing around
| a callable/function with a standard interface. An LLM can call
| the callable and work with the returned data without needing to
| go back and forth between your application logic.
| tb1989 wrote:
| 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
| whazor wrote:
| MCP is very similar in protocol to LSP.
|
| In LSP, you have editor (vscode, neovim), and language servers
| (rust, typescript, python).
|
| In MCP, you have the client (chat window), and servers
| (providing context, tools, and prompts).
| riemannzeta wrote:
| The weather data example in their documentation makes it really
| simple to grasp how it works as an interface for models:
|
| https://modelcontextprotocol.io/quickstart/server
|
| I don't think it's terribly difficult to drill down into their
| GitHub to see what's happening under the hood if you need that
| level of detail.
| ondrsh wrote:
| 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 where MCP excels. Yes, you can add
| tools via MCP servers at design-time, but you can also include
| them manually through JSON schemas and code (giving you more
| control because you're not restricted by the abstractions that
| MCP imposes).
|
| MCP-native applications on the other hand can be shipped, and
| then _the users_ can add tools to the application -- at
| runtime. In other words, you don 't know at design-time which
| tools your users will add (similar to how browser developers
| don't know which websites users will visit at runtime). This
| concept -- combined with the fact that AI generalizes so well
| -- makes designing this kind of application extremely
| fascinating, because you're constantly thinking about how users
| might end up enhancing your application as it runs.
|
| As of today, the vast majority of developers aren't building
| applications of this kind, which is why there's confusion.
| amerine wrote:
| 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.
| freeone3000 wrote:
| Oh, it's the new HATEOAS? A pluggable framework for automatic
| discoverability of HTTP APIs is incredibly useful, and not
| just for AI :)
| kblissett wrote:
| Isn't this just the same paradigm as plugins?
| TechDebtDevin wrote:
| Well its directly from the documentation written by the SWEs
| that built the protocol...
|
| https://modelcontextprotocol.io/introduction
| madeofpalk wrote:
| I want to know in which way is USB- _C_ applicable here. The
| complicated plug that 's actually 30 different protocol's
| that's difficult understand what capabiltiies a plug/cable
| actually has?
| ginko wrote:
| Master Control Program?
| jtimdwyer wrote:
| Who does he calculate he is?!?
| shrisukhani wrote:
| MCP is now _the_ standard everyone must conform to. Couldn 't
| possibly have predicted that 2 months ago.
| todsacerdoti wrote:
| Amazing how fast things are happening atm
| keithwhor wrote:
| 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-2...
|
| [1]
| https://github.com/modelcontextprotocol/specification/issues...
| _pdp_ wrote:
| 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 wrote:
| 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.
| _pdp_ wrote:
| I agree. What OpenAI did was simple and beautiful.
|
| Also, I think there is a fundamental misunderstanding that
| MCP services are plug and play. They are not. Function
| names and descriptions are literally prompts so it is
| almost certain you would need to modify the names or
| descriptions to add some nuances to how you want these to
| be called. Since MCP servers are not really meant to be
| extensible in that sort of way, the only other alternative
| is to add more context into the prompt which is not easy
| unless you have a tone of experience. Most of our customers
| fail at prompting.
|
| The reason I like the ai-plugin.json approach is that you
| don't have to change the API to make the description of a
| function a little bit different. One day MCP might support
| this but it will another layer of complexities that could
| have been avoided with a remotely hosted JSON / YAML file.
| keithwhor wrote:
| The good thing to note is that (AFAIK) MCP is intended to
| be a collaborative and industry-wide effort. Whereas
| plugins was OpenAI-specific.
|
| So, hopefully, we can contribute and help direct the
| development! I think this dialogue is helpful and I'm
| hoping the creators respond via GitHub or otherwise.
| pcarolan wrote:
| Yeah, I had more luck with just giving an ai the openapi spec
| and letting it figure everything out. I like a lot about MCP
| (structure, tool guidance, etc), but couldn't it just have
| been a REST API and a webserver?
| cruffle_duffle wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| First, I don't want to pay Claude Code at all...
|
| Second, isn't that doable with API calling :)
| Tteriffic wrote:
| So we're back to programming?
| zoogeny wrote:
| 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 wrote:
| 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 wrote:
| 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.
| victorbjorklund wrote:
| What is the revenue plan for 99% of open source library
| authors?
| zoogeny wrote:
| Is what you are insinuating that the only licensing model for
| independent MCP authors is open source? Are you assuming that
| MCPs are only viable as free (as in beer) projects?
|
| I feel like software license and business revenue models are
| only very loosely correlated. I guess if you are assuming
| there is no money at all to be made in MCP then my question
| wouldn't make sense.
| achierius wrote:
| The currently-dominant open source paradigm (i.e. motivated
| and well-meaning developers work themselves to the bone under
| pressure from tech giants who will never pay them) is clearly
| not sustainable. Moreover, many are probably not happy with
| their code being used (without permission) to train machines
| whose putative intent is to replace those self-same
| developers. Now the question is, how many will want to do
| something similar, again?
| izwasm wrote:
| 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 wrote:
| None. Kind of like the difference of using a REST api or
| inventing your own api format. Both will work. One is standard.
| aurumque wrote:
| 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.
| ondrsh wrote:
| 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 wrote:
| 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).
| rgomez wrote:
| 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. There's a link to a video
| in there. Yesterday just recorded a video showcasing DeepSeek V3
| as the LLM backend.
| keyle wrote:
| 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
___________________________________________________________________
(page generated 2025-03-26 23:00 UTC)