TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

The Future of MCPs

185 点作者 tylerg29 天前

16 条评论

freedomben29 天前
Interesting thoughts regarding MCPs being the future App Store&#x2F;Platform. I don&#x27;t know that I agree but I don&#x27;t necessarily disagree either. Time will certainly tell.<p>To me, MCP feels more like an implementation detail, not something that most people would ever use directly. I would expect that the future would be some app distributed through existing channels, which bundles the MCP client into it, then uses a server-side component (run by the vendor of course) to get the real work done. As much as I like the idea of people installing the servers locally, that future seems like a Linux nerd&#x2F;self hosted type of activity. I just can&#x27;t imagine a typical mac or windows non-power-user installing one directly. Just the idea that they would need to install &quot;two apps&quot; is enough to confuse them immensely. It&#x27;s possible some might bundle the server too and run it locally as needed, but even in that case I think MCP is completely invisible to the user.
评论 #43776727 未加载
评论 #43774872 未加载
评论 #43776299 未加载
评论 #43774927 未加载
评论 #43776742 未加载
3np29 天前
&gt; Think of MCPs as standardized APIs—connectors between external data sources or applications and large language models (LLMs) like ChatGPT or Claude.<p>This is incorrect.<p>MCP is Model Context Protocol.<p>You didn&#x27;t &quot;build an MCP&quot;, you implemented an MCP server. Lighttpd is not &quot;an HTTP&quot;, it&#x27;s an HTTP server. wget is also not &quot;an HTTP&quot;, it&#x27;s an HTTP client. Lighttpd and wget are different enough that it&#x27;s useful to make that distinction clear when labeling them.<p>dnsmasq is not &quot;a DHCP&quot;, it&#x27;s a DHCP server.<p>This distinction also matters because it is certain that we will see further protocol iterations so we will indeed have multiple different MCPs that may or may not be compatible.
评论 #43775999 未加载
评论 #43777011 未加载
评论 #43782296 未加载
评论 #43776627 未加载
guideamigo_com129 天前
MCP might be one of the few technology pieces where more articles have been written about it than the actual use-cases being built.<p>It is like the ERC20 era all over again.
评论 #43777646 未加载
评论 #43775433 未加载
评论 #43777342 未加载
评论 #43775146 未加载
评论 #43775267 未加载
评论 #43775256 未加载
评论 #43775152 未加载
brap29 天前
My prediction: there will be no standard protocol, clients will do whatever works for them, and devs will do whatever it takes to be installable on those clients. Just like mobile.
评论 #43783158 未加载
baalimago28 天前
If LLMs are so smart, why do they need a custom &quot;MCP&quot; format to what&#x27;s commonly known as a normal API? Why can&#x27;t they just call normal APIs?<p>Extending this thought: why would there be any difference between offering data behind an API, and offering data behind a &quot;MCP api&quot;? 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 &quot;standardized&quot;, otherwise it doesn&#x27;t get it (?).<p>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&#x27;s enough to expose the same data on a normal website?<p>I don&#x27;t get it.
评论 #43782178 未加载
评论 #43782588 未加载
评论 #43780739 未加载
评论 #43779957 未加载
评论 #43781476 未加载
评论 #43780998 未加载
gadders29 天前
&gt;&gt;MCP Affiliate Shopping Engines<p>As someone else once said, I want a Grocery Shopping Engine. &quot;Here&#x27;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.&quot;<p>If MCPs gave the LLMs a window into all the major supermarkets home shopping sites that looks like it&#x27;s a step closer.
评论 #43780657 未加载
评论 #43800077 未加载
评论 #43776361 未加载
neuroelectron28 天前
MCP is perhaps the biggest attack vector I&#x27;ve seen people willingly adopt simply for FOMO. Nothing about implementing it is defined or tractable. Even logging its use is extremely complicated.
bravetraveler29 天前
<i>MCP</i> in this context means <i>&quot;Model Context Protocol&quot;</i><p>I thought it might be <i>&quot;managed cloud providers&quot;</i>, but perhaps I&#x27;m too optimistic for a change
评论 #43774930 未加载
kaycebasques29 天前
If you&#x27;re sold on MCP, what was your &quot;wow&quot; moment? I&#x27;ve read the docs and tinkered a bit but it was a decidedly &quot;meh&quot; experience personally. It seems very similar to ChatGPT Plugins, and that was a flop. I don&#x27;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 have to opt-in to tens or hundreds of servers. Yet I&#x27;ve heard that clients start to struggle once you have more than 20 servers plugged in...? Please excuse any fundamental errors I&#x27;ve repeated here, if any...
评论 #43776256 未加载
评论 #43777072 未加载
评论 #43776734 未加载
评论 #43777166 未加载
评论 #43776588 未加载
评论 #43782645 未加载
评论 #43776834 未加载
ilaksh28 天前
Anyone 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&#x27;s generally not necessary. You just go to the admin and install plugins with the tools. <a href="https:&#x2F;&#x2F;github.com&#x2F;runvnc&#x2F;mindroot">https:&#x2F;&#x2F;github.com&#x2F;runvnc&#x2F;mindroot</a><p>How does discovery work with MCP? Is there a way to make it fairly seamless?
helsinki29 天前
Are there any open-source MCP &#x27;app stores&#x27; currently available? I am considering building one for my employer. A place to host internally built MCPs. It would be useful to know if there is something already out there.
评论 #43778141 未加载
评论 #43775931 未加载
relistan28 天前
My experience so far with MCP is also that this is not ready yet. There are a few working use cases, but generally this stuff is pretty raw.
nilslice29 天前
we’ve been building most of what OP has written about with <a href="https:&#x2F;&#x2F;mcp.run" rel="nofollow">https:&#x2F;&#x2F;mcp.run</a><p>We started doing this the day Anthropic released MCP in November last year. Our company has always been devoted to secure plug-in system technology having built Extism, a WebAssembly plugin framework.<p>We immediately saw MCP as the plugin system for AI and knew it would be significant, but were concerned about the security implications of running MCP servers from untrusted parties and using the STDIO transport which makes user systems vulnerable in ways we weren’t ok with.<p>So we built mcp.run which is a secure implementation of the protocol, running servers in fully isolated &amp; portable wasm modules. They must be allow-listed to access files &amp; network hosts, and cannot access any part of your system without your explicit permission.<p>They also run everywhere. Each server (we call them servlets) on mcp.run is automatically available via SSE (soon HTTP streaming) as well as STDIO, but can also be embedded directly into your AI apps, no transport needed, and can run natively on mobile!<p>We are excited about MCP and glad so many are too - but we really need more security-oriented implementations before it’s too late and someone suffers a seriously bad exploit - which could tarnish the ecosystem for everyone.
评论 #43776781 未加载
wkat424228 天前
The Master Control Program has no future!
taytus28 天前
The future? MCP is fighting even to have a present.
评论 #43785705 未加载
kristjank29 天前
MCPs tries too hard to signal XHR for AI, but nobody wants to earnestly deal with the consequences of AI interfacing in a wider context of mis-&#x2F;disinformation, hallucination and generally letting <i>it</i> talk to stuff in a semi-unprompted manner.