MCP (Model Context Protocol)

In short: An open protocol that lets an AI like Claude access external tools and data sources (files, APIs, apps) through a uniform channel, without a separate integration having to be written for every app.

In more detail: An MCP server offers “tools” (callable functions) via a standardised interface – the transport can be, e.g., stdio, SSE or Streamable HTTP. The client (here Claude Code) connects, receives a list of available tools, and then calls them like built-in tools.

Our context: Your Obsidian vault is connected via MCP – the “MCP Connector” plugin (istefox) starts a local MCP server in Obsidian (http://127.0.0.1:27200/mcp), which we registered in Claude Code with claude mcp add --transport http, authenticated with a bearer token.

In Depth

The three core building blocks

The three core building blocks an MCP server can offer a client like Claude: tools (callable functions with defined parameters, e.g. “read this file” or “send this message”), resources (readable data such as files or database entries that the client can fetch when needed, usually without side effects) and prompts (predefined, reusable prompt templates provided by the server so that users don’t have to phrase common requests anew each time). In practice, tools are by far the most used so far, since they give the model the greatest ability to act — resources and prompts are more of a supporting nature.

Why an open standard

The decisive advantage of MCP as an open standard: without it, every AI application would need its own tailor-made integration for every external app (one for Obsidian, one for Slack, one for GitHub, …) — with MCP, a single server provided by the respective app community can be used by ANY MCP-capable client, without the client vendor having to write that integration itself. This is comparable to the difference between proprietary charging cables and a uniform USB standard — before such a standard, every manufacturer had to ship its own cable for every device; afterwards, a single cable format is enough for practically everything.

Connection types (transports)

The transport determines HOW client and server actually exchange data. stdio (standard input/output) is suitable for locally running servers that the client starts itself as a subprocess — simple, but tied to the same machine. SSE (server-sent events) and Streamable HTTP, on the other hand, allow connections to remotely running servers over the network, including authentication (e.g. via a bearer token) — handy when the MCP server doesn’t run on the same device as the client but, for example, inside Obsidian as a locally running service reachable over HTTP.

Security aspects

Since an MCP server potentially gives the client far-reaching capabilities (file access, network access, executing actions in external apps), the question of WHICH servers you connect with WHICH permissions is security-relevant — a malicious or compromised MCP server could theoretically exfiltrate data or trigger unwanted actions. Reputable MCP clients therefore typically show which tools a newly connected server offers and let the user explicitly confirm individual, potentially risky actions (e.g. file deletions), instead of blindly giving the model free rein.

Origins

MCP was published by Anthropic as an open standard with the explicit goal of reducing fragmentation in AI tool integrations — similar to how the Language Server Protocol (LSP) earlier unified the integration of programming language support into different code editors, instead of every editor needing its own implementation for every language.

See also: Streamable HTTP, Bearer token, Obsidian vault, Protocol