Want smarter insights in your inbox? Sign up for our weekly newsletters to get only what matters to enterprise AI, data, and security leaders.<\/em> Subscribe Now<\/em><\/p>\n\n\n\n The Model Context Protocol (MCP) has become one of the most talked-about developments in AI integration since its introduction by Anthropic in late 2024. If you\u2019re tuned into the AI space at all, you\u2019ve likely been inundated with developer \u201chot takes\u201d on the topic. Some think it\u2019s the best thing ever; others are quick to point out its shortcomings. In reality, there\u2019s some truth to both.<\/p>\n\n\n\n One pattern I\u2019ve noticed with MCP adoption is that skepticism typically gives way to recognition: This protocol solves genuine architectural problems that other approaches don\u2019t. I\u2019ve gathered a list of questions below that reflect the conversations I\u2019ve had with fellow builders who are considering bringing MCP to production environments.\u00a0<\/p>\n\n\n\n Of course, most developers considering MCP are already familiar with implementations like OpenAI\u2019s custom GPTs, vanilla function calling, Responses API with function calling, and hardcoded connections to services like Google Drive. The question isn\u2019t really whether MCP fully replaces <\/em>these approaches \u2014 under the hood, you could absolutely use the Responses API with function calling that still connects to MCP. What matters here is the resulting stack.<\/p>\n\n\n\n Despite all the hype about MCP, here\u2019s the straight truth: It\u2019s not a massive technical leap. MCP essentially \u201cwraps\u201d existing APIs in a way that\u2019s understandable to large language models (LLMs). Sure, a lot of services already have an OpenAPI spec that models can use. For small or personal projects, the objection that MCP \u201cisn\u2019t that big a deal\u201d is pretty fair.<\/p>\n\n\n\n The AI Impact Series Returns to San Francisco – August 5<\/strong><\/p>\n\n\n\n The next phase of AI is here – are you ready? Join leaders from Block, GSK, and SAP for an exclusive look at how autonomous agents are reshaping enterprise workflows – from real-time decision-making to end-to-end automation.<\/p>\n\n\n\n Secure your spot now – space is limited: https:\/\/bit.ly\/3GuuPLF<\/p>\n\n\n\n The practical benefit becomes obvious when you\u2019re building something like an analysis tool that needs to connect to data sources across multiple ecosystems. Without MCP, you\u2019re required to write custom integrations for each data source and each LLM you want to support. With MCP, you implement the data source connections once<\/em>, and any compatible AI client can use them.<\/p>\n\n\n\n This is where you really start to see the gap between reference servers and reality. Local MCP deployment using the stdio programming language is dead simple to get running: Spawn subprocesses for each MCP server and let them talk through stdin\/stdout. Great for a technical audience, difficult for everyday users.<\/p>\n\n\n\n Remote deployment obviously addresses the scaling but opens up a can of worms around transport complexity. The original HTTP+SSE approach was replaced by a March 2025 streamable HTTP update, which tries to reduce complexity by putting everything through a single \/messages endpoint. Even so, this isn\u2019t really needed for most companies that are likely to build MCP servers.<\/p>\n\n\n\n But here\u2019s the thing: A few months later, support is spotty at best. Some clients still expect the old HTTP+SSE setup, while others work with the new approach \u2014 so, if you\u2019re deploying today, you\u2019re probably going to support both. Protocol detection and dual transport support are a must.<\/p>\n\n\n\n Authorization is another variable you\u2019ll need to consider with remote deployments. The OAuth 2.1 integration requires mapping tokens between external identity providers and MCP sessions. While this adds complexity, it\u2019s manageable with proper planning.<\/p>\n\n\n\n This is probably the biggest gap between the MCP hype and what you actually need to tackle for production. Most showcases or examples you\u2019ll see use local connections with no authentication at all, or they handwave the security by saying \u201cit uses OAuth.\u201d\u00a0<\/p>\n\n\n\n The MCP authorization spec does <\/em>leverage OAuth 2.1, which is a proven open standard. But there\u2019s always going to be some variability in implementation. For production deployments, focus on the fundamentals:\u00a0<\/p>\n\n\n\n However, the biggest security consideration with MCP is around tool execution itself. Many tools need (or think<\/em> they need) broad permissions to be useful, which means sweeping scope design (like a blanket \u201cread\u201d or \u201cwrite\u201d) is inevitable. Even without a heavy-handed approach, your MCP server may access sensitive data or perform privileged operations \u2014 so, when in doubt, stick to the best practices recommended in the latest MCP auth draft spec.<\/p>\n\n\n\n This gets to the heart of any adoption decision: Why should I bother with a flavor-of-the-quarter protocol when everything AI is moving so fast? What guarantee do you have that MCP will be a solid choice (or even around) in a year, or even six months?\u00a0<\/p>\n\n\n\n Well, look at MCP\u2019s adoption by major players: Google supports it with its Agent2Agent protocol, Microsoft has integrated MCP with Copilot Studio and is even adding built-in MCP features for Windows 11, and Cloudflare is more than happy to help you fire up your first MCP server on their platform. Similarly, the ecosystem growth is encouraging, with hundreds of community-built MCP servers and official integrations from well-known platforms.\u00a0<\/p>\n\n\n\n In short, the learning curve isn\u2019t terrible, and the implementation burden is manageable for most teams or solo devs. It does what it says on the tin. So, why would I be cautious about buying into the hype?<\/p>\n\n\n\n MCP is fundamentally designed for current-gen AI systems, meaning it assumes you have a human supervising a single-agent interaction. Multi-agent and autonomous tasking are two areas MCP doesn\u2019t really address; in fairness, it doesn\u2019t really need to. But if you\u2019re looking for an evergreen yet still somehow bleeding-edge approach, MCP isn\u2019t it. It\u2019s standardizing something that desperately needs consistency, not pioneering in uncharted territory.<\/p>\n\n\n\n Signs are pointing toward some tension down the line for AI protocols. While MCP has carved out a tidy audience by being early, there\u2019s plenty of evidence it won\u2019t be alone for much longer.<\/p>\n\n\n\n Take Google\u2019s Agent2Agent (A2A) protocol launch with 50-plus industry partners. It\u2019s complementary to MCP, but the timing \u2014 just weeks after OpenAI publicly adopted MCP \u2014 doesn\u2019t feel coincidental. Was Google cooking up an MCP competitor when they saw the biggest name in LLMs embrace it? Maybe a pivot was the right move. But it\u2019s hardly speculation to think that, with features like multi-LLM sampling soon to be released for MCP, A2A and MCP may become competitors.<\/p>\n\n\n\n Then there\u2019s the sentiment from today\u2019s skeptics about MCP being a \u201cwrapper\u201d rather than a genuine leap forward for API-to-LLM communication. This is another variable that will only become more apparent as consumer-facing applications move from single-agent\/single-user interactions and into the realm of multi-tool, multi-user, multi-agent tasking. What MCP and A2A don\u2019t address will become a battleground for another breed of protocol altogether.<\/p>\n\n\n\n For teams bringing AI-powered projects to production today, the smart play is probably hedging protocols. Implement what works now while designing for flexibility. If AI makes a generational leap and leaves MCP behind, your work won\u2019t suffer for it. The investment in standardized tool integration absolutely will pay off immediately, but keep your architecture adaptable for whatever comes next.<\/p>\n\n\n\n Ultimately, the dev community will decide whether MCP stays relevant. It\u2019s MCP projects in production, not specification elegance or market buzz, that will determine if MCP (or something else) stays on top for the next AI hype cycle. And frankly, that\u2019s probably how it should be.<\/p>\n\n\n\n Meir Wahnon is a co-founder at Descope.<\/em><\/p>\n\n\n\n\n Daily insights on business use cases with VB Daily<\/strong><\/p>\n If you want to impress your boss, VB Daily has you covered. We give you the inside scoop on what companies are doing with generative AI, from regulatory shifts to practical deployments, so you can share insights for maximum ROI.<\/p>\n \n\t\t\t\t\tThanks for subscribing. Check out more VB newsletters here.\n\t\t\t\t<\/p>\n An error occured.<\/p>\n<\/p><\/div>\n
\n<\/div>1. Why should I use MCP over other alternatives?<\/h2>\n\n\n\n
\n\n\n\n
\n<\/div>2. Local vs. remote MCP deployment: What are the actual trade-offs in production?<\/h2>\n\n\n\n
3. How can I be sure my MCP server is secure?<\/h2>\n\n\n\n
\n
4. Is MCP worth investing resources and time into, and will it be around for the long term?<\/h2>\n\n\n\n
5. Are we about to witness the \u201cAI protocol wars?\u201d<\/h2>\n\n\n\n
![\"\"\/](\"https:\/\/venturebeat.com\/wp-content\/themes\/vb-news\/brand\/img\/vb-daily-phone.png\")
\n\t\t\t\t<\/div>\n<\/p><\/div>\n<\/div>\t\t\t<\/div>\r\n