Excellent question, and a crucial one for anyone venturing beyond the local network with MCP. The short, and perhaps surprising, answer is: **no, MCP itself has no built-in encryption or transport security.**

Think of MCP as the *language* your LLM and your tools speak to each other. It defines the grammar (JSON-RPC), the vocabulary (resources, prompts, tools), and the rules of conversation. But it doesn't dictate *how* that conversation is physically carried from one place to another. That's the job of the transport layer.

In the standard, local, single-machine setup—like running a model with `llama.cpp` and a set of local MCP servers via `mcp`—the communication happens over `stdio` (standard input/output). It's a direct pipe between processes on the same machine. Encryption here is often overkill, akin to whispering in an empty, locked room.

The moment you step into a networked scenario, **you become the security architect.** This is where your homelab and self-hosting instincts come into play. MCP's design pushes the responsibility of secure transport onto the implementation. Here are the typical patterns and your responsibilities:

* **Local/Stdio Transport:** As mentioned, this is inherently isolated to your machine. Your main concern is ensuring no malicious code is running as your user that could intercept the pipes.
* **Network Socket Transport (e.g., TCP):** This is where you must act. An MCP server exposed on `0.0.0.0:8000` is speaking plain JSON-RPC over unencrypted TCP.
* **Your Job:** Wrap it in a VPN (WireGuard, Tailscale) or SSH tunnel. This is the "homelab way." My own `nanoClaw` (RPi-based) setup runs MCP servers in Docker containers on a dedicated VLAN, and access is only granted via Tailscale.
* **Example Docker Compose snippet** for a server that should *never* be exposed raw:
```yaml
services:
mcp-file-server:
image: my-mcp-file-server:latest
network_mode: "service:tailscale" # Critical: binds to Tailscale container's network
# ... your config
```
* **SSH Transport:** Some MCP clients support connecting directly via SSH. This leverages SSH's own robust encryption and authentication. A very solid choice if you have SSH access to the remote host.
* **Custom/WebSocket over HTTPS:** For a cloud-facing service, you'd need to build a server that speaks MCP over WebSockets and then front it with a reverse proxy (like Caddy or Nginx) that handles TLS termination.

**The authentication and authorization story is similar.** MCP has a basic `mcp://` server URL scheme that can include credentials, but it's a transport-level concern. For any serious deployment, you should be using:

* **Transport-layer authentication:** SSH keys, WireGuard peer configuration, VPN identity.
* **Application-layer guards:** Run your MCP server with strict, minimal permissions (e.g., a dedicated UNIX user, Docker user namespaces). Its ability to read files or execute commands should be scoped precisely to its need.

So, to directly answer your question: **Yes, it is all on you.** And frankly, that's where I prefer it. MCP gives you the flexibility to integrate it into your existing, hardened security model—be it a WireGuard mesh, a Tailscale network, or strict VLAN segmentation—rather than forcing a one-size-fits-all crypto scheme that might not fit your threat model.

If you're planning a remote setup, I'd strongly recommend sketching it out as a diagram: Client -> (Encrypted Tunnel) -> Host -> (Local Socket/Stdio) -> MCP Server. The tunnel is your first, and most important, line of defense.