Skip to content

MCP servers

MCP, the Model Context Protocol, is an open standard for exposing tools to a language model. Point Smart Second Brain at an MCP server and its tools appear alongside the agent’s built-in ones.

This is how the agent reaches things that aren’t in your vault: an issue tracker, a database, a calendar, a service running on your own machine.

MCP servers are configured per agent, in the Agent editor. A research agent can carry a web-heavy server set while your everyday note agent carries none.

Servers are reached over HTTP (Streamable HTTP, falling back to SSE for older servers). The same configuration works on desktop and mobile.

Field Example
Name My MCP Server
Server URL https://mcp.example.com/mcp
Headers Authorization: Bearer token, one per line

Pasting a server’s published JSON config (the mcpServers block from its README, or a VS Code servers entry) into any field fills the form for you. Test connection lists the tools the server offers before you save.

The handshake happens on the agent’s first run and its tools are cached for that agent. Concurrent runs share one in-flight handshake rather than each opening their own.

If the handshake fails, the failure is not cached. The plugin retries on the next run rather than leaving the agent toolless for the whole session. The error is logged. Check the developer console if a server’s tools never appear.

Editing an agent’s server list clears its cache, so changes take effect on the next run without a restart.

They solve different problems, and the answer is usually a skill.

Reach for a skill when the capability already exists in the vault or in another Obsidian plugin. It’s a file, it’s version-controlled with your notes, and it costs nothing at rest.

Reach for MCP when the capability lives in a genuinely external system that needs credentials, a network connection, or a running service.