MCP Viewpoints — 4 KI-Kritiken

Generiert: 2026-04-14 | Framework: Feasibility / Review / Evaluation

Viewpoint 1 — Gemini 2.5 Flash (Google)

Perspektive: Enterprise End-User

## Feasibility

While MCP aims for a "USB-C for AI" standard, true enterprise-scale adoption faces significant hurdles. Standardized transports like stdio or HTTP+SSE are trivial, but the "data layer protocol" – JSON-RPC with primitives for tools, resources, and prompts – is where complexity explodes. Enterprises have deeply entrenched systems, bespoke authentication/authorization, and complex data governance. Implementing MCP servers for every legacy database, internal API, or data stream will require substantial wrapper development and maintenance, negating some of the "standardization" benefits. Real-time performance and strict SLA adherence across a federated MCP server landscape will be challenging to guarantee and monitor.

## Review

The primary weakness lies in its abstraction level. While aiming to simplify AI integration, it introduces another layer of abstraction over existing, mature API ecosystems. Enterprises are already heavily invested in direct API integrations, microservices, and robust SDKs. MCP's JSON-RPC primitives are generic, potentially leading to a "lowest common denominator" problem where rich API functionalities are awkwardly shoehorned. Security is a major concern: managing access controls and data leakage prevention for a multitude of MCP servers exposing internal systems to potentially external AI clients requires a robust, centralized policy enforcement mechanism, which MCP's current description doesn't explicitly address. Vendor lock-in, albeit at a lower layer, could also emerge if the standard evolves in non-neutral ways.

## Evaluation

MCP struggles against established alternatives. LangChain tools and native function calling (e.g., OpenAI, Anthropic) provide lightweight, model-specific integration points that are often sufficient for common use cases and easier to implement directly within model applications. These require less infrastructure overhead. Direct API integrations remain the gold standard for robust, high-performance, and secure enterprise solutions, offering full control and optimal utilization of system capabilities without an intermediary protocol. MCP feels like a solution seeking a problem already solved by more pragmatic, less opinionated approaches, or one that introduces too much overhead for the perceived simplification it offers. Its value proposition is diluted for any enterprise already having a mature API gateway strategy.

Viewpoint 2 — Kimi K2.5

Perspektive: Enterprise Production Engineer

## Feasibility

MCP's stdio transport is fundamentally unsuited for production—spawning processes per request doesn't scale. HTTP+SSE adds state management complexity that most infrastructure isn't designed for. The JSON-RPC layer introduces serialization overhead and error-handling nightmares at enterprise load. Stateful connections don't work well with serverless/containerized deployments where connections drop and resume unpredictably. Authentication and authorization are underspecified; enterprise IAM integration is an exercise left to the implementer. No built-in rate limiting, circuit breakers, or observability hooks means you're building production scaffolding yourself.

## Review

MCP conflates transport with semantics. Tool schemas are runtime-discovered but lack versioning—breaking changes are inevitable. Resource subscriptions (notifications) are overengineered; most use cases need polling, not push. The "prompts" primitive is underbaked—templating should be client-side, not server-exposed. Security model trusts the server too much: a compromised MCP server can exfiltrate context or execute arbitrary tools. No sandboxing primitives. Debugging is painful—stdio hides errors, SSE hides latency.

## Evaluation

LangChain tools are more mature with better ecosystem integration. Direct API calls are simpler and more debuggable—MCP adds indirection without clear value for single-client scenarios. Where MCP wins: multi-client scenarios where you want one tool backend serving Claude, Cursor, and internal apps. But that's a configuration management problem, not a protocol problem. Function calling (OpenAI/Anthropic native) has better type safety and is what models actually use—MCP is a translation layer that adds latency. If you're not building a platform serving multiple AI clients, skip MCP. Use it only if you're a tool vendor wanting distribution across many AI apps.

Viewpoint 3 — GLM-5.1

Perspektive: Enterprise Architect / Protocol Designer

## Feasibility

MCP works for single-user desktop workflows (Claude Desktop, VS Code). At enterprise scale it breaks: stdio transport is local-only, HTTP+SSE lacks multiplexing and connection pooling — every client holds a persistent SSE stream per server. No built-in auth framework (OAuth is "planned"), no rate limiting, no circuit breaking. Federation across trust boundaries is undefined. You're building production infra on a protocol that explicitly delegates auth to "the transport layer" — meaning you're on your own.

