Locara

38 — Model Context Protocol (MCP) Compatibility

The Model Context Protocol (MCP) is Anthropic’s open standard for connecting LLMs to data sources and tools. As of 2025–2026 it’s becoming the de-facto interop layer between LLM clients (Claude Desktop, Cursor, Continue, etc.) and external context (servers exposing files, databases, APIs).

This document specifies how Locara should and should not engage with MCP.

Why this matters for Locara

Two opposite ways MCP intersects with the project:

  1. Locara apps could BE MCP clients. A Locara app’s LLM could connect to MCP servers to access data outside the app. (Pro: rich ecosystem of existing MCP servers. Con: each MCP server is potentially network-using and breaks the local-first thesis unless the server itself is local.)
  2. Locara apps could EXPOSE MCP servers. A Locara app’s data could be available to other LLMs (e.g., Claude Desktop) via MCP. (Pro: makes Locara apps valuable beyond Locara. Con: exposes app data to external clients, conflicts with capability isolation unless explicit.)

Both are interesting; both have implications for the trust model.

What MCP is, briefly

MCP is a JSON-RPC-based protocol where:

  • An MCP server exposes “resources” (data the LLM can read) and “tools” (functions the LLM can call).
  • An MCP client (LLM-driven app) connects to one or more servers and lets the LLM use them mid-conversation.
  • Servers run locally (stdio transport) or over network (SSE transport).
  • The protocol handles authentication, capability negotiation, content streaming.

It’s open, language-agnostic, and reasonably mature.

Locara’s stance

(committed) v1 ships with Locara apps as MCP clients (local servers only) and as MCP servers (opt-in). Specifically:

  • Locara apps can declare tools.mcp capability and connect to local-only MCP servers (stdio transport, no network).
  • Locara apps can expose their data as MCP servers, gated by an explicit capability and user consent.
  • Network-using MCP servers are gated by the standard net capability (with user warning).

This makes Locara apps interoperable with the broader MCP ecosystem without breaking the local-first thesis.

Locara apps as MCP clients

Capability declaration

"capabilities": {
  "tools": {
    "mcp": {
      "local_servers": ["filesystem", "git", "memory"]
    }
  }
}

Each entry is the name of an MCP server known to Locara — either:

  • A bundled Locara MCP server (filesystem, git, memory, etc. — Locara curates a small set).
  • A user-installed MCP server in ~/.locara/mcp-servers/ (advanced; tracked + signed).

Local stdio transport only

The runtime starts MCP servers as subprocesses with stdio transport. No network MCP servers in v1. This preserves the local-first guarantee.

If an app wants a network MCP server, it must declare net capability with the appropriate hosts; the runtime then permits it but the app loses the “fully local” badge.

How an app uses MCP

import { llm, mcp } from '@locara/sdk'

// Connect to declared MCP servers
const fs = await mcp.connect('filesystem', { root: '~/Documents/research' })
const git = await mcp.connect('git', { repo: '~/Code/myproject' })

// Provide MCP context to LLM
const response = await llm.chat({
  model: 'qwen2.5-7b-q4',
  messages: [...],
  mcp: [fs, git],  // The LLM can call MCP tools or read MCP resources
})

The runtime mediates all calls. Capability checks apply to MCP tool invocations the same way they apply to native Locara tools.

Available bundled MCP servers (v1)

A small curated set:

  • filesystem — read user-selected directories. Subject to fs capability.
  • git — read git repos. Subject to fs capability.
  • memory — simple key-value memory across sessions. Subject to fs.app-data.
  • sqlite — query SQLite databases (the app’s own or user-selected). Subject to fs.
  • fetch — fetch HTTP resources. Subject to net capability with allowlist.

Each is implemented as a small Wasm or signed Rust binary. Updates to the curated set follow the same review process as tools.

Locara apps as MCP servers

Why expose

