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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

MCP: An in-depth introduction

201 点作者 ritzaco5 天前

13 条评论

epistasis1 天前
&gt; But even after a few hours of reading about what MCP is and working through an example , it can be confusing to follow exactly what is happening when and where. What does the LLM do? What does the MCP server do? What does the MCP client do? Where does data flow, and where are choices made?<p>Yeah MCP is the worst documented technology I have ever encountered. I understand APIs for calling LLMs, I understand tool calling APIs. Yet I have read so much about MCP and have zero fucking clue except vague marketing speak. Or code that has zero explanation. What an amateur effort.<p>I&#x27;ve given up, I don&#x27;t care about MCP. I&#x27;ll use tool calling APIs as I currently do.
评论 #44014187 未加载
评论 #44012862 未加载
oliviergg大约 22 小时前
I have trouble understanding the level of criticism about MCPs. As I understand it, it&#x27;s just a tool that allows an LLM to communicate with other tools.<p>People often talk about web APIs, but we should also consider the integration of local tools. For me, the integration is mind-blowing.<p>When I tried the Playwright MCP integration [0][1] a few months ago, I really felt that after giving computers the ability to speak or communicate, we had now given them arms. I still get goosebumps thinking about it.<p>[0]<a href="https:&#x2F;&#x2F;youtu.be&#x2F;3NWy_sxD3Vc" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;3NWy_sxD3Vc</a> [1]<a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;playwright-mcp">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;playwright-mcp</a> [EDIT]
评论 #44014945 未加载
评论 #44013914 未加载
评论 #44014207 未加载
defaultcompany大约 15 小时前
One confusing thing to me was the word &quot;server&quot;. An &quot;MCP server&quot; is a server to the LLM &quot;client&quot;. But the MCP server itself is a client to the thing it&#x27;s connecting the LLM to. So it&#x27;s more like an adapter or proxy. Also I was confused because often this server runs on your local system (although it doesn&#x27;t have to). In my mind I thought if they&#x27;re calling it a server it must be run in the cloud somewhere but that&#x27;s often not the case.
评论 #44015996 未加载
评论 #44016088 未加载
amannm大约 18 小时前
It&#x27;s a half-baked, rushed out, speculative attempt to capture developer mindshare and establish an ecosystem&#x2F;moat early in a (perceived) market. It&#x27;s a desperate &quot;standard&quot; muscled in by Amazon&#x2F;Claude, similar to their overwrought &quot;Smithy&quot; IDL that basically nobody outside the Amazon SDK team chooses to use for API&#x2F;Schema management. It will end up in that same niche in the long term, most likely... AWS&#x2F;Amazon&#x2F;Claude specific app integrations, buried underneath some other 3rd party framework that abstracts it away and makes the &quot;spec&quot; irrelevant.
评论 #44014644 未加载
评论 #44014744 未加载
评论 #44015083 未加载
CSMastermind大约 15 小时前
Anyone who has worked with LLMs for non-trival tasks know how poorly they handle JSON vs other formats (they do notably well with XML for some reason but even YAML seems to be handled fine).<p>MCP forcing JSON for tool specifications seems like a massive mistake.<p>Maybe Google can save us with something built on top of protobuffs.
评论 #44016783 未加载
评论 #44016876 未加载
shaneos大约 20 小时前
Using MCP in production has a lot of tricky edge cases. This post describes some cool solutions to them <a href="https:&#x2F;&#x2F;www.stainless.com&#x2F;blog&#x2F;what-we-learned-converting-complex-openapi-specs-to-mcp-servers" rel="nofollow">https:&#x2F;&#x2F;www.stainless.com&#x2F;blog&#x2F;what-we-learned-converting-co...</a>
snowstormsun大约 18 小时前
MCP is practically useful, but the total lack of security in its &quot;design&quot; for me just underlines the type of YOLO-driven development and lack of quality that&#x27;s being marketed as productivity improvement in software engineering too often these days.
评论 #44015329 未加载
danjc1 天前
MCP Clients need to support auth (and probably the spec needs to have a broader set of options for auth) - this is going to be a major blocker for adoption.
评论 #44013906 未加载
评论 #44012668 未加载
valzam大约 20 小时前
Isn&#x27;t MCP just an OpenAPI spec that everyone agrees on? I don&#x27;t really get the confusion around it
评论 #44015477 未加载
评论 #44013889 未加载
quantadev大约 17 小时前
Not to complain but this &quot;introduction&quot; would&#x27;ve been better if it was just a simple tool to add numbers to make an LLM able to solve &quot;What is 10 + 50?&quot; using a remote tool. By solving a complex problem you&#x27;ve just added unnecessary complexity. Everyone would&#x27;ve already known how to extend a function call to solve some other set of problems. Sure it made the intro more &quot;impressive&quot; as an actual accomplishment, but seems like counterproductive impressiveness bordering on just showing off. lol. Nice work tho. I was impressed.
TZubiri1 天前
I feel like I need the opposite, a cursory view, or at least a definition.<p>Most of the material on MCP is either too specific or too in depth.<p>WTF is it?! (Other than a dependency by Anthropic)
评论 #44012485 未加载
评论 #44012252 未加载
评论 #44012056 未加载
评论 #44011940 未加载
评论 #44011426 未加载
评论 #44011344 未加载
TZubiri1 天前
&quot;“MCP is an open protocol that standardizes how applications provide context to LLMs, what’s the problem?”&quot;<p>We are already off to a wrong start, context has a meaning specific to LLMs, everyone who works with LLMs knows what it means: the context is the text that is fed as input at runtime to LLM, including the current message (user prompt) as well as the previous messages and responses by the LLM.<p>So we don&#x27;t need to read any further and we can ignore this article, and MCPs by extension, YAGNI
评论 #44011459 未加载
评论 #44012023 未加载
andes3141 天前
For anyone confused, you can play with mcp for free on usetexture.com
评论 #44012034 未加载