## Review

JSON-RPC over SSE is the wrong abstraction. SSE is unidirectional; server-to-client messages require a separate HTTP POST channel, creating dual-connection overhead and race conditions. No message ordering guarantees across channels. No binary framing — every payload is JSON, every tool call serializes/deserializes at line speed.

Three primitives that overlap. Tools, resources, and prompts sound clean but in practice: resources are just GET endpoints without caching semantics, prompts are template strings without a templating standard, and tools lack idempotency hints or timeout contracts. The spec is ~40 pages of capability negotiation for what amounts to glorified RPC.

No observability story. No tracing, no structured logging, no correlation IDs. When tool call #47 in a chain fails, you get a JSON-RPC error and nothing else.

## Evaluation

vs. Function calling (OpenAI/Anthropic APIs): MCP adds discovery and multi-server orchestration but at the cost of a full protocol stack — function calling is simpler for single-provider use cases.

vs. LangChain tools: LangChain owns the orchestration layer; MCP only standardizes the interface. You'll likely need both, which defeats the "one protocol" pitch.

vs. Direct API integration: Faster, type-safe, no negotiation overhead. MCP wins only when you need dynamic tool discovery across heterogeneous providers — which most enterprises don't.

Verdict: MCP is the right idea at the wrong layer. It should have been a tool schema registry, not a full transport protocol. Enterprise adoption requires auth, observability, and transport maturity that won't land before late 2026.

Viewpoint 4 — MiniMax M2.7

Perspektive: DevOps / Infrastructure Engineer

## Feasibility

MCP's stdio transport is a red flag for enterprise scale. Stdio assumes local process communication—fine for a dev workstation, problematic when you need distributed, fault-tolerant tool execution across a microservices mesh. The HTTP+SSE alternative exists but lacks the resilience patterns (retry queues, circuit breakers, service discovery) enterprises require. You'd be building significant plumbing on top of a protocol that solves the easy part of the integration problem.

The JSON-RPC 2.0 basis is sensible but low-level. At scale, you'll write substantial boilerplate for authentication, authorization, rate limiting, and observability—areas where mature API gateways and service meshes already have solved problems.

## Review

Tool discovery is shallow. MCP defines how to call tools, not how to negotiate capability intersections between client and server. In practice, you'll discover mismatches at runtime when a Claude session tries a tool your server doesn't advertise in that context.

Security model is underspecified. The spec punt on authnz—expected behavior is "transport-level security." In enterprise environments with zero-trust requirements, this is a significant gap. Compare to OpenAPI's OAuth2/PKI ecosystem.

Prompt primitive is ambiguous. "Canned interactions" is vague enough to be useless at design time. This will become a schema drift nightmare.

No versioning strategy. When a server updates its tool schema, clients get no signal. Production systems will encounter silent breakage.

## Evaluation

MCP is a well-intentioned abstraction that sits at the wrong layer. LangChain's tool abstraction is more pragmatic for AI-native workflows; function calling (OpenAI's tool use) is simpler for single-provider cases; direct API integrations offer enterprise controls. MCP's value is genuine as a client-side standard (VS Code ↔ data sources) rather than a cross-cutting enterprise integration layer. If you're Anthropic-centric and building Claude-centric workflows, it's viable. For heterogeneous multi-agent systems, it's premature.

Konsolidierte Schwachstellen-Karte

Thema	Alle 4 einig
Transport	stdio skaliert nicht, HTTP+SSE ist unzureichend für Enterprise
Auth/Authz	Protokoll adressiert es nicht, "left to implementer"
Observability	Keine Tracing/Logging/Correlation-IDs
Tool Versioning	Keine Schema-Evolution, Silent Breakage
Overhead	JSON-RPC + SSE + Abstraktion = zu viel für was es löst
Maturity	Production-ready für Desktop/Dev, nicht für Enterprise

Wann MCP sinnvoll ist

Tool Vendor Distribution (eine Backend, viele AI-Clients)
Anthropic-centric Claude Desktops/VS Code Workflows
Schnelle Prototypen mit dynamischer Tool-Discovery