Locara apps accumulate valuable structured data (transcripts, indexed documents, custom knowledge bases). Exposing this via MCP means:

  • A user’s Claude Desktop or Cursor could ask questions across their Locara apps’ data.
  • Cross-app workflows without depending on Locara-specific IPC.

Capability + consent

"capabilities": {
  "expose_mcp": {
    "transport": "stdio",
    "consumers": ["any" | "specific:<app-id>"]
  }
}

Default: off. Apps don’t expose MCP servers unless the manifest declares it.

When declared, the user sees explicit consent at install:

Transcribe wants to expose your transcripts via MCP.
This means other apps (like Claude Desktop) you allow can read them.
You'll be asked to approve each consumer the first time it connects.

[Allow]  [Deny]

Transport options

  • stdio: local clients only. Most secure.
  • localhost socket: allows connections from the same machine (e.g., Claude Desktop).
  • network: requires net capability. Discouraged for v1.

Default: stdio + localhost socket (so Claude Desktop on the same Mac can connect).

What apps can expose

  • Read access to declared resources.
  • Tool invocations limited to a per-app allowlist.
  • No write access without per-call user confirmation.
  • Subject to all capability checks (an MCP-exposed tool that wants net requires the app declare net).

Trust model under MCP

The composition rule from 04-modalities.md applies:

  • An MCP server cannot exceed its host app’s capabilities. If the app declares fs.user-selected: "read", the MCP server it exposes can also only read user-selected files.
  • An MCP client app cannot exceed its declared MCP servers. If it only declared tools.mcp.local_servers: ["filesystem"], it cannot suddenly connect to “git.”
  • Network MCP servers require net capability declaration; same rules as any other network use.

The static analyzer (31-capability-analyzer.md) verifies these compositions.

MCP server registry

Locara curates a small set of bundled MCP servers (above). For third-party MCP servers:

  • Registered with Locara via a separate registry.
  • Reviewed for security like apps.
  • Signed; users install via standard download (same flow as Locara apps themselves).
  • Listed under ~/.locara/mcp-servers/ with manifest of capabilities.

The bigger MCP server ecosystem (npm packages, GitHub repos) is NOT directly trusted. Users who want to use those install via the standard MCP setup outside Locara, but those servers cannot be invoked from Locara apps without being registered.

When NOT to use MCP

Native Locara primitives (SDK calls like llm.chat, db.query, fs.pick) should be preferred when possible. MCP is for:

  • Connecting to external standardized services.
  • Exposing your app’s data to other LLM clients (Claude Desktop, Cursor).
  • Reusing existing MCP server implementations rather than reinventing.

For purely intra-app needs, the SDK is simpler and integrates better with the capability system.

Performance considerations

MCP adds a JSON-RPC roundtrip per call. For tight inference loops, this can matter:

  • A native Locara tool: sub-millisecond invocation.
  • An MCP tool over stdio: milliseconds.
  • An MCP tool over network: tens to hundreds of ms.

Apps that need many calls per second should prefer native Locara tools; apps that need flexible interop should use MCP.

Future considerations

  • MCP standardization on capability declarations. If the MCP spec evolves to include capability metadata, Locara’s analyzer can read it directly. We track upstream.
  • Locara apps published as standalone MCP servers. A Locara app could double as a standalone MCP server distributed outside the Locara ecosystem. Out of scope for v1; reasonable v2 feature.
  • MCP Resources for model artifacts. Could models be served via MCP between Locara apps? Probably yes; we already content-address them.

Open questions

  • (open) Should the bundled MCP servers ship in the framework or be installed as separate signed packages? Separate packages keep the framework small; bundled keeps the install flow simpler.
  • (open) When a Locara app exposes MCP, should the consumer (e.g., Claude Desktop) be required to be Locara-signed too? Probably no — interop with anything is the value — but there should be a clear “external app connected” signal.
  • (open) Schema versioning for MCP resources/tools — track upstream MCP spec evolution.
  • (open) MCP server installation flow needs design (is it like installing a Locara app? a separate registry?).

Cross-references