In this post, I’d like to share some thoughts on the **Model Context Protocol (MCP)** and compare two types of server integration methods it supports—**STDIO** and **SSE**, especially from the security perspective.
## Quick Recap: What is MCP?
- **Model Context Protocol (MCP)** is a new standard for integrating external tools with AI chat applications. For example, you can add Google Search as an MCP server to Claude Desktop, allowing the LLM to perform live searches to improve its responses. In this case, Claude Desktop is the *MCP Host*.
There are two common types of MCP server transports:
- **STDIO Transport**: The MCP server runs locally on the same machine as the MCP Host. Users download a small application (the MCP server), install it, and configure the MCP Host to communicate with it via standard input/output.
- **SSE Transport**: The MCP server runs as a network service, typically on a remote server (but it can also be on `localhost`). It's essentially a special kind of website that the MCP Host connects to via Server-Sent Events (SSE).
## The Current Situation
Most MCP servers available today use **STDIO transport**. These are often small scripts or programs written in various programming languages and meant to be installed and run locally. There's a bit of a "community competition" going on—developers building interesting MCP servers to integrate with different tools.
However, most MCP Hosts (e.g., Claude Desktop) **only support STDIO**. Some platforms offer limited SSE support, but often lack features like configurable security headers.
## How to Choose the Right Transport for Your MCP Server
Here are some factors to consider:
### 1. Who Is the User?
- **Technically Experienced Users**: Typically developers or power users who use AI tools to boost productivity. They can install and run local MCP servers and even inspect the code for security risks.
- **Ordinary Users**: These users rely on MCP servers for practical help (e.g., Excel assistants) but aren’t equipped to assess the safety of local scripts or programs.
### 2. What Is Being Integrated?
- **Local Integrations**: Tools or services that run on the same machine—like local databases, MS Excel, or music players.
- **Cloud/Remote Integrations**: Services that live on the web—Google Search, messaging apps, Google Drive, etc.
### Recommended Guidelines
Based on this, here are my personal recommendations:
- **If your MCP server integrates with a cloud-based service (SaaS)**, then **use SSE transport** and host it as a secure remote service.
- **If your MCP server integrates a local application and targets ordinary users**, it should come from a **trusted source**—either as an official component of the MCP Host or distributed by a reputable vendor (e.g., Microsoft for MS Office integrations).
- **MCP servers published as standalone scripts or programs** should be intended only for **technically skilled users** who can verify the source code and its safety.
## A Word About Security
### STDIO: A Real Concern
In its current form, **STDIO transport has serious security flaws**.
Here's a real-world example: I visited one of the MCP server directories—[https://www.mcpinstall.com](https://www.mcpinstall.com)—and clicked on a random server. The installation instructions were:
**MacOS/Linux:**
```bash
curl -LsSf https://astral.sh/uv/install.sh | sh
```
**Windows:**
```powershell
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
```
**What?!** We're piping and executing scripts directly from the internet with **zero validation**. I wouldn't recommend doing this—ever.
> _Disclaimer: I have nothing against [mcpinstall.com](https://www.mcpinstall.com) or any listed MCP servers. This is just an example of a broader issue._
We either need to:
- Move most MCP server development to **SSE transport**, **or**
- Create a **trusted, community-managed repository** that verifies and certifies MCP servers.
### SSE: Easier to Secure
SSE transport is naturally better suited for secure integrations. All it needs is **authorization support**—for example, **authorization tokens** passed in headers. That's usually enough.
If you’re interested in how to implement authentication for SSE-based MCP servers in Go or Python, check out my blog post here:
👉 [Implementing Authentication in a Remote MCP Server with SSE Transport](/blog/post/implementing-authentication-in-a-remote-mcp-server-with-sse-transport/)
## Final Thoughts
Choosing between STDIO and SSE transport for your MCP server depends largely on your target audience and the nature of your integration. STDIO may still be the only viable option for certain local use cases, especially given current MCP Host limitations—but it comes with significant security risks that can't be ignored. SSE offers a more secure and scalable path, especially for cloud-based services, and should be the preferred option moving forward. As the MCP ecosystem matures, we should aim for better standards, trusted repositories, and broader SSE support to ensure that powerful integrations don’t come at the cost of user safety.
