feat(content): 11 new SEO/GEO guide articles with per-article OG images
How-to cluster: create-mcp-server-without-code, claude-desktop-mcp-setup, chatgpt-mcp-connector (incl. honest Business/Enterprise write-connector plan limits), rest-api-to-mcp-server. Comparison cluster: mcp-server-hosting-pricing (5-platform matrix), composio-alternative, smithery-alternative — house style: explicitly state where competitors win. Technical/GEO cluster: mcp-transports-explained (SSE deprecation 2025-03-26), mcp-oauth-plain-english, mcp-server-security-checklist, and German DACH article mcp-server-ohne-code-erstellen (articleJsonLd gained optional inLanguage param). Every article: pageMetadata canonical, Article JSON-LD with Person author + image + wordCount, BreadcrumbList, FAQPage where applicable, 1200x630 OG image via shared helper, internal linking. Registry entries in lib/articles.ts feed guides index, sitemap and RSS automatically. Product claims sourced only from lib/seo.ts truth — no invented customers, SLAs or certifications. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SXUwmPVRTD8AKQtio6gCN5
This commit is contained in:
Marco Sadjadi
@@ -0,0 +1,13 @@
|
||||
import { articleOgImage, OG_SIZE } from '@/lib/og-article';
|
||||
|
||||
export const runtime = 'edge';
|
||||
export const alt = 'MCP transports explained: stdio vs SSE vs Streamable HTTP';
|
||||
export const size = OG_SIZE;
|
||||
export const contentType = 'image/png';
|
||||
|
||||
export default function Image() {
|
||||
return articleOgImage({
|
||||
title: 'MCP transports explained: stdio vs SSE vs Streamable HTTP',
|
||||
tag: 'Explainer',
|
||||
});
|
||||
}
|
||||
@@ -0,0 +1,206 @@
|
||||
import { JsonLd } from '@/components/json-ld';
|
||||
import { StaticCodeBlock } from '@/components/static-code-block';
|
||||
import { articleJsonLd, breadcrumbJsonLd, faqJsonLd, pageMetadata } from '@/lib/seo';
|
||||
import Link from 'next/link';
|
||||
import { ArticleShell, H2, Note, P, Strong, Table, UL } from '../article-shell';
|
||||
|
||||
const PATH = '/guides/mcp-transports-explained';
|
||||
const TITLE = 'MCP transports explained: stdio vs SSE vs Streamable HTTP';
|
||||
const DESCRIPTION =
|
||||
'What each MCP transport actually is, why the spec deprecated HTTP+SSE in favor of Streamable HTTP, and which transport to pick for local tools, remote servers and serverless deployments.';
|
||||
|
||||
export const metadata = pageMetadata({ title: TITLE, description: DESCRIPTION, path: PATH });
|
||||
|
||||
const TRANSPORT_FAQ = [
|
||||
{
|
||||
q: 'Is SSE deprecated in MCP?',
|
||||
a: 'Yes. The HTTP+SSE transport from protocol version 2024-11-05 was replaced by Streamable HTTP in spec revision 2025-03-26. Servers may keep SSE endpoints for backward compatibility, but client support is degrading and platforms have been removing it through 2026.',
|
||||
},
|
||||
{
|
||||
q: 'What is the difference between Streamable HTTP and SSE in MCP?',
|
||||
a: 'The old HTTP+SSE transport needed two endpoints — a long-lived SSE stream for server-to-client messages and a separate POST endpoint for client-to-server messages. Streamable HTTP collapses this into one MCP endpoint that accepts HTTP POST and can optionally upgrade a response to an SSE stream when the server needs to push multiple messages.',
|
||||
},
|
||||
{
|
||||
q: 'When should I use stdio instead of HTTP?',
|
||||
a: 'Use stdio when the server runs on the same machine as the client — local dev tools, filesystem access, anything personal. The client spawns the server as a subprocess; there is no network surface and no auth to build. The moment more than one person or machine needs the server, you need Streamable HTTP.',
|
||||
},
|
||||
{
|
||||
q: 'Does Streamable HTTP require SSE?',
|
||||
a: 'No. SSE is optional within Streamable HTTP. A server can answer every request with a plain JSON response and never open a stream. Streams are only needed when the server wants to send progress notifications or multiple messages for one request.',
|
||||
},
|
||||
];
|
||||
|
||||
export default function Page() {
|
||||
return (
|
||||
<>
|
||||
<JsonLd
|
||||
data={articleJsonLd({
|
||||
title: TITLE,
|
||||
description: DESCRIPTION,
|
||||
path: PATH,
|
||||
datePublished: '2026-07-08',
|
||||
authorName: 'Marco Sadjadi',
|
||||
wordCount: 1350,
|
||||
})}
|
||||
/>
|
||||
<JsonLd
|
||||
data={breadcrumbJsonLd([
|
||||
{ name: 'Home', path: '/' },
|
||||
{ name: 'Guides', path: '/guides' },
|
||||
{ name: TITLE, path: PATH },
|
||||
])}
|
||||
/>
|
||||
<JsonLd data={faqJsonLd(TRANSPORT_FAQ)} />
|
||||
<ArticleShell
|
||||
title={TITLE}
|
||||
subtitle="MCP has shipped three transports in under two years. Two are current, one is on its way out. Here is what each one actually does, why the spec moved, and how to choose."
|
||||
updated="July 2026"
|
||||
>
|
||||
<H2>The three transports at a glance</H2>
|
||||
<Table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Transport</th>
|
||||
<th>Status</th>
|
||||
<th>Endpoints</th>
|
||||
<th>Best for</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td>stdio</td>
|
||||
<td>Current</td>
|
||||
<td>None — subprocess pipes</td>
|
||||
<td>Local, single-user tools</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>HTTP+SSE</td>
|
||||
<td>Deprecated (2025-03-26)</td>
|
||||
<td>Two: SSE stream + POST</td>
|
||||
<td>Legacy remote servers only</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Streamable HTTP</td>
|
||||
<td>Current standard for remote</td>
|
||||
<td>One MCP endpoint (POST/GET)</td>
|
||||
<td>Every remote deployment</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</Table>
|
||||
|
||||
<H2>stdio: the local transport</H2>
|
||||
<P>
|
||||
With <Strong>stdio</Strong>, the MCP client launches your server as a subprocess and
|
||||
exchanges JSON-RPC messages over stdin and stdout. There is no port, no TLS, no
|
||||
authentication — the security boundary is your operating system's process model. That is
|
||||
exactly right for tools that live on your own machine: filesystem helpers, local database
|
||||
access, developer utilities.
|
||||
</P>
|
||||
<P>
|
||||
The limitation is structural. A stdio server is bound to one machine and one client
|
||||
process. You cannot share it with a teammate, install it on a phone, or point ChatGPT's
|
||||
web app at it. It also means every user has to install a runtime (Node, Python, Docker)
|
||||
and keep the server updated themselves.
|
||||
</P>
|
||||
|
||||
<H2>HTTP+SSE: the deprecated remote transport</H2>
|
||||
<P>
|
||||
The first remote transport (protocol version 2024-11-05) paired two endpoints: the client
|
||||
opened a long-lived <Strong>Server-Sent Events</Strong> stream to receive messages, and
|
||||
sent its own messages to a separate HTTP POST endpoint the server advertised over that
|
||||
stream.
|
||||
</P>
|
||||
<P>This design turned out to be hostile to real infrastructure:</P>
|
||||
<UL>
|
||||
<li>
|
||||
<Strong>Load balancers</Strong> had to pin the SSE stream and the POST endpoint to the
|
||||
same backend instance, defeating horizontal scaling.
|
||||
</li>
|
||||
<li>
|
||||
<Strong>Serverless platforms</Strong> bill and time out on connection duration; a
|
||||
permanently open SSE stream is the pathological case.
|
||||
</li>
|
||||
<li>
|
||||
<Strong>Proxies and firewalls</Strong> routinely buffer or kill long-lived streams,
|
||||
producing connections that look healthy but deliver nothing.
|
||||
</li>
|
||||
</UL>
|
||||
<P>
|
||||
Spec revision <Strong>2025-03-26</Strong> replaced HTTP+SSE with Streamable HTTP. The old
|
||||
transport still works where both sides keep supporting it, but the direction is one-way:
|
||||
platforms have been announcing removal dates through 2026 — Atlassian's Rovo MCP server,
|
||||
for example, set its HTTP+SSE cutoff for June 30, 2026. New servers should not ship it.
|
||||
</P>
|
||||
|
||||
<H2>Streamable HTTP: the current standard</H2>
|
||||
<P>
|
||||
<Strong>Streamable HTTP</Strong> collapses everything onto a single MCP endpoint. The
|
||||
client sends JSON-RPC messages as ordinary HTTP POST requests. For a simple request, the
|
||||
server answers with a plain JSON response — request in, response out, connection closed.
|
||||
When the server needs to push several messages for one request (progress updates,
|
||||
notifications), it can upgrade that specific response to an SSE stream. Streaming becomes
|
||||
an option per response, not a mandatory architecture.
|
||||
</P>
|
||||
<UL>
|
||||
<li>Stateless requests by default — load balancers and serverless platforms just work.</li>
|
||||
<li>One URL to configure, secure and monitor instead of two coupled endpoints.</li>
|
||||
<li>
|
||||
Sessions are explicit (an <code>Mcp-Session-Id</code> header) instead of implied by a
|
||||
held-open socket, so a server can resume or reject them deliberately.
|
||||
</li>
|
||||
<li>Standard HTTP auth applies — which is what makes OAuth 2.1 integration clean.</li>
|
||||
</UL>
|
||||
<P>A remote server entry in a client config is now just a URL:</P>
|
||||
<StaticCodeBlock
|
||||
label="claude_desktop_config.json"
|
||||
code={`{
|
||||
"mcpServers": {
|
||||
"my-tool": {
|
||||
"url": "https://my-tool.mcp.buildmymcpserver.com/mcp",
|
||||
"auth": "oauth2"
|
||||
}
|
||||
}
|
||||
}`}
|
||||
/>
|
||||
|
||||
<H2>Choosing a transport</H2>
|
||||
<UL>
|
||||
<li>
|
||||
<Strong>Only you, on your machine</Strong> → stdio. Zero infrastructure, strongest
|
||||
isolation.
|
||||
</li>
|
||||
<li>
|
||||
<Strong>Anyone else, any other machine, any hosted client</Strong> → Streamable HTTP
|
||||
over TLS, with OAuth 2.1 in front of it. This is the only current answer for servers
|
||||
that Claude Desktop, Cursor and ChatGPT install over the internet.
|
||||
</li>
|
||||
<li>
|
||||
<Strong>Existing HTTP+SSE server</Strong> → migrate. The usual path is to serve the new
|
||||
single MCP endpoint alongside the legacy pair during a transition window, then drop the
|
||||
legacy endpoints once your clients are confirmed on the new transport.
|
||||
</li>
|
||||
</UL>
|
||||
<Note>
|
||||
Transport is only half of a production remote server — the other half is authorization.
|
||||
OAuth 2.1 with PKCE, Dynamic Client Registration and Resource Indicators is what makes a
|
||||
Streamable HTTP server actually installable from real clients. That's covered in{' '}
|
||||
<Link
|
||||
href="/guides/host-mcp-server-with-oauth"
|
||||
className="text-[--color-accent] hover:underline"
|
||||
>
|
||||
how to host a remote MCP server with OAuth
|
||||
</Link>
|
||||
.
|
||||
</Note>
|
||||
|
||||
<H2>FAQ</H2>
|
||||
{TRANSPORT_FAQ.map((f) => (
|
||||
<div key={f.q} className="mt-5">
|
||||
<h3 className="text-[15px] font-semibold tracking-tight text-[--color-fg]">{f.q}</h3>
|
||||
<p className="mt-1.5 text-[14px] leading-relaxed text-[--color-fg-muted]">{f.a}</p>
|
||||
</div>
|
||||
))}
|
||||
</ArticleShell>
|
||||
</>
|
||||
);
|
||||
}
|
||||
Reference in New Issue
Block a user