Model Context Protocol

Original Article ↗ Hacker News Discussion ↗

Anthropic’s Model Context Protocol (MCP) aims to standardize how AI applications connect to external tools and data sources, so any LLM client can talk to any “context server” (for filesystems, databases, GitHub, Slack, etc.) through a common interface. Early adopters see it as an “LSP for LLMs” that could reduce today’s fragmented, bespoke integrations, but many find the spec and tooling immature, with confusing documentation and open questions around transports, authentication, security, and handling large or sensitive data. A recurring theme is whether MCP can gain enough cross-vendor adoption—and stay model-agnostic—before dominant players like OpenAI push competing approaches.

What MCP Is Trying to Solve

  • Described as “LSP for LLMs,” “ODBC for AI,” or a standardized plugin layer for LLM apps.
  • Main goal: solve the N×M integration problem between many LLM clients (chat apps, IDEs, agents) and many tools/data sources.
  • Provides common primitives: tools, resources (read-only context like schemas/files), prompts (prebuilt prompt snippets), and transports (stdio, SSE, etc.).
  • Intended to be model-agnostic and usable by any LLM application, not only Claude.

Current Usage & Examples

  • Common demos: connect local databases, file systems, Git/GitHub, Slack, Google Drive, Postgres, Puppeteer, YouTube, etc.
  • Users report using it to:
    • Let Claude (or other clients) explore DB schemas and generate ORM layers.
    • Summarize YouTube videos via a custom MCP server.
    • Drive browsers with Puppeteer.
    • Integrate with code editors like Zed and Cody, and custom shell/CLI agents.

Clients, Servers, and Architecture

  • Architecture: host (LLM app) ↔ client (user-facing mediator) ↔ server (integration talking to external system).
  • Claude Desktop currently the primary general-purpose client; web Claude.ai does not yet support MCP.
  • Zed editor and Sourcegraph’s Cody already integrate as MCP clients.
  • SDKs exist for TypeScript and Python on both client and server sides; Python client is labeled more experimental.

Security, Permissions, and Auth

  • Current UX emphasizes safety: per-tool, per-server permission prompts; no permanent global approval in Claude Desktop.
  • Concerns raised about:
    • Accidental data exfiltration (e.g., querying entire DBs).
    • Lack of standardized auth/identity for multi-user/enterprise use; today credentials are often in local config.
    • Risk that exposed JSON-RPC servers become attack vectors if misconfigured.
  • Remote/SaaS MCP and standardized auth are acknowledged as “not fully solved yet.”

Critiques, Confusion, and Open Questions

  • Many ask why MCP is needed versus:
    • Plain tool/function calling, OpenAPI/Swagger, GraphQL, or existing frameworks like LangChain.
  • Some see MCP as merely reshaping, not eliminating, the N×M problem (now N MCP clients × M MCP servers).
  • Several find documentation confusing, especially definitions of “context,” client/host/server roles, and advanced concepts like “sampling.”
  • Questions about:
    • How business logic fits vs. raw DB access.
    • How to differentiate read-only vs mutating tools for approval flows.
    • How embeddings/RAG and large datasets interact with MCP (often unclear or “outside” the protocol).

Ecosystem & Adoption Concerns

  • Enthusiasm for an open protocol and community-built integrations; some teams plan to adopt immediately.
  • Skepticism that it will matter unless other major model vendors (OpenAI, Google, Microsoft, Meta, etc.) adopt or compatible shims appear.
  • Some distrust any single-vendor “open” standard without broader governance, but note everything is MIT-licensed and already used beyond Claude.