Locara

Model Context Protocol (MCP)

What it is: An open protocol introduced by Anthropic in November 2024 for connecting AI applications to data sources and tools through a standardized interface. JSON-RPC 2.0 over stdio (subprocess) or HTTP+SSE. Three primitives: resources (read-only data), tools (callable functions), prompts (templates). Status: Rapidly became the de facto standard for AI↔tool integration. Adopted by Anthropic (Claude apps, Claude Code), OpenAI (Agents SDK), Cursor, Zed, Continue, and most serious agent tooling. Thousands of community MCP servers by mid-2025. Most relevant to Locara: Locara’s “tool” capability is essentially the local-execution sibling of MCP. This is the standard you must take an explicit position on.

Background

Anthropic published the MCP spec in November 2024 alongside reference implementations and a small library of canonical servers (filesystem, github, sqlite, postgres, slack, browser-puppeteer, etc.). The pitch was the “USB-C of AI” — a single protocol so any AI client could talk to any data source or tool, without N×M custom integrations.

Adoption was unusually fast for a proposed standard. Within six months, MCP was assumed in any serious agent stack: third-party clients (Cursor, Zed, Continue, Cline), competing AI vendors (OpenAI’s Agents SDK supports MCP servers as tools), and a Cambrian explosion of community servers covering everything from databases to design tools.

Key design decisions

  • JSON-RPC 2.0 transport. Stdio (subprocess, local-first by default) or HTTP+SSE (network).
  • Stateful sessions with explicit capability negotiation between client and server.
  • Three primitives, deliberately small:
    • Resources — read-only data the model can subscribe to (files, DB rows, calendar entries).
    • Tools — callable functions with JSON-Schema-typed args and side effects.
    • Prompts — server-provided template snippets users can invoke.
  • Server-driven capability declaration. The server lists what it can do; the client decides what to surface to the model.
  • No mandated authorization model in v1. OAuth 2.1 / Dynamic Client Registration was added in 2025 for HTTP transport.
  • Permissive license, open governance. Anthropic publishes the spec; SDKs in Python, TypeScript, Rust, Go, C#, Java, Kotlin (some official, some community).
  • Reference servers as exemplars — the official servers repo doubled as a tutorial for the protocol.

What worked

  • Standardization happened in months, not years. A combination of: clear spec, reference implementations, multiple SDKs, and a real customer (Claude Desktop) shipping it from day one.
  • Stdio + subprocess is dead-simple to implement. Lowers the bar for new servers to a handful of lines per primitive.
  • Server ecosystem exploded. Filesystem, git, github, slack, postgres, sqlite, puppeteer, custom-API wrappers, IDE bridges. Most are 200–500 lines each.
  • Transport-agnostic design lets local-first tools (stdio) and remote APIs (HTTP) coexist under one client interface.
  • Cross-vendor adoption. Both OpenAI and Anthropic clients consume the same servers. Rare for a competitor-introduced standard.
  • The “USB-C” framing landed — developers immediately understood the role MCP plays.

What failed / criticisms

  • Spec evolves quickly. Early servers broke as the protocol matured (notably around capability negotiation and the 2025 auth changes).
  • Tool descriptions are unstructured prose. The model relies on the server author’s English description of each tool. Quality varies wildly. Bad descriptions = bad tool selection.
  • No standard sandboxing. Stdio servers run as user-privileged subprocesses with full filesystem and network access by default. Security model is “trust the publisher.”
  • Discovery is ad-hoc. Multiple competing registries (smithery, mcp.so, etc.); no canonical one. Users find servers via Twitter and “awesome-mcp” lists.
  • Authorization for HTTP transport is still hardening. OAuth 2.1 + DCR is the spec but real-world deployments are inconsistent.
  • Token cost is real. Tool descriptions sit in every prompt. Servers with 50 tools eat thousands of tokens before the user message.
  • Permission scoping is per-server, not per-tool. Clients build their own per-tool permission UIs; not standardized.
  • State-management edge cases. Long-lived sessions, reconnection, server restarts — implementation quality varies.

Specific learnings for Locara

  1. MCP is not optional. Pick a position. Locara apps that talk to “tools” are MCP-shaped whether you call them that or not. Three coherent positions: (a) Locara consumes MCP — apps can use third-party MCP servers; (b) Locara apps expose MCP — apps appear as MCP servers to other clients; (c) both. Recommendation: both. The cost of not deciding is reinventing MCP poorly.
  2. Locara’s runtime is the missing sandbox layer. MCP’s most-cited weakness is that stdio servers are unsandboxed subprocesses. Locara’s wasmtime+WASI tool-execution capability solves exactly this. Pitch: “MCP servers, but actually safe — manifest-declared filesystem/network scope, kernel-enforced.” This is a real wedge.
  3. Stdio transport maps directly to Wasm tool execution. A Locara tool can be a Wasm module exposing the MCP protocol over stdio. Sandbox by default, capability declarations enforced, runs anywhere wasmtime runs. The substrate is already there.
  4. Discovery is unsolved — that’s the registry opening. No canonical MCP server registry has won. Locara’s curated catalog could carve a defensible niche: “the curated registry of safe MCP servers running in Wasm with declared capabilities.” Higher trust than smithery, more capable than the official Anthropic list.
  5. Don’t reinvent the protocol. Locara’s tool API surface should be MCP, not something MCP-adjacent. Inventing a parallel standard when MCP exists is the LangChain-of-2025 mistake.
  6. Manifest-declared capability scope is the missing complement to MCP descriptions. MCP says what tools exist; Locara’s manifest says what capabilities the tool actually needs. The manifest is enforceable; the description is not.
  7. OAuth 2.1 / DCR for HTTP transport — follow the spec. When Locara apps need to consume remote MCP servers (rare, but it’ll happen), use the standard auth flow. Don’t invent.
  8. Token efficiency is a Locara feature. The manifest can declare which tools are “always loaded” (in every prompt) vs “loaded on demand” (lazily described). MCP doesn’t address this; Locara can.
  9. Tool-description quality is a curation lever. Locara’s review can require well-structured tool descriptions, examples, and JSON-schema-typed args. Closes the most-cited MCP quality gap.

References