{"slug": "mcp", "name": "MCP", "category": "ai", "category_name": "AI models and assistants", "description": "Open protocol for connecting AI models and agents to external tools and data sources", "recommenders": 7, "commenters": 11, "warners": 3, "score": 4.019, "rising": 1.36, "first": "2026-03-01", "latest": "2026-09-30", "why": "HN commenters value MCP as a widely adopted standard for connecting AI agents to APIs and internal tools, and for letting servers describe their capabilities in natural language so clients can use them without prior knowledge.", "why_is_quote": false, "has_verdict": true, "sentiment": {"recommend": 8, "neutral": 1, "compare": 0, "warn": 3}, "spark": [0, 0, 0, 0, 2, 0, 0, 3, 0, 1, 2, 0], "listed": true, "loved": ["Broad ecosystem", "Practical integrations"], "caveat": "Unnecessary abstraction", "short_quote": "I use MCP to accelerate CAD mould-making and for music production.", "icon": true, "domain": null, "github_repo": null, "official_url": "https://modelcontextprotocol.io", "pricing": "open source", "aliases": ["MCP"], "verdict": [{"text": "HN commenters value MCP as a widely adopted standard for connecting AI agents to APIs and internal tools,", "cites": [{"id": 798509840, "item_id": 49906865, "url": "https://news.ycombinator.com/item?id=49906865", "by": "_fw", "date": "2026-09-30", "stance": "recommend", "quote": "", "excerpt": "I appreciate their reluctance towards MCP, but /something/ is better than nothing. It\u2019s suboptimal for the reasons the author outlines: but so is USB-C. So is NVME, so is HDMI. We use these hugely successful technologies in spite of their flaws because they\u2019re widely compatible and easy for the end user. That\u2019s why MCP is everywhere. It might not be performant, robust and uniform but it WILL get better over time. And", "context": "", "use_case": "connecting LLMs to tools", "switched_from": "", "story": "You said no MCP"}, {"id": 755342592, "item_id": 47208912, "url": "https://news.ycombinator.com/item?id=47208912", "by": "phpnode", "date": "2026-03-01", "stance": "recommend", "quote": "MCP is going to be around for a long time, and we can expect it to get much better than it is today.", "excerpt": "I don't doubt that CLIs + skills are a good alternative to MCP in some contexts, but if you're building an app for non-developers and you need to let users connect it to arbitrary data sources there's really no sensible, safe path to using CLIs instead. MCP is going to be around for a long time, and we can expect it to get much better than it is today.", "context": "building an app for non-developers", "use_case": "connecting apps to data sources", "switched_from": "", "story": "MCP is dead. Long live the CLI"}, {"id": 796646352, "item_id": 49790397, "url": "https://news.ycombinator.com/item?id=49790397", "by": "rsolva", "date": "2026-09-21", "stance": "recommend", "quote": "MCP is exactly the lipstick we needed to put on our pigs", "excerpt": "MCP is exactly the lipstick we needed to put on our pigs, APIs that is not ours, but open source tools we use internally and also wanted to expose to our agents.", "context": "", "use_case": "exposing internal tools to agents", "switched_from": "", "story": "MCP was always a bad idea?"}, {"id": 777465744, "item_id": 48591609, "url": "https://news.ycombinator.com/item?id=48591609", "by": "thallavajhula", "date": "2026-06-18", "stance": "recommend", "quote": "it's back to Agent <> MCP now; couple that with tool search/code mode (whatever you want to call it) in your Agentic AI harness, MCPs seem to be the way to go for now.", "excerpt": "In the past 1 year, I think I've moved from MCP to A2A to Agent <> MCP back again. I have agents still talking to other Agents via A2A for some use cases, but for the most part, it's back to Agent <> MCP now; couple that with tool search/code mode (whatever you want to call it) in your Agentic AI harness, MCPs seem to be the way to go for now.", "context": "", "use_case": "agent tool integration", "switched_from": "", "story": "Ask HN: Is anyone using the A2A protocol yet?"}]}, {"text": " and for letting servers describe their capabilities in natural language so clients can use them without prior knowledge.", "cites": [{"id": 777494400, "item_id": 48593400, "url": "https://news.ycombinator.com/item?id=48593400", "by": "brookst", "date": "2026-06-18", "stance": "recommend", "quote": "I am a complete convert.", "excerpt": "I agree that having auth outside of context window is good. But the real value of MCP is adding a semantic layer on top of APIs. Skills are client side and don\u2019t know the server\u2019s capabilities. MCP lets the server explain its API in natural language so clients who have no prior knowledge of the server, it\u2019s API, or its domain can use it intelligently. I used to think MCP was dumb. I\u2019ve written to large MCP servers, o", "context": "has written large MCP servers", "use_case": "servers for CAD and music", "switched_from": "", "story": "Zero-Touch OAuth for MCP"}, {"id": 777493968, "item_id": 48593373, "url": "https://news.ycombinator.com/item?id=48593373", "by": "flashgordon", "date": "2026-06-18", "stance": "recommend", "quote": "So mcp is really an \"app framework\" than a protocol", "excerpt": "This is fantastic. Ive been so fortunate to work with the mcp folks last few months on a couple of the SEPs (and my own experimental sdk in go). I used to be a naysayer. \"Its just apis\" I used to say. \"Sheesh the invented another abstraction\" I used to say. What folks dont realize is it is the \"P\" in MCP that throws people off. When you build a traditional app you have to build forms, ui, req/response handling, bidir", "context": "contributes to MCP SEPs", "use_case": "app framework with unified auth", "switched_from": "", "story": "Zero-Touch OAuth for MCP"}]}, {"text": " The most common criticism is that CLIs and skills make it unnecessary,", "cites": [{"id": 758201440, "item_id": 47387590, "url": "https://news.ycombinator.com/item?id=47387590", "by": "ArcaneMoose", "date": "2026-03-15", "stance": "warn", "quote": "I still think MCP is completely unnecessary (and have from the start).", "excerpt": "I still think MCP is completely unnecessary (and have from the start). The article correctly points out where CLI > MCP but stops short on 2 points: 1. Documenting the interface without MCP. This problem is best solved by the use of Skills which can contain instructions for both CLIs and APIs (or any other integration). Agents only load the relevant details when needed. This also makes it easy to customize the docs f", "context": "", "use_case": "agent tool integration", "switched_from": "", "story": "MCP Is Dead; Long Live MCP"}, {"id": 792959361, "item_id": 49559960, "url": "https://news.ycombinator.com/item?id=49559960", "by": "agentdev001", "date": "2026-09-04", "stance": "warn", "quote": "I'm frustrated to see that new projects on my team still consider MCP as a reasonable first pass solution", "excerpt": "I am not using MCP in be production- but, my team is. My team also produces MCP servers for other teams, and I find it a bit maddening. I wonder if anyone can relate to my experience here. It feels like there is a significant amount of baggage with MCP. It had first mover advantage- coming in at a time when the frontier looked much different. Models were significantly less predictable, would consistently screw up too", "context": "team produces MCP servers for other teams", "use_case": "giving agents tool access", "switched_from": "", "story": "Ask HN: Who is using MCP in production?"}]}, {"text": " with others calling the spec poorly written.", "cites": [{"id": 770650384, "item_id": 48165649, "url": "https://news.ycombinator.com/item?id=48165649", "by": "epistasis", "date": "2026-05-16", "stance": "warn", "quote": "anybody involved with MCP's launch should be ashamed of what they put out there", "excerpt": "> Despite the fact that MCP is an utterly terrible attempt at a \"specification\", Can I just say that anybody involved with MCP's launch should be ashamed of what they put out there. I understand tool calling. I understand specs. I read MCP's \"spec\" and I used useless word salad that alternates between baby's first wire format and pie-in-the-sky marketing speak. Several of the navigation links I encountered were broke", "context": "", "use_case": "tool calling spec", "switched_from": "", "story": "MCP Hello Page"}]}], "praise": [{"label": "Broad ecosystem", "summary": "Commenters prefer one widely compatible standard over many competing integration methods, despite its flaws.", "quotes": [{"id": 798509840, "item_id": 49906865, "url": "https://news.ycombinator.com/item?id=49906865", "by": "_fw", "date": "2026-09-30", "stance": "recommend", "quote": "", "excerpt": "I appreciate their reluctance towards MCP, but /something/ is better than nothing. It\u2019s suboptimal for the reasons the author outlines: but so is USB-C. So is NVME, so is HDMI. We use these hugely successful technologies in spite of their flaws because they\u2019re widely compatible and easy for the end user. That\u2019s why MCP is everywhere. It might not be performant, robust and uniform but it WILL get better over time. And", "context": "", "use_case": "connecting LLMs to tools", "switched_from": "", "story": "You said no MCP"}, {"id": 755342592, "item_id": 47208912, "url": "https://news.ycombinator.com/item?id=47208912", "by": "phpnode", "date": "2026-03-01", "stance": "recommend", "quote": "MCP is going to be around for a long time, and we can expect it to get much better than it is today.", "excerpt": "I don't doubt that CLIs + skills are a good alternative to MCP in some contexts, but if you're building an app for non-developers and you need to let users connect it to arbitrary data sources there's really no sensible, safe path to using CLIs instead. MCP is going to be around for a long time, and we can expect it to get much better than it is today.", "context": "building an app for non-developers", "use_case": "connecting apps to data sources", "switched_from": "", "story": "MCP is dead. Long live the CLI"}, {"id": 770650384, "item_id": 48165649, "url": "https://news.ycombinator.com/item?id=48165649", "by": "epistasis", "date": "2026-05-16", "stance": "warn", "quote": "anybody involved with MCP's launch should be ashamed of what they put out there", "excerpt": "> Despite the fact that MCP is an utterly terrible attempt at a \"specification\", Can I just say that anybody involved with MCP's launch should be ashamed of what they put out there. I understand tool calling. I understand specs. I read MCP's \"spec\" and I used useless word salad that alternates between baby's first wire format and pie-in-the-sky marketing speak. Several of the navigation links I encountered were broke", "context": "", "use_case": "tool calling spec", "switched_from": "", "story": "MCP Hello Page"}]}, {"label": "Practical integrations", "summary": "Used to expose internal tools and APIs to agents for work such as CAD, music production and evals.", "quotes": [{"id": 796646352, "item_id": 49790397, "url": "https://news.ycombinator.com/item?id=49790397", "by": "rsolva", "date": "2026-09-21", "stance": "recommend", "quote": "MCP is exactly the lipstick we needed to put on our pigs", "excerpt": "MCP is exactly the lipstick we needed to put on our pigs, APIs that is not ours, but open source tools we use internally and also wanted to expose to our agents.", "context": "", "use_case": "exposing internal tools to agents", "switched_from": "", "story": "MCP was always a bad idea?"}, {"id": 790407920, "item_id": 49400495, "url": "https://news.ycombinator.com/item?id=49400495", "by": "brookst", "date": "2026-08-22", "stance": "recommend", "quote": "I use MCP to accelerate CAD mould-making and for music production.", "excerpt": "I\u2019ll never understand the \u201cI\u2019ve never used it but am absolutely certain I would get zero value from it if I did\u201d mentality. I use MCP to accelerate CAD mould-making and for music production. I use it to avoid copying and pasting slack threads, and to let AI drive an eval system so I don\u2019t have to manually configure things in a UI. It\u2019s just hard to imagine both not using it and being so sure it has no use.", "context": "", "use_case": "CAD, music production, Slack, evals", "switched_from": "", "story": "New MCP Roadmap"}, {"id": 755475041, "item_id": 47217190, "url": "https://news.ycombinator.com/item?id=47217190", "by": "yuvrajangads", "date": "2026-03-02", "stance": "recommend", "quote": "the local tool-use model works well because I control both sides", "excerpt": "I've been using MCP with Claude Code for a while now (Google Maps, Swiggy, Figma servers) and the local tool-use model works well because I control both sides. I pick which servers to trust, I see every tool call, and I can deny anything sketchy. WebMCP flips that. The website exposes the tools and the browser decides what to call. The security model gets a lot harder when you're trusting random sites to define their", "context": "", "use_case": "agent tool integration", "switched_from": "", "story": "WebMCP is available for early preview"}]}, {"label": "Semantic layer", "summary": "Servers explain their API in natural language, and the protocol handles much of the common app plumbing.", "quotes": [{"id": 777494400, "item_id": 48593400, "url": "https://news.ycombinator.com/item?id=48593400", "by": "brookst", "date": "2026-06-18", "stance": "recommend", "quote": "I am a complete convert.", "excerpt": "I agree that having auth outside of context window is good. But the real value of MCP is adding a semantic layer on top of APIs. Skills are client side and don\u2019t know the server\u2019s capabilities. MCP lets the server explain its API in natural language so clients who have no prior knowledge of the server, it\u2019s API, or its domain can use it intelligently. I used to think MCP was dumb. I\u2019ve written to large MCP servers, o", "context": "has written large MCP servers", "use_case": "servers for CAD and music", "switched_from": "", "story": "Zero-Touch OAuth for MCP"}, {"id": 777493968, "item_id": 48593373, "url": "https://news.ycombinator.com/item?id=48593373", "by": "flashgordon", "date": "2026-06-18", "stance": "recommend", "quote": "So mcp is really an \"app framework\" than a protocol", "excerpt": "This is fantastic. Ive been so fortunate to work with the mcp folks last few months on a couple of the SEPs (and my own experimental sdk in go). I used to be a naysayer. \"Its just apis\" I used to say. \"Sheesh the invented another abstraction\" I used to say. What folks dont realize is it is the \"P\" in MCP that throws people off. When you build a traditional app you have to build forms, ui, req/response handling, bidir", "context": "contributes to MCP SEPs", "use_case": "app framework with unified auth", "switched_from": "", "story": "Zero-Touch OAuth for MCP"}]}, {"label": "Agent tooling", "summary": "Paired with tool search or code mode in agent harnesses, MCP is seen as the current way to go.", "quotes": [{"id": 777465744, "item_id": 48591609, "url": "https://news.ycombinator.com/item?id=48591609", "by": "thallavajhula", "date": "2026-06-18", "stance": "recommend", "quote": "it's back to Agent <> MCP now; couple that with tool search/code mode (whatever you want to call it) in your Agentic AI harness, MCPs seem to be the way to go for now.", "excerpt": "In the past 1 year, I think I've moved from MCP to A2A to Agent <> MCP back again. I have agents still talking to other Agents via A2A for some use cases, but for the most part, it's back to Agent <> MCP now; couple that with tool search/code mode (whatever you want to call it) in your Agentic AI harness, MCPs seem to be the way to go for now.", "context": "", "use_case": "agent tool integration", "switched_from": "", "story": "Ask HN: Is anyone using the A2A protocol yet?"}]}, {"label": "Local control", "summary": "Running local servers lets users choose trusted servers, see every tool call and deny anything suspicious.", "quotes": [{"id": 755475041, "item_id": 47217190, "url": "https://news.ycombinator.com/item?id=47217190", "by": "yuvrajangads", "date": "2026-03-02", "stance": "recommend", "quote": "the local tool-use model works well because I control both sides", "excerpt": "I've been using MCP with Claude Code for a while now (Google Maps, Swiggy, Figma servers) and the local tool-use model works well because I control both sides. I pick which servers to trust, I see every tool call, and I can deny anything sketchy. WebMCP flips that. The website exposes the tools and the browser decides what to call. The security model gets a lot harder when you're trusting random sites to define their", "context": "", "use_case": "agent tool integration", "switched_from": "", "story": "WebMCP is available for early preview"}]}], "caveats": [{"label": "Unnecessary abstraction", "summary": "Some argue CLIs, APIs and skills now do the job better, and that MCP carries baggage from earlier, less capable models.", "quotes": [{"id": 758201440, "item_id": 47387590, "url": "https://news.ycombinator.com/item?id=47387590", "by": "ArcaneMoose", "date": "2026-03-15", "stance": "warn", "quote": "I still think MCP is completely unnecessary (and have from the start).", "excerpt": "I still think MCP is completely unnecessary (and have from the start). The article correctly points out where CLI > MCP but stops short on 2 points: 1. Documenting the interface without MCP. This problem is best solved by the use of Skills which can contain instructions for both CLIs and APIs (or any other integration). Agents only load the relevant details when needed. This also makes it easy to customize the docs f", "context": "", "use_case": "agent tool integration", "switched_from": "", "story": "MCP Is Dead; Long Live MCP"}, {"id": 792959361, "item_id": 49559960, "url": "https://news.ycombinator.com/item?id=49559960", "by": "agentdev001", "date": "2026-09-04", "stance": "warn", "quote": "I'm frustrated to see that new projects on my team still consider MCP as a reasonable first pass solution", "excerpt": "I am not using MCP in be production- but, my team is. My team also produces MCP servers for other teams, and I find it a bit maddening. I wonder if anyone can relate to my experience here. It feels like there is a significant amount of baggage with MCP. It had first mover advantage- coming in at a time when the frontier looked much different. Models were significantly less predictable, would consistently screw up too", "context": "team produces MCP servers for other teams", "use_case": "giving agents tool access", "switched_from": "", "story": "Ask HN: Who is using MCP in production?"}]}, {"label": "Poor spec", "summary": "One commenter calls the specification poorly thought out and poorly communicated, with broken navigation links.", "quotes": [{"id": 770650384, "item_id": 48165649, "url": "https://news.ycombinator.com/item?id=48165649", "by": "epistasis", "date": "2026-05-16", "stance": "warn", "quote": "anybody involved with MCP's launch should be ashamed of what they put out there", "excerpt": "> Despite the fact that MCP is an utterly terrible attempt at a \"specification\", Can I just say that anybody involved with MCP's launch should be ashamed of what they put out there. I understand tool calling. I understand specs. I read MCP's \"spec\" and I used useless word salad that alternates between baby's first wire format and pie-in-the-sky marketing speak. Several of the navigation links I encountered were broke", "context": "", "use_case": "tool calling spec", "switched_from": "", "story": "MCP Hello Page"}]}, {"label": "Agent adoption", "summary": "Agents may not use MCP tools unless explicitly asked, with Claude preferring the shell.", "quotes": [{"id": 786886737, "item_id": 49180421, "url": "https://news.ycombinator.com/item?id=49180421", "by": "alexaholic", "date": "2026-08-05", "stance": "neutral", "quote": "MCP is nice, but does your agent use it without you explicitly asking it to do so?", "excerpt": "MCP is nice, but does your agent use it without you explicitly asking it to do so? From my experience, instructions in `.md` files aren't enough. In fact, Claude seems to prefer the shell over even its own built-in tools (e.g. `read`, `edit` etc.) See: https://github.com/anthropics/claude-code/issues/19649. It's like an old dog that needs to be tricked to learn new tricks.", "context": "", "use_case": "agent tool integration", "switched_from": "", "story": "Stateless MCP has recaptured my interest"}]}, {"label": "Performance, robustness", "summary": "Even supporters concede it is not performant, robust or uniform yet.", "quotes": [{"id": 798509840, "item_id": 49906865, "url": "https://news.ycombinator.com/item?id=49906865", "by": "_fw", "date": "2026-09-30", "stance": "recommend", "quote": "", "excerpt": "I appreciate their reluctance towards MCP, but /something/ is better than nothing. It\u2019s suboptimal for the reasons the author outlines: but so is USB-C. So is NVME, so is HDMI. We use these hugely successful technologies in spite of their flaws because they\u2019re widely compatible and easy for the end user. That\u2019s why MCP is everywhere. It might not be performant, robust and uniform but it WILL get better over time. And", "context": "", "use_case": "connecting LLMs to tools", "switched_from": "", "story": "You said no MCP"}]}], "who": [{"by": "brookst", "context": "has written large MCP servers", "url": "https://news.ycombinator.com/item?id=48593400", "date": "2026-06-18"}, {"by": "flashgordon", "context": "contributes to MCP SEPs", "url": "https://news.ycombinator.com/item?id=48593373", "date": "2026-06-18"}, {"by": "phpnode", "context": "building an app for non-developers", "url": "https://news.ycombinator.com/item?id=47208912", "date": "2026-03-01"}], "tags": ["for agent builders", "for apps for non-developers", "for Claude Code users", "for CAD and music workflows"], "use_cases": ["agent tool integration", "connecting llms to tools", "exposing internal tools to agents", "giving agents tool access", "cad, music production, slack, evals", "servers for cad and music"], "compared": [{"slug": "claude-code", "name": "Claude Code", "co": 5, "switched_from": 0, "switched_to": 0}, {"slug": "a2a", "name": "A2A", "co": 3, "switched_from": 0, "switched_to": 0}], "makers": [], "threads": [{"url": "https://news.ycombinator.com/item?id=48592163", "title": "Zero-Touch OAuth for MCP", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=49906637", "title": "You said no MCP", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49779329", "title": "MCP was always a bad idea?", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49548600", "title": "Ask HN: Who is using MCP in production?", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49399591", "title": "New MCP Roadmap", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49131438", "title": "Stateless MCP has recaptured my interest", "mentions": 1}], "sentiment_by_month": {"2025-11": {}, "2025-12": {}, "2026-01": {}, "2026-02": {}, "2026-03": {"recommend": 2, "warn": 1}, "2026-04": {}, "2026-05": {"warn": 1}, "2026-06": {"recommend": 3}, "2026-07": {}, "2026-08": {"neutral": 1, "recommend": 1}, "2026-09": {"warn": 1, "recommend": 2}, "2026-10": {}}, "quotes": [{"id": 798509840, "item_id": 49906865, "url": "https://news.ycombinator.com/item?id=49906865", "by": "_fw", "date": "2026-09-30", "stance": "recommend", "quote": "", "excerpt": "I appreciate their reluctance towards MCP, but /something/ is better than nothing. It\u2019s suboptimal for the reasons the author outlines: but so is USB-C. So is NVME, so is HDMI. We use these hugely successful technologies in spite of their flaws because they\u2019re widely compatible and easy for the end user. That\u2019s why MCP is everywhere. It might not be performant, robust and uniform but it WILL get better over time. And", "context": "", "use_case": "connecting LLMs to tools", "switched_from": "", "story": "You said no MCP"}, {"id": 796646352, "item_id": 49790397, "url": "https://news.ycombinator.com/item?id=49790397", "by": "rsolva", "date": "2026-09-21", "stance": "recommend", "quote": "MCP is exactly the lipstick we needed to put on our pigs", "excerpt": "MCP is exactly the lipstick we needed to put on our pigs, APIs that is not ours, but open source tools we use internally and also wanted to expose to our agents.", "context": "", "use_case": "exposing internal tools to agents", "switched_from": "", "story": "MCP was always a bad idea?"}, {"id": 792959361, "item_id": 49559960, "url": "https://news.ycombinator.com/item?id=49559960", "by": "agentdev001", "date": "2026-09-04", "stance": "warn", "quote": "I'm frustrated to see that new projects on my team still consider MCP as a reasonable first pass solution", "excerpt": "I am not using MCP in be production- but, my team is. My team also produces MCP servers for other teams, and I find it a bit maddening. I wonder if anyone can relate to my experience here. It feels like there is a significant amount of baggage with MCP. It had first mover advantage- coming in at a time when the frontier looked much different. Models were significantly less predictable, would consistently screw up too", "context": "team produces MCP servers for other teams", "use_case": "giving agents tool access", "switched_from": "", "story": "Ask HN: Who is using MCP in production?"}, {"id": 790407920, "item_id": 49400495, "url": "https://news.ycombinator.com/item?id=49400495", "by": "brookst", "date": "2026-08-22", "stance": "recommend", "quote": "I use MCP to accelerate CAD mould-making and for music production.", "excerpt": "I\u2019ll never understand the \u201cI\u2019ve never used it but am absolutely certain I would get zero value from it if I did\u201d mentality. I use MCP to accelerate CAD mould-making and for music production. I use it to avoid copying and pasting slack threads, and to let AI drive an eval system so I don\u2019t have to manually configure things in a UI. It\u2019s just hard to imagine both not using it and being so sure it has no use.", "context": "", "use_case": "CAD, music production, Slack, evals", "switched_from": "", "story": "New MCP Roadmap"}, {"id": 786886737, "item_id": 49180421, "url": "https://news.ycombinator.com/item?id=49180421", "by": "alexaholic", "date": "2026-08-05", "stance": "neutral", "quote": "MCP is nice, but does your agent use it without you explicitly asking it to do so?", "excerpt": "MCP is nice, but does your agent use it without you explicitly asking it to do so? From my experience, instructions in `.md` files aren't enough. In fact, Claude seems to prefer the shell over even its own built-in tools (e.g. `read`, `edit` etc.) See: https://github.com/anthropics/claude-code/issues/19649. It's like an old dog that needs to be tricked to learn new tricks.", "context": "", "use_case": "agent tool integration", "switched_from": "", "story": "Stateless MCP has recaptured my interest"}, {"id": 777494400, "item_id": 48593400, "url": "https://news.ycombinator.com/item?id=48593400", "by": "brookst", "date": "2026-06-18", "stance": "recommend", "quote": "I am a complete convert.", "excerpt": "I agree that having auth outside of context window is good. But the real value of MCP is adding a semantic layer on top of APIs. Skills are client side and don\u2019t know the server\u2019s capabilities. MCP lets the server explain its API in natural language so clients who have no prior knowledge of the server, it\u2019s API, or its domain can use it intelligently. I used to think MCP was dumb. I\u2019ve written to large MCP servers, o", "context": "has written large MCP servers", "use_case": "servers for CAD and music", "switched_from": "", "story": "Zero-Touch OAuth for MCP"}, {"id": 777493968, "item_id": 48593373, "url": "https://news.ycombinator.com/item?id=48593373", "by": "flashgordon", "date": "2026-06-18", "stance": "recommend", "quote": "So mcp is really an \"app framework\" than a protocol", "excerpt": "This is fantastic. Ive been so fortunate to work with the mcp folks last few months on a couple of the SEPs (and my own experimental sdk in go). I used to be a naysayer. \"Its just apis\" I used to say. \"Sheesh the invented another abstraction\" I used to say. What folks dont realize is it is the \"P\" in MCP that throws people off. When you build a traditional app you have to build forms, ui, req/response handling, bidir", "context": "contributes to MCP SEPs", "use_case": "app framework with unified auth", "switched_from": "", "story": "Zero-Touch OAuth for MCP"}, {"id": 777465744, "item_id": 48591609, "url": "https://news.ycombinator.com/item?id=48591609", "by": "thallavajhula", "date": "2026-06-18", "stance": "recommend", "quote": "it's back to Agent <> MCP now; couple that with tool search/code mode (whatever you want to call it) in your Agentic AI harness, MCPs seem to be the way to go for now.", "excerpt": "In the past 1 year, I think I've moved from MCP to A2A to Agent <> MCP back again. I have agents still talking to other Agents via A2A for some use cases, but for the most part, it's back to Agent <> MCP now; couple that with tool search/code mode (whatever you want to call it) in your Agentic AI harness, MCPs seem to be the way to go for now.", "context": "", "use_case": "agent tool integration", "switched_from": "", "story": "Ask HN: Is anyone using the A2A protocol yet?"}, {"id": 770650384, "item_id": 48165649, "url": "https://news.ycombinator.com/item?id=48165649", "by": "epistasis", "date": "2026-05-16", "stance": "warn", "quote": "anybody involved with MCP's launch should be ashamed of what they put out there", "excerpt": "> Despite the fact that MCP is an utterly terrible attempt at a \"specification\", Can I just say that anybody involved with MCP's launch should be ashamed of what they put out there. I understand tool calling. I understand specs. I read MCP's \"spec\" and I used useless word salad that alternates between baby's first wire format and pie-in-the-sky marketing speak. Several of the navigation links I encountered were broke", "context": "", "use_case": "tool calling spec", "switched_from": "", "story": "MCP Hello Page"}, {"id": 758201440, "item_id": 47387590, "url": "https://news.ycombinator.com/item?id=47387590", "by": "ArcaneMoose", "date": "2026-03-15", "stance": "warn", "quote": "I still think MCP is completely unnecessary (and have from the start).", "excerpt": "I still think MCP is completely unnecessary (and have from the start). The article correctly points out where CLI > MCP but stops short on 2 points: 1. Documenting the interface without MCP. This problem is best solved by the use of Skills which can contain instructions for both CLIs and APIs (or any other integration). Agents only load the relevant details when needed. This also makes it easy to customize the docs f", "context": "", "use_case": "agent tool integration", "switched_from": "", "story": "MCP Is Dead; Long Live MCP"}, {"id": 755475041, "item_id": 47217190, "url": "https://news.ycombinator.com/item?id=47217190", "by": "yuvrajangads", "date": "2026-03-02", "stance": "recommend", "quote": "the local tool-use model works well because I control both sides", "excerpt": "I've been using MCP with Claude Code for a while now (Google Maps, Swiggy, Figma servers) and the local tool-use model works well because I control both sides. I pick which servers to trust, I see every tool call, and I can deny anything sketchy. WebMCP flips that. The website exposes the tools and the browser decides what to call. The security model gets a lot harder when you're trusting random sites to define their", "context": "", "use_case": "agent tool integration", "switched_from": "", "story": "WebMCP is available for early preview"}, {"id": 755342592, "item_id": 47208912, "url": "https://news.ycombinator.com/item?id=47208912", "by": "phpnode", "date": "2026-03-01", "stance": "recommend", "quote": "MCP is going to be around for a long time, and we can expect it to get much better than it is today.", "excerpt": "I don't doubt that CLIs + skills are a good alternative to MCP in some contexts, but if you're building an app for non-developers and you need to let users connect it to arbitrary data sources there's really no sensible, safe path to using CLIs instead. MCP is going to be around for a long time, and we can expect it to get much better than it is today.", "context": "building an app for non-developers", "use_case": "connecting apps to data sources", "switched_from": "", "story": "MCP is dead. Long live the CLI"}]}