Model Context Protocol

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.