[HN Gopher] OpenAI adds MCP support to Agents SDK
___________________________________________________________________
OpenAI adds MCP support to Agents SDK
Author : gronky_
Score : 768 points
Date : 2025-03-26 18:55 UTC (1 days 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.
| mindwok wrote:
| 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 wrote:
| http endpoint + function calling can do what MCP do, this
| extra bad named layer is just jargon festish
| knowaveragejoe wrote:
| Okay, but we should have a standard around that, right?
| Something like... a protocol?
| 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.
| knowaveragejoe wrote:
| There's already like a half dozen such "marketplaces" and
| they all ultimately point to open source repos. If the
| goal was to lock people in, they did a bad job of it.
| taude wrote:
| there's a reason there's MCP plugins for LangChain. Some
| companies will need massively customized workflows that
| LangChain is appropriate for, where it only needs to dig into
| a couple potentially publically accessed MCPS for things.
|
| I could see a future where companies have their developer
| portal where now they have their APIs document, the pretty in
| swagger, the samples, etc, but they'll have a MCP endpoint
| (potentially), where they're safely exposing the data to an
| LLM. Your langchain node step to to get context, could call
| out to some of these hosted/shared mcps where you do standard
| stuff, like post to a Slack channel, grab some data from a
| SFDC instance, etc....
| otabdeveloper4 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 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!
| PufPufPuf wrote:
| Since I've worked with the official MCP SDK, I find this
| analogy quite accurate
| 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.
| knowaveragejoe wrote:
| You can run remote MCP servers and configure whatever client
| to use them. This should work even via OpenAI's API(perhaps
| not yet, but it's just another 'tool' to call)
|
| https://blog.cloudflare.com/remote-model-context-protocol-
| se...
| 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.
| nsonha wrote:
| 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 wrote:
| 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-2...
| nsonha wrote:
| Higher in what way?
|
| But HOW is it stateful? That "mandate" the only occurence
| of that string "state" in that document.
| slt2021 wrote:
| transport argument is irrelevat when http can be both TCP and
| UDP, and even if you wanna do one protocol, it can be
| proxied/tunneled via another protocol transparently via
| VPN/wireguard/proxy.
|
| so transport protocol is moot, especially from latency
| perspective when most time is spent doing AI inference
| (seconds) rather than passing packets (milliseconds).
|
| I really wish OpenAI just embraced OpenAPI and that would
| have instantly gained millions of existing sites available to
| ChatGPT with zero code change.
| sethaurus wrote:
| It's transport-agnostic in the sense that it works locally
| (over stdout), not just remotely. It's not just for web-
| services. That's why HTTP isn't baked into this.
| Xelynega wrote:
| HTTP also works locally(over local files including
| stdin/stdout), not just remotely.
| 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
| OrangeMusic wrote:
| GraphQL looks like an even better choice - it really looks like
| they re-invented the wheel here.
| 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?
| vessenes wrote:
| first sentence sounds right to me.
|
| "Implementation detail" is doing a lot of work in the
| second sentence, though. There are whole startups like
| langchain that were trying to build out a reasonable agent
| framework integrated in such a way that the LLMs can drive.
| MCP makes that really easy -- LLM training just has to
| happen once, against MCP spec, and I get client and LLM
| support for an iterative tool use scenario right in the
| LLM.
| polishdude20 wrote:
| So is the MCP server acting like a middleman between the llm
| and the application you want to control?
|
| Like, could I give the MCP server the ability to say exec
| Unix code on my machine and then tell the LLM "here's the MCP
| server, this function can execute Unix code and get back the
| response".
|
| Then I can tell the LLM, "create an application using the MCP
| server that will listen to a GitHub webhook and git pull when
| the webhook hits and have it running" then the LLM would
| generate the commands necessary to do that and run them
| through the MCP server which just executed the Unix code. And
| viola?
|
| I've gotten an llm to create files and run system commands
| for me.
|
| Is that the most barebones application?
| analyte123 wrote:
| You could say the same thing about almost any protocol, e.g.
| HTTP, which runs on arbitrary streams of bytes over TCP; and
| the headers, methods and status codes are just illusions on top
| of that.
| ripped_britches wrote:
| Literally every protocol ever written is "clever heuristics
| over plain-ass {bits|bytes|text|etc}"
| oefnak wrote:
| Well, you should check again, because it hasn't been text to
| text for a while. There are multimodal models now.
| bob1029 wrote:
| If we want to get pedantic, in context of practical
| transformer models it has _never_ been text to text. It has
| always been tokens to tokens. The tokens can represent
| anything. "multimodal" is a marketing term.
| orangebread wrote:
| I would think of MCP as a "plugin" for AI.
|
| Right now your typical interaction in chat is limited with some
| exceptions of out of box tooling that most current platforms
| provide: file attachment, web search, etc.
|
| MCP is a way to extend this toolbox, but the cooler thing is AI
| will be able to determine _at inference time_ what tools to use
| to fulfill the user's prompt.
|
| Hope this helped!
| 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
| 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.
| soulofmischief wrote:
| In this regard, they have been extraordinarily fruitful for
| my research and studies.
| 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
| rounce wrote:
| Do they? Like actually, know it cover-to-cover, or do they
| just know _of_ it? Because the first thing to point out is
| that USB-C isn 't a protocol, it's a connector standard.
| 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.
| soulofmischief wrote:
| This is what we used to just call "standards", but apparently
| we need analogies now in order to explain standards to new
| developers.
| talles wrote:
| Not only that, the P for "protocol" already gives that.
| 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.
| otabdeveloper4 wrote:
| No, it's actually a lot worse. "USB-C port for AI
| applications" sounds like something written by an insane
| person.
| 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
| knowaveragejoe wrote:
| > MCP, despite its open-source claim, heavily relies on
| proprietary interfaces from Anthropic's Claude model. Thus,
| the proclaimed openness is surface-level at best, creating
| subtle but significant barriers within the ecosystem.
|
| This strikes me as fundamentally untrue, but I'd love to see
| an example of this in the source code or documentation.
| 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, at design-time you don 't know 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 :)
| TeMPOraL wrote:
| No, you can't understand it until you understand that _the
| world isn 't all webshit and not everything is best used
| via REST_.
|
| (Not even webshit is best used by REST, as evidenced by
| approximately _every_ "REST" API out there, designed as RPC
| over HTTP pretending it's not.)
| freeone3000 wrote:
| Nevertheless, MCP _is_ a "webshit" protocol (even in
| stdio mode), so if web protocols are unsuitable for your
| problem, MCP would be as well.
| ondrsh wrote:
| Unfortunately, MCP is not HATEOAS. It doesn't need to be,
| because it's not web-like. I wish it were.
|
| HATEOAS is great for web-like structures because in each
| response it not only includes the content, but also all
| actions the client can take (usually via links). This is
| critical for architectures without built-in structure --
| unlike Gopher which has menus and FTP and Telnet which have
| stateful connections -- because otherwise a client arriving
| at some random place has no indication on what to do next.
| MCP tackles this by providing a stateful connection
| (similar to FTP) and is now moving toward static entry
| points similar to Gopher menus.
|
| I specifically wrote about why pure HATEOAS should come
| back instead of MCP: https://www.ondr.sh/blog/ai-web
| kblissett wrote:
| Isn't this just the same paradigm as plugins?
| ondrsh wrote:
| Similar, but one level higher.
|
| Plugins have pre-defined APIs. You code your application
| against the plugin API and plugin developers do the same.
| Functionality is being consumed directly through this API
| -- this is level 1.
|
| MCP is a meta-protocol. Think of it as an API that lets
| arbitrary plugins announce their APIs to the application at
| runtime. MCP thus lives one level above the plugin's API
| level. MCP is just used to exchange information about the
| level 1 API so that the LLM can then call the plugin's
| level 1 API at runtime.
|
| This only works because LLMs can understand and interpret
| arbitrary APIs. Traditionally, developers needed to
| understand an API at design-time, but now LLMs can
| understand an API at runtime. And _because_ this can now
| happen at runtime, users (instead of developers) can add
| arbitrary functionality to applications.
|
| I hate plugging my own blog again but I wrote about that
| exact thing before, maybe it helps you:
| https://www.ondr.sh/blog/thoughts-on-mcp
| anonymousDan wrote:
| This sounds like a security nightmare.
| soulofmischief wrote:
| As it currently stands, MCP is absolutely a security
| nightmare. Combine this with a general lack of
| appreciation for security culture amongst developers, and
| the emerging vibe coding paradigm where non-security-
| minded people automatically generate and fail to properly
| audit production-facing code, and it's a disaster waiting
| to happen.
|
| Feels like we've slid back into the 90s in this regard.
| Great time to be a security researcher!
| vykthur wrote:
| I tend to agree with this.
|
| No, MCP's have NOT Won (Yet)
| https://newsletter.victordibia.com/p/no-mcps-have-not-
| won-ye...
| jcheng wrote:
| It's pretty astounding to me that this aspect of MCP is
| not mentioned more. You're putting a LOT of trust in both
| the model and the system prompt when you start attaching
| MCPs that provide unfettered access to your file system,
| or connect up to your REST API's POST endpoints.
|
| (That being said, I have to admit I've been writing my
| own powerful but extremely dangerous tools as an
| experiment (e.g. run arbitrary Python code on my machine,
| unsandboxed) and I have to admit the results have been
| incredibly compelling.)
| lurking_swe wrote:
| agreed. this sounds useless at the moment unless you're
| sand boxing it in a throw-away VM lol. Scary!
| TeMPOraL wrote:
| > _Feels like we 've slid back into the 90s in this
| regard._
|
| Thank $deity. 90s and early 2000s were the times software
| was designed to _do useful work and empower users_ , as
| opposed to lock them into services and collect telemetry,
| both of which protected by the best of advancement in
| security :).
|
| I'm only half-joking here. Security is always working
| _against_ usefulness; MCP is designed to be useful first
| (like honest to $deity useful, not "exploit your
| customers" useful), so it looks like security nightmare.
| Some of that utility will need to go away, because
| complete lack of security is _also_ bad for the users -
| but there 's a tradeoff to be made, hopefully one that
| doesn't just go by modern security zeitgeist, because
| that is already deep into protecting profits by _securing
| services against users_.
|
| > _a general lack of appreciation for security culture
| amongst developers, and the emerging vibe coding paradigm
| where non-security-minded people automatically generate
| and fail to properly audit production-facing code_
|
| There is also a general lack of consideration of _who is
| being protected from whom, and why_ in the security
| culture. MCP, vibe coding, and LLMs in general are
| briefly giving end-users back some agency, bringing back
| the whole idea of "bicycle for the mind" that was
| completely and intentionally destroyed when computing
| went mainstream. Let's not kill it so eagerly this time.
| soulofmischief wrote:
| A non-exhaustive list of concerns:
|
| - How does a consumer of a remote MCP server trust that
| it is not saving/modifying their data, or that it is
| doing something other than what it said it would?
|
| - How does a consumer of a local MCP server trust that it
| won't wreck their machine or delete data?
|
| - How do servers authorize and authenticate end users?
| How do we create servers which give different permissions
| to different users?
|
| These are examples of things which _must be done right_ ,
| and sacrificing user security in order to achieve market
| dominance is ethically bankrupt. Pedestrians don't _know_
| exactly which regulations serve them when a bridge is
| built, so we don 't expect pedestrians to be able to stop
| corruption and laziness in civil engineering. The same
| should be true for mass infrastructure; we have a duty as
| engineers to make the right call.
|
| > MCP, vibe coding, and LLMs in general are briefly
| giving end-users back some agency, bringing back the
| whole idea of "bicycle for the mind"
|
| I love what software might look like in 15 years. I don't
| plan to kill that. I want to protect it, and also protect
| everyone involved.
| jglamine wrote:
| I really enjoyed both your blog posts. You've clearly
| thought about this a lot and explained things well. I'd
| love to subscribe to be updated on your next post (even
| if it's not for months/years). Any chance you could add
| an RSS feed to your blog?
| ondrsh wrote:
| Thanks. Added RSS, but WC3 shows some errors. I'll move
| to plain markdown when I have more time, then this will
| be easier.
| Xelynega wrote:
| > And because this can now happen at runtime, users
| (instead of developers) can add arbitrary functionality
| to applications.
|
| I don't understand what you mean by this. Currently
| without MCP a server has an API that's documented and to
| interact with it(thus provide "arbitrary functionality")
| you call those APIs from your own application code(e.x.
| python script).
|
| With MCP an LLM connected to your application code calls
| an API that's documented via MCP to provide "arbitrary
| functionality".
|
| How are these different, and how does MCP allow me to do
| anything I couldn't before with API access and
| documentation? In both cases the application code needs
| to be modified to account for the new functionality,
| unless you're also using the LLM to handle the logic
| which will have very unpredictable results.
| ondrsh wrote:
| >In both cases the application code needs to be modified
| to account for the new functionality, unless you're also
| using the LLM to handle the logic which will have very
| unpredictable results.
|
| In the case of MCP, no application code is modified. You
| first ship the application and _then_ functionality is
| added. Using plain APIs, it 's the other way around.
| That's the difference.
| vykthur wrote:
| This a good characterisation of functionality MCP might
| enable. Thanks.
|
| In your opinion, what percentage of apps might benefit from
| this model where end users bring their own MCP tools to
| extend the capabilities of your app. What are some good
| examples of this - e.g., a development tool like Cursor,
| WindSurf likely apply, but are there others, preferable with
| end users?
|
| How is the user incentivized to upskill towards finding the
| right tool to "bring in", installing it and then using it to
| solve their problem.
|
| How do we think about about the implications of bring your
| own tools, knowing that unlike plugin based systems (e.g,.
| Chrome/extensions), MCP servers can be unconstrained in
| behaviour - all running within your app
| ondrsh wrote:
| > In your opinion, what percentage of apps might benefit
| from this model where end users bring their own MCP tools
| to extend the capabilities of your app.
|
| Long term close to 100%. Basically all long-running, user-
| facing applications. I'm looking through my dock right now
| and I can imagine using AI tools in almost all of them. The
| email client could access Slack and Google Drive before
| drafting a reply, Linear could access Git, Email and Slack
| in an intelligent manner and so on. For Spotify I'm
| struggling right now, but I'm sure there'll soon be some
| kind of Shazam MCP server you can hum some tunes into.
|
| > How is the user incentivized to upskill towards finding
| the right tool to "bring in", installing it and then using
| it to solve their problem.
|
| This will be done automatically. There will be registries
| that LLMs will be able to look through. You just ask the
| LLM nicely to add a tool, it then looks one up and asks you
| for confirmation. Running servers locally is an issue right
| now because local deployment is non-trivial, but this could
| be solved via something like WASM.
|
| > How do we think about about the implications of bring
| your own tools, knowing that unlike plugin based systems
| (e.g,. Chrome/extensions), MCP servers can be unconstrained
| in behaviour - all running within your app
|
| There are actually 3 different security issues here.
|
| #1 is related to the code the MCP server is running, i.e.
| the tools themselves. When running MCP servers remotely
| this obviously won't be an issue, when running locally I
| hope WASM can solve this.
|
| #2 is that MCP servers might be able to extract sensitive
| information via tool call arguments. Client applications
| should thus ask for confirmation for every tool call. This
| is the hardest to solve because in practice, people won't
| bother checking.
|
| #3 is that client applications might be able to extract
| sensitive information from local servers via tool results
| (or resources). Since the user has to set up local servers
| themselves right now, this is not a huge issue now. Once
| LLMs set them up, they will need to ask for confirmation.
| tuananh wrote:
| > local deployment is non-trivial, but this could be
| solved via something like WASM.
|
| This is why I started working on hyper-mcp which use WASM
| for plugin development & OCI registry for hosting. You
| can write Dockerfile for plugin packaging
|
| You develop plugins in any language you want as long as
| it supports WASM
|
| https://github.com/tuananh/hyper-mcp
| paradite wrote:
| I think this is a good explanation on the client side of MCP.
| But most developers are not building MCP clients (I think?).
| Only a few companies like OpenAI, Anthropic, Cursor and Goose
| are building MCP client.
|
| Most developers are currently building MCP servers that wrap
| a 3rd party or wrap their own service. And in this case, they
| are still at deciding on the tools in design-time, not
| runtime.
|
| Also I want to mention that both Cursor and Claude desktop
| don't support dynamic toggling on / off tools within a MCP
| server, which means users can't really pick which tools to
| expose to AI. It exposes all tools within a MCP server in
| current implementation.
| ondrsh wrote:
| The concept of design-time vs. runtime applies to both
| clients and servers.
|
| I believe you're implying that server developers can focus
| less on this concept (or sometimes even ignore it) when
| building a server. This is true.
|
| However, the fact that end-users can now run MCP servers
| directly -- rather than having to wait for developers to
| bundle them into applications -- _is_ a significant
| paradigm shift that directly benefits MCP server authors.
| paradite wrote:
| I see what you mean. It is a paradigm shift indeed if you
| look from the user's perspective.
| aeonik wrote:
| You might be able the say the user could "plug in" the new
| functionality. Or it allows them to "install" a new
| "application"?
| sebazzz wrote:
| So MCP to an application is like how a WebDriver interface is
| to a Web browser?
| 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?
| TeMPOraL wrote:
| Yes. 99% of that complexity is on the side of implementers -
| _where it should be_ - and for actual use, approximately
| everything works well with everything else; specifics matter
| mostly when you 're trying to plug devices that exercise the
| limits of advanced capabilities. Which sucks, yes, but mostly
| because implementers/vendors made it this way (would it
| _hurt_ y 'all to _label_ your cables and devices properly,
| correctly and visibly?!).
| soulofmischief wrote:
| What's so hard for them to just say "it's a standard"? Why do
| we need to mention USB? Or USB-C at that, which just confuses
| the message even more?
|
| Do modern developers not know what "standards" means? Is this
| marketing slop or did an engineer seriously write that for
| other engineers?
| deepak_leanmvp wrote:
| Thinking in terms of MCP, will change your thought process to
| design your application in different way.
| amannm wrote:
| I see it as service discovery for AI applications
| TeMPOraL wrote:
| It's a beautiful and deep analogy, and works for _both_
| software engineer and their mom.
|
| Mom-level: ChatGPT ("or that other ChatGPT with a human name,
| Klaus I think? No, it was _Claude_. ") can use software that
| says it supports MCP. If it says "MCP", I can use it with my
| AI.
|
| Software dev level: MCP servers and MCP clients should _just
| work_ , like USB. I don't really have to care about this, I
| expect them to connect just fine. Like with USB, there's a crap
| ton of complexity dumped on implementers of the spec to make it
| work reliably and cheaply - _as it should be_. That 's
| _literally their job_ : to take all the "secret sauce" that
| makes their product "special" and hide it behind a standard,
| because _they 're not special and nobody cares_.
|
| As another software engineer: if it ain't USB, I ain't buying,
| because I'm too old to deal with the proprietary per-device
| unique connectors bullshit. The standard exists so I don't have
| to think about it.
| ginko wrote:
| Master Control Program?
| jtimdwyer wrote:
| Who does he calculate he is?!?
| neilv wrote:
| 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
|
| Don't hook up the MCP to any lab equipment:
|
| https://www.youtube.com/watch?v=lAcYUt2QbAo
| 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
| nilslice wrote:
| We launched mcp.run in December '24 with that prediction (err,
| gamble ;) )
| otabdeveloper4 wrote:
| Wait two more months and there will be a different _the_
| standard.
| 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?
| zambachi wrote:
| I think people often think of their specific use-case and
| tend to forget the bigger picture. MCP does not force one
| transport or the other and that is great--use any transport
| you want as long as it uses JSON RPC as the payload.
|
| The two built in transports are also extremely minimalistic
| and for SSE transport use regular HTTP--no need for web
| sockets or other heavier dependencies because SSE events
| are lightweight and broadly supported.
| tlrobinson wrote:
| 100%. I know I'm in the "get off my lawn" phase of my career
| when I see things like MCP and LangChain, but know I would
| have been excited about them earlier in my career.
| soulofmischief wrote:
| LangChain is an objectively terrible Frankenstein's monster
| of an API. If you were a good developer in your youth,
| you'd have still held it in contempt, and treat MCP with
| caution.
|
| The MCP API is pretty bad, too, it's just that a paradigm
| is starting to emege regarding modularity, integration and
| agentic tooling, and MCP happens to be the only real shot
| in that direction st this particular moment.
| gnatolf wrote:
| Could you elaborate on your issues with LangChain?
|
| We're kinda headed towards using it as it seems to be a
| flexible enough abstraction that is relatively stable to
| work with, so I'd like to know if I'm overlooking
| something..?
| gregorymichael wrote:
| A lot of folks use it to get started quickly and then
| realize the unnecessary abstractions are obfuscating the
| actual hard parts.
| jinushaun wrote:
| You spend more time fighting the tool/framework than
| working on the product you're trying to build.
| davedx wrote:
| A big soup of untyped json blobs and python, all working
| highly asynchronously in complicated ways.
|
| Is this variable available in my agent's state?
|
| Depends! Is it an agent that started an hour ago before
| you made that other change? Is it in the manager state or
| not? Did the previous agent run correctly or not? Did
| something else go wrong?
| zambachi wrote:
| How is the MCP API bad? It uses simple and widely
| available standards-based transports while still allowing
| custom transport implementations, along with a simple API
| that can be used easily without any libraries, in any
| programming language under the sun?
| davedx wrote:
| I'm seriously considering getting out of IT because of it
| romankolpak wrote:
| because of MCP and langchain?
| mordymoop wrote:
| It took me a minute to even understand this comment because
| for me the "obvious" use-case for MCP is local filesystem
| tasks, not web requests. Using MCP to manipulate files is my
| primary LLM use-case and has been ever since Anthropic
| released it and integrated it into Claude Desktop. I
| understand where you're coming from, but I suspect that the
| idea here is to build something that is more "filesystem
| first."
| keithwhor wrote:
| That makes sense. But if that's the case I think we should
| call a spade a spade and differentiate "Local-first MCP"
| and "Remote MCP"; because what (many, most?) _companies_
| are really trying to do is integrate with the latter.
|
| Which is where you see this sort of feedback, where a bunch
| of us API engineers are like; "there's already a well-
| trodden path for doing all of this stuff. Can we just do
| that and agree that it's the standard?"
| rcarmo wrote:
| Exactly my points:
| https://taoofmac.com/space/notes/2025/03/22/1900
| EGreg wrote:
| I am actually working on such a thing, and I want to get it
| righr. This is like RSS or Atom or Jabber or XMPP wars. Or
| OpenGraph vs Twitter's meta tags etc. I want interoperability
| which is cool, but I also want it to seamlessly interoperate
| with human roles and services.
|
| What is the best way to connect with you? I would like to
| discuss ideas and protocols if you're up for that.
| mbroecheler wrote:
| Second that. A lot of our use cases are "remote tooling",
| i.e. calling APIs. Implementing an MCP server to wrap APIs
| seems very complex - both in terms of implementation and
| infrastructure.
|
| We have found GraphQL to be a great "semantic" interface for
| API tooling definitions since GraphQL schema allows for
| descriptions in the spec and is very humanly readable. For
| "data-heavy" AI use cases, the flexibility of GraphQL is nice
| so you can expose different levels of "data-depth" which is
| very useful in controlling cost (i.e. context window) and
| performance of LLM apps.
|
| In case anybody else wants to call GraphQL APIs as tools in
| their chatbot/agents/LLM apps, we open sourced a library for
| the boilerplate code: https://github.com/DataSQRL/acorn.js
| _pdp_ wrote:
| Oh wow. Amazing. I did not think of that. I am not fan of
| GraphQL but you might be onto something here. I have not
| checked the code and perhaps this is not the right channel
| for this but my read is that this library allows any
| generic GraphQL server to exposed in this sort of way?
| thomasfromcdnjs wrote:
| I've been working on BLAH - Barely Logical Agent Host (https://
| github.com/thomasdavis/blah/blob/master/packages/cli...) for
| the past few weeks.
|
| It is essentially a standard (has a schema) that has an
| ecosystem of tools around it.
|
| (completely opensource, no protocol/bridge lockin, no
| vendor/provider lockin, no ide/client/auton lockin,
| http/sse/jsonrpc/whatever, local/remote, composable)
|
| So far I'm categorically calling MCP a "bridge", because BLAH
| supports other bridges such as SLOP (https://github.com/agnt-
| gg/slop/blob/main/README.md) and conceptually OpenAPI (or
| simply HTTP) is a bridge.
|
| An example blah.json looks like this "tools":
| [ { "name": "jsonresume",
| "bridge": "mcp", "command": "npx -y
| @jsonresume/mcp@3.0.0", }, {
| "name": "slop_example", "description": "Slop
| example", "bridge": "slop", "source":
| "https://ajax-valjs_slop_example.web.val.run" },
| { "name": "normal_http_example",
| "description": "Normal HTTP example", "bridge":
| "openapi", "source":
| "https:/example.com/openapi.json" } ],
| }
|
| So blah can orchestra/compose any number of bridges, and it can
| list any tools it style/format of any bridge. (sorry that
| sounds so dumb)
|
| For example, you can run `blah mcp start --config blah.json`,
| and add that to your cursor/claude mcp servers. When you fetch
| the tools, it loops over all your tools in your blah.json and
| fetches them whether it is an mcp server, slop server or
| openapi, it's agnostic and will return a full list of tools
| pulling from all bridges.
|
| And then you can do `blah slop start`, which will do the same,
| but the opposite, start a slop server but it will boot up mcp
| servers and serve them over http too.
|
| So essentially a bridge/protocol agnostic system, you ask for a
| list of tools, and it traverses everything that can list tools
| and splats them all together.
|
| That's a little of the main pitch but there are larger plans to
| try build an ecosystem like npmjs where there is a public
| registry of any tool (which are just functions at the end of
| the day). Clouldflare AI team is really getting it right now
| (https://blog.cloudflare.com/remote-model-context-protocol-
| se...), most people would rather just tools being hosted for
| them, and workers is perfect for that.
|
| It also means you just have to add one MCP server and use one
| configuration file to manage your tools. (Also has way more
| control over logging which MCP devs would love)
|
| ---
|
| And that all maybe sounds complicated, but it's meant to make
| things A LOT easier. The README.md is horrible, just lots of
| random ideas and my comment isn't much better, but I'm aiming
| to have an alpha version in a week or so. Would absolutely love
| feedback!
|
| 4.5 Deep Research Report on BLAH -
| https://gist.github.com/thomasdavis/3827a1647533e488c107e64a...
| keithwhor wrote:
| This is very cool but definitely has the XKCD standards vibe
| [0]. If the industry is standardizing on MCP but then we
| decide it's not good enough, we just end up back where we
| started. I hope there's enough willpower (and low enough ego)
| to get to a really tight, single great implementation.
|
| [0] https://xkcd.com/927/
| namaria wrote:
| Complete with the alt text mentioning USB, which is used in
| the MCP website to describe it. Someone else said it and I
| agree, it's not a good analogy. Most of what we do in
| software development is connecting things. Saying "this is
| like USB but for X" could cover a huge chunk of what
| software is.
|
| Besides, this "think of" analogies kinda irk me because I
| don't want you to give me a mental image you think I can
| digest, I want to know how it works. Abstractions in
| software are great and all but the fact that for some
| reason most explainers have decided they should be opaque
| is very unhelpful when you're trying to learn.
| soulofmischief wrote:
| Only a certain subset of developer spends most of their
| time "connecting things", and if that's the kind of
| developer you consider yourself, I'd be looking to either
| upskill or change professions as this will be the first
| kind of developer eliminated if we continue to see decent
| progress in automation.
| keithwhor wrote:
| Would disagree there -- system integration probably
| accounts for like 90% of development work; just at
| different layers of abstraction.
|
| It's evergreen work that companies are endlessly trying
| to eliminate or automate yet keep running headfirst into.
| soulofmischief wrote:
| I would still feel zero job security in such a position,
| and would be looking for work which is not only
| intellectually and creatively rewarding, but considerably
| more difficult to automate. Often this means becoming
| product-oriented or getting into leadership positions.
| kiratp wrote:
| I would urge you to not think this way:
| https://www.osmos.io/fabric
| ewoodrich wrote:
| You probably should've disclosed that you are promoting
| your own company's AI product here...
| TeMPOraL wrote:
| Doesn't mean it's not all the same or boring drudge work
| :).
|
| Though I disagree with GP's reply to you about being
| product-oriented and such - 90% of products are just
| "system integration" with some custom marketing graphics
| and a sprinkle of vendor lock in :).
|
| Combination of standardization and AI will end in a great
| carnage of software developer jobs, as system integration
| is basically the poster child of a job that should _not_
| exist in ideal world - i.e. all problems are problems of
| insufficient automation or insufficient ability to cope
| with complexity. But there 's only so much demand for R&D
| and creating bona fide new capabilities, and not everyone
| wants to be a manager or a salesperson...
|
| IDK, might be really the time to pick some trade skills,
| as manual labor in the field is likely the _last_ thing
| to be automated away.
| thomasfromcdnjs wrote:
| aha can't disagree with that sentiment, best I can do is
| not make the standard suck.
| michaelsbradley wrote:
| _ad hoc_ RPC[1] that involves JSON request /response payloads
| and is wed to HTTP transport is arguably worse than conforming
| to the JSON-RPC 2.0 specification[2].
|
| [1] if it's not REST (even giving a pass on HATEOAS) then it's
| probably, eventually, effectively RPC, and it's still _ad hoc_
| even if it's well documented
|
| [2] https://www.jsonrpc.org/specification
| imtringued wrote:
| The big irony behind HATEOAS is that LLMs are the mythical
| "evolvable agents" that are necessary to make HATEOAS work in
| the first place. HATEOAS was essentially built around human
| level intelligence that can automatically crawl your
| endpoints and read documentation written in human language
| and then they scratched their head why it didn't catch on.
|
| Only browser like clients could conform to HATEOAS, because
| they essentially delegate all the hard parts (dealing with a
| dynamically changing structureless API) to a human.
| michaelsbradley wrote:
| Well, like I wrote, "giving a pass on HATEOAS".
|
| With e.g. JSON over HTTP, you can implement an API that
| satisfies the stateless-ness constraint of REST and so on.
| Without hypermedia controls it would fit at Level 2 of the
| RMM, more or less.
|
| In that shape, it would still be a different beast from
| RPC. And a disciplined team or API overlord could get it
| into that shape and keep it there, especially if they start
| out with that intention.
|
| The problem I've seen many times is that a JSON over HTTP
| API can start out as, or devolve into, a messy mix of
| client-server interactions and wind up as _ad hoc_ RPC that
| 's difficult to maintain and very brittle.
|
| So, if a team/project isn't committed to REST, and it's
| foreseeable that the API will end up dominated by RPC/-like
| interactions, then why not embrace that reality and do RPC
| properly? Conforming to a specification like JSON-RPC can
| be helpful in that regard.
| pacjam wrote:
| Totally agree - a well-defined REST API "standard" for tool
| listing and tool execution would have been much better. Could
| extend as needed to websockets for persistent connections /
| streaming data.
| cyanydeez wrote:
| perhaps openai is the wrong tool for this thing.
| ants_everywhere wrote:
| My bias is I generally think RPC is much nicer than REST. But
| what's kind of funny here is that we have
|
| (1) an RPC to call a (remote) method called "tools/call", which
| is a method that
|
| (2) calls a method called get_weather
|
| Both methods have arguments. But the arguments of "tools/call"
| are called "params" and the arguments of "get_weather" are
| called "arguments".
|
| I realize this is a common pattern when you have to shell out,
| e.g. in python's subprocess.run().
|
| But it also seems like there could be a cleaner API with better
| types.
| keithwhor wrote:
| I don't disagree. I fought this battle for a long time -- ran
| a company where I tried to simplify SDK development by making
| every endpoint POST and JSON params; sorta like SOAP / just
| simple RPC. Why do you need all the HTTP methods when most
| SDKs simplify everything to .retrieve etc, why not name the
| endpoints that?
|
| What I realized was that these specs are valuable because
| they're stable over long periods of time and handle many
| sorts of edge cases. Also from a systems integration
| perspective, everybody already knows and is trained in them.
| Over many years I accepted the wisdom of commons.
|
| A lot of tooling already exists to make development of these
| sorts of systems easy to implement and debug. Hence why I
| think for Remote MCP servers, HTTP as it exists is a great
| choice.
| mattmanser wrote:
| I don't feel that's really true, it's easy to forget how
| fast things have moved.
|
| For a long time lots of servers didn't really support PUT
| or DELETE, and it was only the early 2010s that it became
| common.
|
| It's still a problem sometimes that you have to explicitly
| enable them (I'm looking at you IIS + WebDAV).
|
| PATCH wasn't even added till 2010 and you still don't see
| it commonly used.
|
| Perhaps we have different understandings of 'stable' and
| 'many years'.
|
| I also agree with you on RPC, it's pretty ridiculous that
| some guys tried to boil every single API down to
| essentially 4 verbs. I remember when Google went all crazy
| on implementing pure REST and their APIs were atrocious.
|
| And everyone still goes along with it even though it
| clearly doesn't work, so you always end up with a mix of
| REST and RPC in any non-trivial API.
|
| But pure RPC doesn't really work as then you have to change
| every call to a POST, as you mention. Which is also
| confusing as everyone is now used to using the really
| restricted REST CRUD interface.
|
| So now pure REST sucks and pure RPC sucks. Great job HTTP
| standards team!
|
| To be fair to them, I know it's hard and at some point you
| can't fix your mistakes. These days I guess I've just
| accepted that almost all standards are going to suck a bit.
| croes wrote:
| Maybe MCP was developed with AI. LLMs tend to be overly verbose
| antupis wrote:
| Why is this get_weather location "New York" always an example
| when people talk about tool calling?
| deadbabe wrote:
| Because if you can make it New York City, you can make it
| anywhere.
| richsong wrote:
| 1/ pre-trained models don't know current weather
|
| 2/ easy enough for people to understand
| pulkitsh1234 wrote:
| "Tool calling" is just one part of MCP, there are more things
| like "Sampling" which allow the server itself to initiate stuff
| on the client. As for tool calling, having a layer like MCP
| makes sense because there a lot of things which don't have a
| REST-API + may need direct access to the computer (filesystem,
| processes, etc).
|
| Examples:
|
| * Running SQL commands on a DB or a Redis instance. * Launching
| Docker containers, SSHing to a server an running some command.
| * Reading a file and extracting relevant information from it,
| like OCR. * Controlling a remote browser using the WebDriver
| protocol, have some kind of persistent connection to a backend.
|
| As for just pure REST-API usecases, I think MCP serves what
| Swagger/OpenApi-Spec are meant to do, i.e. enforce some kind of
| format and give each endpoint a "Name" + list of Params which
| the LLM can invoke. The issue is that there is no standardised
| way to pass these API specs to LLMs as tools (maybe something
| can be built in this space). In the future, I can easily see
| some kind of library/abstraction that allows an MCP server to
| parse an existing API spec file to expose those APIs as tools
| which can be combined with some local state on the computer to
| allow stateful interactions with a REST API.
| dan-kwiat wrote:
| I just made a tool which parses any OpenAPI spec to MCP spec:
| https://www.open-mcp.org (literally just deployed so I don't
| know if the DNS has propagated globally yet..)
| zomglings wrote:
| I received a 500 response when I attempted to create an MCP
| server for an API.
|
| I was using this URL:
| https://engineapi.moonstream.to/metatx/openapi.json
|
| The response body: {success: false,
| error: "Server URL must start with https:// or http://"}
| dan-kwiat wrote:
| Thanks, I just added support for relative URLs, try
| again. Your OpenAPI spec defines a relative base URL for
| the server /metatx but no domain. You can now specify the
| full base URL in your MCP client's environment variables:
|
| `OPEN_MCP_BASE_URL="https://engineapi.moonstream.to/metat
| x"`
| ammmir wrote:
| Yeah, I always thought MCP was a bit verbose. It reminds me of
| the WSDL and SOAP mess of the 2000s. Model tool calls are just
| RPCs into some other service, so JSON-RPC makes sense. Is there
| anything else has wide adoption and good client support? XML-
| RPC? gRPC? Protobufs? I mean, it shouldn't need extra libraries
| to use. You can handroll a JSON-RPC request/response pretty
| easily from any programming language.
|
| Regarding the verbosity, yeah, it's interesting how model
| providers make more money from more tokens used, and you/we end
| up paying for it somehow. When you're doing lots of tool calls,
| it adds up!
| thisisfixer wrote:
| fully agree, and that's what we do at ACI.dev as a managed
| authenticated tool calling platform. https://www.aci.dev/ And
| we expose more tool discovery flexibility rather than just
| list_tools()
| ramesh31 wrote:
| >And we expose more tool discovery flexibility rather than
| just list_tools()
|
| Extremely curious about this as just directly listing all
| tools to an agent will obviously not scale well. What does
| the interface look like?
| thanatropism wrote:
| Ehh. Sometimes you don't want to have to have string builders
| to assemble REST calls.
| 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.
| imtringued wrote:
| The revenue plan for hosted services is that every user
| with an MCP client will count as a billable user.
| 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?
| NicuCalcea wrote:
| Most MCP servers are thin wrappers around an API, I don't think
| there will be a big paid market. I imagine they will be
| released like SDKs are now, either by companies themselves, or
| by individuals when there's no official implementation. A few
| dev agents can even write MCP servers for themselves.
|
| https://www.reddit.com/r/ClaudeAI/comments/1hcrxl6/cline_can...
| 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.
| esafak wrote:
| Where are the community-created server APIs for your format?
| Why would you re-invent the wheel and rewrite them all
| yourself?
| 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.
| philomath_mn wrote:
| 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 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).
| consumer451 wrote:
| I only use one regularly, but I use it a lot. (Supabase)
|
| Example use case: https://news.ycombinator.com/item?id=43466434
| nomilk wrote:
| 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 wrote:
| 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 wrote:
| 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?
| antoinec wrote:
| I have two that I use a lot: - Postgres one connected to my
| local db - A browser (Playwright) That way I can ask cursor
| something like: "Find an object with xxx property in the db,
| open its page in the browser, fix console errors" And it's able
| to query my db, find relevant object, open the browser, check
| logs, fix the code based on errors.
|
| Even simpler stuff: - copying pasting a broken local url in
| cursor, and asking it to fix all console errors. Works really
| well. - or when you have a complex schema, and need to find
| some kind of specific record, you can just ask cursor "find me
| a user that has X transactions, matches Y condition, etc..". I
| found it much faster than me at finding relevant records
| knowaveragejoe wrote:
| I mainly use simple integrations:
|
| - fetch, essentially curl any webpage or endpoint
|
| - filesystem, read(and occasionally write) to local disk
|
| - mcp-perplexity, so I can essentially have Claude sample from
| perplexity's various models and/or use it for web search.
| Somewhat superseded by Claude's own new web search capability,
| but perplexity's is generally better.
| 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 (but could be any from OpenAI as well, or
| Anthropic, whatever).
| nomel wrote:
| 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 wrote:
| 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 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
| NicuCalcea wrote:
| 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 wrote:
| 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
| tonyhb wrote:
| 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 wrote:
| Big fan of Inngest! Most of http://glama.ai/mcp logic is
| built on top of Inngest.
| __mharrison__ wrote:
| Awesome. I'm preparing an AI course and it looks like the APIs
| are starting to converge finally...
| johnjungles wrote:
| If you want to try out mcp (model context protocol) with little
| to no setup:
|
| I built 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 wrote:
| This looks super cool and I can see myself using this!
|
| Although the name is a bit unfortunate.
| pfista wrote:
| my favorite is implementing issues from linear
| ogundipeore wrote:
| 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 wrote:
| 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 wrote:
| We need to also add Tron support, otherwise who's going to fight
| for the users?
| eigenvalue wrote:
| 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
| Tewboo wrote:
| Impressive move by OpenAI. MCP support in Agents SDK will greatly
| enhance AI agent capabilities. Can't wait to see how developers
| leverage it.
| goaaron wrote:
| 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 wrote:
| 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 wrote:
| You're way over thinking the use cases for MCPs. That tells me
| you should stick to functions.
| mkagenius wrote:
| > That tells me you should stick to functions.
|
| probably we all should -\\_(tsu)_/-
| prometheon1 wrote:
| 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/sr...
| singularity2001 wrote:
| 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 wrote:
| 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 wrote:
| is this the new langchain?
| paradite wrote:
| 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 wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2025-03-27 23:01 UTC)