The Master Control Program has no future!
The Future of MCPs
51–60 of 90 posts
Re: The Future of MCPs
#52If you're sold on MCP, what was your "wow" moment? I've read the docs and tinkered a bit but it was a decidedly "meh" experience personally. It seems very similar to ChatGPT Plugins, and that was a flop. I don't really like the fuzzy nature of the architecture, where I never know what server will be invoked. And I have to manually opt-in to each server I want to use? To be unexpectedly useful, it seems like I would h…
For me it was implementing a simple `execute_terminal_command` tool along with hooking up to my company's jira and gitlab (dont worry security gurus, for the command line, I have a hardcoded list of allowed read-only commands that the LLM can execute, and both jira and gitlab servers likewise have readonly options.) What I will say is I agree there should be an option to get rid of the chat confirmations of every sin…
Open webui let's you do all that. You set up single model agents and assign specific tools. You can also beef it up with system prompts.
On that note, the various agents libraries will let you create that same setup.
Re: The Future of MCPs
#53>>MCP Affiliate Shopping Engines As someone else once said, I want a Grocery Shopping Engine. "Here's my shopping list, taking into consideration delivery times and costs, please buy this for the lowest cost from any combination of supermarkets and deliver by day after tomorrow at the latest." If MCPs gave the LLMs a window into all the major supermarkets home shopping sites that looks like it's a step closer.
> If MCPs gave the LLMs a window into all the major supermarkets home shopping sites that looks like it's a step closer. And how exactly will they do that?
There are existing comparison services that keep track of prices and locations of grocery items. MCP is just the glue code.
Re: The Future of MCPs
#54> Think of MCPs as standardized APIs—connectors between external data sources or applications and large language models (LLMs) like ChatGPT or Claude. This is incorrect. MCP is Model Context Protocol. You didn't "build an MCP", you implemented an MCP server. Lighttpd is not "an HTTP", it's an HTTP server. wget is also not "an HTTP", it's an HTTP client. Lighttpd and wget are different enough that it's useful to make…
I’d just like to interject for a moment. What you’re refering to as Linux, is in fact, GNU/Linux, or as I’ve recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX. Many computer users run a modifi…
Honestly can't tell if this is very dry sarcasm or not
Re: The Future of MCPs
#55MCP is perhaps the biggest attack vector I've seen people willingly adopt simply for FOMO. Nothing about implementing it is defined or tractable. Even logging its use is extremely complicated.
Re: The Future of MCPs
#56Earlier quoted context omitted.
I’d just like to interject for a moment. What you’re refering to as Linux, is in fact, GNU/Linux, or as I’ve recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX. Many computer users run a modifi…
Honestly can't tell if this is very dry sarcasm or not
It's tired copypasta. Typically interpreted as "parent is a silly nitpicking neckbeard keyboard warrior".
Re: The Future of MCPs
#57> Think of MCPs as standardized APIs—connectors between external data sources or applications and large language models (LLMs) like ChatGPT or Claude. This is incorrect. MCP is Model Context Protocol. You didn't "build an MCP", you implemented an MCP server. Lighttpd is not "an HTTP", it's an HTTP server. wget is also not "an HTTP", it's an HTTP client. Lighttpd and wget are different enough that it's useful to make…
> You didn't "build an MCP" The author explicitly states he built 2 MCP servers , not 2 MCPs, so I don’t know where your beef is coming from
I had the exact same reaction to the plural "MCPs". That's silly wording. There are no multiple MCPs. It's a single protocol. It's hilariously awkward wording to say you built "an MCP". It's like saying you built "an FTP", or "an HTTP". I guess every Web App is really just "an HTTP". We've been talking wrong all these years. lol.
Re: The Future of MCPs
#58If LLMs are so smart, why do they need a custom "MCP" format to what's commonly known as a normal API? Why can't they just call normal APIs?
Extending this thought: why would there be any difference between offering data behind an API, and offering data behind a "MCP api"? At the end of the day, the underlying data will be the same (weather, stock market info, logs, whatever), it seems LLMs just needs this to be "standardized", otherwise it doesn't get it (?).
Furthermore..! LLMs can already crawl web pages just fine using (true) restful technologies. So why would there be need for other, new, special APIs when it's enough to expose the same data on a normal website?
I don't get it.
Re: The Future of MCPs
#59Anyone else explored a plugin approach to bundle tools with the client? I started down that path long before MCP was a thing. I do plan to add MCP and A2A support at some point. But for my program it's generally not necessary. You just go to the admin and install plugins with the tools. https://github.com/runvnc/mindroot
How does discovery work with MCP? Is there a way to make it fairly seamless?
Re: The Future of MCPs
#60Earlier quoted context omitted.
MCP's will be run by the service providers, and you'll have the ability to "link" them, just like today you can link a Google account to give access to Calendar, GDrive, ... in the future you'll be able to give a model access to the Google MCP for your account.
i wonder how granular the permissions will get though. giving model-level access to something like Gmail sounds powerful, but also like a privacy minefield if not done carefully. curious to see how trust and isolation get handled.
Those oauth permission dialogs come to mind but they may need to improve significantly to become useful.
I don't think most of those are granular enough.