diff --git a/apps/web/app/(marketing)/guides/chatgpt-mcp-connector/opengraph-image.tsx b/apps/web/app/(marketing)/guides/chatgpt-mcp-connector/opengraph-image.tsx
new file mode 100644
index 0000000..3c5766f
--- /dev/null
+++ b/apps/web/app/(marketing)/guides/chatgpt-mcp-connector/opengraph-image.tsx
@@ -0,0 +1,13 @@
+import { articleOgImage, OG_SIZE } from '@/lib/og-article';
+
+export const runtime = 'edge';
+export const alt = 'Add a custom MCP connector to ChatGPT (2026 guide)';
+export const size = OG_SIZE;
+export const contentType = 'image/png';
+
+export default function Image() {
+ return articleOgImage({
+ title: 'Add a custom MCP connector to ChatGPT (2026 guide)',
+ tag: 'Setup',
+ });
+}
diff --git a/apps/web/app/(marketing)/guides/chatgpt-mcp-connector/page.tsx b/apps/web/app/(marketing)/guides/chatgpt-mcp-connector/page.tsx
new file mode 100644
index 0000000..18a06ba
--- /dev/null
+++ b/apps/web/app/(marketing)/guides/chatgpt-mcp-connector/page.tsx
@@ -0,0 +1,200 @@
+import { JsonLd } from '@/components/json-ld';
+import { articleJsonLd, breadcrumbJsonLd, pageMetadata } from '@/lib/seo';
+import Link from 'next/link';
+import { ArticleShell, H2, Note, OL, P, Strong, Table, UL } from '../article-shell';
+
+const PATH = '/guides/chatgpt-mcp-connector';
+const TITLE = 'Add a custom MCP connector to ChatGPT (2026 guide)';
+const DESCRIPTION =
+ 'How to connect a custom MCP server to ChatGPT: setup flow, the HTTPS and OAuth requirements, and the plan limits nobody mentions — write-capable connectors need a Business, Enterprise or Edu workspace.';
+
+export const metadata = pageMetadata({ title: TITLE, description: DESCRIPTION, path: PATH });
+
+export default function Page() {
+ return (
+ <>
+
+
+
+
The plan limits, first — because they decide everything
+
+ Before writing a single prompt or line of code, check what your ChatGPT plan allows.
+ OpenAI gates custom MCP connectors by workspace type:
+
+
+
+
+
Plan
+
Custom MCP connectors
+
Practical meaning
+
+
+
+
+
Free
+
No custom connectors
+
Only built-in connectors.
+
+
+
Plus / Pro (individual)
+
Read/fetch-only, via Developer Mode
+
+ Your server's search and read tools work; tools that create, update or delete will
+ not be usable.
+
+
+
+
Business / Enterprise / Edu
+
Full connectors, including write-capable tools
+
The complete MCP tool surface is available.
+
+
+
+
+ This is the most common “my connector is broken” report that is not a bug: a Plus user
+ adds a server with a create_issue tool and the tool never fires.
+ Read-only tools on the same server work fine. If write actions matter for your use case,
+ you need a Business/Enterprise/Edu workspace — or a client without this restriction, like
+ Claude Desktop (
+
+ setup guide
+
+ ).
+
+
+
What ChatGPT requires from the server
+
+
+ A public HTTPS URL. Remote MCP server URLs must use HTTPS — no local
+ STDIO servers, no plain HTTP, no localhost tunnels for anything durable.
+
+
+ Streamable HTTP transport. The current MCP remote transport; legacy
+ HTTP+SSE-only servers are on borrowed time across all clients.
+
+
+ OAuth for user-scoped auth. ChatGPT walks the standard MCP OAuth flow.
+ One sharp edge: if the authorization server issues tokens without{' '}
+ offline_access-style refresh, ChatGPT can lose access when the token
+ expires and users must reauthenticate.
+
+
+
+ If you generate and host your server on{' '}
+
+ BuildMyMCPServer
+
+ , all three are the default: every server deploys to a public HTTPS endpoint speaking
+ Streamable HTTP, behind an OAuth 2.1 authorization server with PKCE and Dynamic Client
+ Registration. There is nothing extra to configure for ChatGPT specifically.
+
+
+
Setup, step by step
+
+
+ Get your server URL — from your own deployment, from{' '}
+
+ a prompt-generated server
+
+ , or by forking a{' '}
+
+ template
+
+ .
+
+
+ In ChatGPT: Settings → Apps & Connectors. On individual plans,
+ enable Developer Mode under advanced settings first — the “create
+ connector” option is hidden without it.
+
+
Add a new connector: name it, paste the MCP endpoint URL, select OAuth as the auth method.
+
+ ChatGPT registers itself with the authorization server and opens the consent screen.
+ Approve; the connector shows as connected.
+
+
+ In a conversation, enable the connector (via the tools/plus menu) and ask for something
+ only your tool can answer. Name the tool explicitly on the first test.
+
+
+
+
Verifying it actually works
+
+ ChatGPT is more eager than Claude to answer from its own knowledge instead of calling a
+ tool. To force a real call, ask for data the model cannot know — a record you created
+ today, a value behind your API. Then check the server's dashboard: a live tool-call log
+ with latency and status per call is the ground truth for whether the connector fired.
+
+
+
Common failure modes
+
+
+
+
Symptom
+
Cause
+
Fix
+
+
+
+
+
“Create connector” option missing
+
Developer Mode off, or Free plan
+
Enable Developer Mode (Plus/Pro) or upgrade the workspace.
+
+
+
Write tools never execute
+
Individual plan — read/fetch-only restriction
+
Business/Enterprise/Edu workspace, or use a write-capable client.
+
+
+
Connector disconnects after hours/days
+
No refresh token (offline_access missing)
+
Reconnect; if you control the AS, enable refresh token issuance.
+
+
+
“Unable to reach server”
+
URL is not public HTTPS, or wrong endpoint path
+
Use the full https://…/mcp endpoint; no localhost, no http.
+
+
+
+
+
Is ChatGPT the right first client?
+
+ If your tools are read-only — search, lookup, reporting — ChatGPT works well on any paid
+ plan and the setup above takes minutes. If your tools write data, start with Claude
+ Desktop or Cursor where the full tool surface works on individual plans, and add ChatGPT
+ when a team workspace exists. The server is the same either way; only the client config
+ differs. Compare hosting options in{' '}
+
+ our platform comparison
+
+ , or check{' '}
+
+ pricing
+ {' '}
+ — the free tier is enough to test a connector end to end.
+
+
+
+ );
+}
diff --git a/apps/web/app/(marketing)/guides/claude-desktop-mcp-setup/opengraph-image.tsx b/apps/web/app/(marketing)/guides/claude-desktop-mcp-setup/opengraph-image.tsx
new file mode 100644
index 0000000..9fea83f
--- /dev/null
+++ b/apps/web/app/(marketing)/guides/claude-desktop-mcp-setup/opengraph-image.tsx
@@ -0,0 +1,13 @@
+import { articleOgImage, OG_SIZE } from '@/lib/og-article';
+
+export const runtime = 'edge';
+export const alt = 'Connect a custom MCP server to Claude Desktop (step by step)';
+export const size = OG_SIZE;
+export const contentType = 'image/png';
+
+export default function Image() {
+ return articleOgImage({
+ title: 'Connect a custom MCP server to Claude Desktop (step by step)',
+ tag: 'Setup',
+ });
+}
diff --git a/apps/web/app/(marketing)/guides/claude-desktop-mcp-setup/page.tsx b/apps/web/app/(marketing)/guides/claude-desktop-mcp-setup/page.tsx
new file mode 100644
index 0000000..51bf448
--- /dev/null
+++ b/apps/web/app/(marketing)/guides/claude-desktop-mcp-setup/page.tsx
@@ -0,0 +1,189 @@
+import { JsonLd } from '@/components/json-ld';
+import { StaticCodeBlock } from '@/components/static-code-block';
+import { articleJsonLd, breadcrumbJsonLd, pageMetadata } from '@/lib/seo';
+import Link from 'next/link';
+import { ArticleShell, H2, Note, OL, P, Strong, Table, UL } from '../article-shell';
+
+const PATH = '/guides/claude-desktop-mcp-setup';
+const TITLE = 'Connect a custom MCP server to Claude Desktop (step by step)';
+const DESCRIPTION =
+ 'How to add a remote MCP server to Claude Desktop: the config snippet, the OAuth flow on first use, and a troubleshooting table for 401s, missing servers and invisible tools.';
+
+export const metadata = pageMetadata({ title: TITLE, description: DESCRIPTION, path: PATH });
+
+const CONFIG_SNIPPET = `{
+ "mcpServers": {
+ "my-tools": {
+ "url": "https://my-tools-a1.mcp.buildmymcpserver.com/mcp",
+ "auth": "oauth2"
+ }
+ }
+}`;
+
+const LOCAL_VS_REMOTE = `# Local (STDIO) — runs on your machine, per-machine setup
+"command": "npx", "args": ["-y", "@your/mcp-server"]
+
+# Remote (Streamable HTTP) — hosted, one URL for every machine
+"url": "https://my-tools-a1.mcp.buildmymcpserver.com/mcp"`;
+
+export default function Page() {
+ return (
+ <>
+
+
+
+
Local vs. remote — pick remote unless you have a reason
+
+ Most MCP tutorials wire up a local STDIO server: Claude Desktop spawns a
+ process on your machine and talks to it over stdin/stdout. That works, but it is
+ per-machine — every teammate repeats the setup, secrets live in local config files, and
+ nothing works from a second device. A remote server over Streamable HTTP{' '}
+ is one URL that every installation shares, with auth handled by OAuth instead of
+ plaintext keys in a JSON file.
+
+
+
+
Step 1 — get a server URL
+
+ You need a live MCP endpoint. If you already run one, use its URL. If not, you can{' '}
+
+ generate one from a prompt
+ {' '}
+ or fork a working one from{' '}
+
+ the template gallery
+ {' '}
+ — either way you end up with an OAuth-protected URL like{' '}
+ https://my-tools-a1.mcp.buildmymcpserver.com/mcp.
+
+
+
Step 2 — add the server to Claude Desktop
+
+
+ Open Claude Desktop settings and go to the connectors/MCP section (on recent versions:
+ Settings → Connectors → Add custom connector), or edit{' '}
+ claude_desktop_config.json directly.
+
+
Add the server entry:
+
+
+
+
Restart Claude Desktop. Config is read at startup, not live.
+
+
+ Claude Desktop's settings UI changes between releases; the JSON config path is the stable
+ fallback. On macOS it lives at{' '}
+ ~/Library/Application Support/Claude/claude_desktop_config.json, on
+ Windows at %APPDATA%\Claude\claude_desktop_config.json.
+
+
+
Step 3 — the OAuth flow on first use
+
+ The first time Claude touches the server it will receive a 401 — that is
+ correct behavior, not an error. The client then discovers the authorization server,
+ registers itself via Dynamic Client Registration, and opens a browser window for consent.
+ You approve once; the client stores the token and refreshes it silently afterwards.
+
+
+ Under the hood this is the OAuth 2.1 handshake the MCP spec requires for remote servers:
+ PKCE so the code exchange cannot be intercepted, and Resource Indicators (RFC 8707) so a
+ token issued for this server cannot be replayed against another. Details in{' '}
+
+ the OAuth documentation
+
+ .
+
+
+
Step 4 — verify the tools are there
+
+
Open a new conversation and check the tools/connectors icon — your server should be listed with its tools.
+
+ Ask Claude directly: “Use the search_pages tool to find X.” Naming the tool
+ forces Claude to attempt the call instead of answering from memory.
+
+
Watch your server's dashboard logs — you should see the tool call arrive with latency and status.
+
+
+
Troubleshooting
+
+
+
+
Symptom
+
Likely cause
+
Fix
+
+
+
+
+
Server never appears in the client
+
Config JSON is invalid, or Claude was not restarted
+
+ Validate the JSON (trailing commas are the classic), restart Claude Desktop fully
+ (quit, not close window).
+
+
+
+
Endless 401 loop, consent screen never opens
+
URL points at the server root instead of the /mcp endpoint
+
Use the full endpoint URL ending in /mcp, exactly as the install snippet shows.
+
+
+
Consent worked, tools still missing
+
Server is deployed but tool listing failed on connect
+
+ Check the server's live logs for an initialize/list_tools error; redeploy if the
+ container restarted with a bad secret.
+
+
+
+
Tool listed, every call errors
+
Upstream credential (e.g. your API key) is wrong or expired
+
+ Update the secret in the dashboard — secrets are injected at runtime, so a redeploy
+ picks up the new value. They are never shown back, so re-enter rather than inspect.
+
+
+
+
Worked yesterday, 401 today
+
Token expired and silent refresh failed
+
Remove and re-add the connector to force a fresh OAuth flow.
+
+
+
+
+
One server, every client
+
+ The same URL works in Cursor, VS Code Copilot, Continue.dev and{' '}
+
+ ChatGPT custom connectors
+ {' '}
+ — the point of hosting a remote MCP server is that the client config is the only
+ per-client step left. If you hit a case this guide does not cover, the{' '}
+
+ docs FAQ
+ {' '}
+ collects the rarer ones.
+
+
+
+ );
+}
diff --git a/apps/web/app/(marketing)/guides/composio-alternative/opengraph-image.tsx b/apps/web/app/(marketing)/guides/composio-alternative/opengraph-image.tsx
new file mode 100644
index 0000000..26fa2a7
--- /dev/null
+++ b/apps/web/app/(marketing)/guides/composio-alternative/opengraph-image.tsx
@@ -0,0 +1,13 @@
+import { articleOgImage, OG_SIZE } from '@/lib/og-article';
+
+export const runtime = 'edge';
+export const alt = 'Composio alternative for bespoke MCP tools';
+export const size = OG_SIZE;
+export const contentType = 'image/png';
+
+export default function Image() {
+ return articleOgImage({
+ title: 'Composio alternative for bespoke MCP tools',
+ tag: 'Alternative',
+ });
+}
diff --git a/apps/web/app/(marketing)/guides/composio-alternative/page.tsx b/apps/web/app/(marketing)/guides/composio-alternative/page.tsx
new file mode 100644
index 0000000..75397fa
--- /dev/null
+++ b/apps/web/app/(marketing)/guides/composio-alternative/page.tsx
@@ -0,0 +1,206 @@
+import { JsonLd } from '@/components/json-ld';
+import { articleJsonLd, breadcrumbJsonLd, pageMetadata } from '@/lib/seo';
+import Link from 'next/link';
+import { ArticleShell, H2, Note, P, Strong, Table, UL } from '../article-shell';
+
+const PATH = '/guides/composio-alternative';
+const TITLE = 'Composio alternative for bespoke MCP tools';
+const DESCRIPTION =
+ 'Composio gives agents 1,000+ pre-built SaaS integrations. The gap is everything not in a catalog: your internal API, your database, your workflow. Here is the generate-your-own route — and where Composio clearly wins.';
+
+export const metadata = pageMetadata({ title: TITLE, description: DESCRIPTION, path: PATH });
+
+export default function Page() {
+ return (
+ <>
+
+
+
+
What Composio does well
+
+ Composio's pitch is breadth with managed auth: as of mid-2026 it exposes{' '}
+ 1,000+ third-party applications — Gmail, Slack, Notion, Salesforce,
+ HubSpot, GitHub, Linear, Stripe, Shopify and the rest of the mainstream SaaS universe — as
+ agent-callable tools behind one MCP gateway, with the OAuth dance to each SaaS handled for
+ you. Pricing is per tool call: a free tier around 20k calls/month, then paid tiers from
+ $29/month. If the integration you need is in that catalog, rebuilding it yourself is
+ almost always the wrong use of your time. That is an honest, strong product.
+
+
+
Where the catalog model hits its ceiling
+
+ A catalog, by definition, contains what many companies share. It cannot contain what only
+ your company has:
+
+
+
+ Internal APIs — the ERP endpoint, the pricing service, the legacy SOAP
+ bridge your team wrapped in REST five years ago.
+
+
+ Your database — a read-only reporting view with exactly the columns
+ the agent may see, and none it may not.
+
+
+ Custom logic between systems — "check inventory, then draft the
+ reorder in our format" is a tool, not two catalog entries.
+
+
+ Data-control requirements — some teams cannot route production
+ traffic and credentials through a third-party tool-execution layer at all.
+
+
+
+ When you hit that ceiling with a catalog product, the fallback is suddenly steep: learn
+ the MCP SDK, write and test a server, stand up hosting and OAuth. That cliff is the gap.
+
+
+
The alternative: generate the bespoke tool
+
+ BuildMyMCPServer starts where the catalog ends. You describe the tool in
+ natural language — endpoints, secrets, behavior. The platform generates a TypeScript MCP
+ server, runs static checks, builds an isolated container and deploys it behind a full
+ OAuth 2.1 authorization server (PKCE, Dynamic Client Registration, Resource Indicators),
+ with copy-paste install snippets for Claude Desktop, Cursor and ChatGPT. Secrets are
+ AES-256-GCM encrypted and injected only at runtime. You can export the full TypeScript
+ source at any time — the generated server is yours, not a subscription artifact.
+
+
+
Side by side
+
+
+
+
+
Composio
+
BuildMyMCPServer
+
+
+
+
+
+ Core object
+
+
Their catalog of pre-built integrations
+
A custom server generated from your prompt
+
+
+
+ Best for
+
+
Mainstream SaaS (Gmail, Slack, Salesforce…)
+
Internal APIs, databases, bespoke workflows
+
+
+
+ Auth to end services
+
+
Managed OAuth to hundreds of SaaS — a real moat
+
You supply credentials for your own APIs
+
+
+
+ Billing shape
+
+
Per tool call (free 20k/mo, then usage tiers)
+
Per server tier with call allowance (free: 1 server, 100k calls/mo)
+
+
+
+ Code ownership
+
+
No server code of yours exists
+
Full TypeScript source export, no lock-in
+
+
+
+ Maturity
+
+
Established, large developer base
+
Young product (launched 2026), EU-hosted
+
+
+
+
+
+ Composio details reflect its public pricing and catalog as of mid-2026; verify current
+ numbers on their site before committing budget.
+
+
+
Pick by the question you are actually asking
+
+
+ "Let my agent use Slack and Gmail" → Composio. Do not
+ generate what a maintained catalog already does better.
+
+
+ "Let my agent use our internal order API, read-only" → a
+ generated bespoke server. No catalog will ever have it.
+
+
+ Both? → they compose. MCP clients speak to multiple servers; a catalog
+ gateway for SaaS plus one generated server for the internal surface is a normal setup,
+ not a compromise.
+
+
+
+
Honest limits of the generator route
+
+ Generation is bounded by what a prompt can specify: tools with clear inputs, outputs and
+ API calls. A deeply stateful integration with complex pagination and exotic auth may
+ still be a hand-written job. And we repeat the maturity point on purpose: Composio has
+ scale and a large user base; we are new. What we offer against that is the source-export
+ exit and a{' '}
+
+ free tier
+ {' '}
+ that lets you test the claim in minutes — start from a prompt or fork a{' '}
+
+ template
+
+ .
+
+
+
+ );
+}
diff --git a/apps/web/app/(marketing)/guides/create-mcp-server-without-code/opengraph-image.tsx b/apps/web/app/(marketing)/guides/create-mcp-server-without-code/opengraph-image.tsx
new file mode 100644
index 0000000..2538ca8
--- /dev/null
+++ b/apps/web/app/(marketing)/guides/create-mcp-server-without-code/opengraph-image.tsx
@@ -0,0 +1,13 @@
+import { articleOgImage, OG_SIZE } from '@/lib/og-article';
+
+export const runtime = 'edge';
+export const alt = 'How to create an MCP server without writing code (2026)';
+export const size = OG_SIZE;
+export const contentType = 'image/png';
+
+export default function Image() {
+ return articleOgImage({
+ title: 'How to create an MCP server without writing code (2026)',
+ tag: 'Guide',
+ });
+}
diff --git a/apps/web/app/(marketing)/guides/create-mcp-server-without-code/page.tsx b/apps/web/app/(marketing)/guides/create-mcp-server-without-code/page.tsx
new file mode 100644
index 0000000..41b7349
--- /dev/null
+++ b/apps/web/app/(marketing)/guides/create-mcp-server-without-code/page.tsx
@@ -0,0 +1,222 @@
+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, OL, P, Strong, UL } from '../article-shell';
+
+const PATH = '/guides/create-mcp-server-without-code';
+const TITLE = 'How to create an MCP server without writing code (2026)';
+const DESCRIPTION =
+ 'Turn a plain-language description into a hosted, OAuth-protected MCP server — no SDK, no Docker, no TypeScript. What works, what the limits are, and when you still need code.';
+
+export const metadata = pageMetadata({ title: TITLE, description: DESCRIPTION, path: PATH });
+
+const ARTICLE_FAQ = [
+ {
+ q: 'Do I really write zero code to create an MCP server?',
+ a: 'Yes — you describe the tools in natural language. The platform generates a TypeScript MCP server, runs static checks against banned patterns, builds a Docker image and deploys it behind OAuth 2.1. You never touch the code unless you want to: the full source is exportable at any time.',
+ },
+ {
+ q: 'How long does generation take?',
+ a: 'Spec to image to live URL typically completes in 45–90 seconds. You watch the build log stream live in the dashboard.',
+ },
+ {
+ q: 'Which AI clients can use a no-code MCP server?',
+ a: 'Anything that speaks the MCP spec over Streamable HTTP: Claude Desktop, Cursor, ChatGPT custom connectors, VS Code Copilot and Continue.dev. You get a copy-paste install snippet for each.',
+ },
+ {
+ q: 'What does it cost to try?',
+ a: 'The free tier includes one hosted server and 100,000 tool calls per month — no credit card. The full TypeScript source of every server you build is exportable, so there is no lock-in.',
+ },
+];
+
+const PROMPT_EXAMPLE = `Create an MCP server that searches our Notion workspace.
+Tools: search_pages, get_page_content.
+Auth: NOTION_API_KEY.`;
+
+const SNIPPET_EXAMPLE = `{
+ "mcpServers": {
+ "notion": {
+ "url": "https://notion-x9.mcp.buildmymcpserver.com/mcp",
+ "auth": "oauth2"
+ }
+ }
+}`;
+
+export default function Page() {
+ return (
+ <>
+
+
+
+
+
What “no code” actually has to cover
+
+ An MCP server that works outside your laptop is more than tool functions. To let Claude,
+ Cursor or ChatGPT call it from anywhere, you need four things: the{' '}
+ server code itself (tool definitions plus handlers), a{' '}
+ remote transport (Streamable HTTP — the STDIO servers most tutorials
+ build only work locally), an auth layer (the MCP spec requires OAuth 2.1
+ for remote servers), and hosting that keeps the process alive. A no-code
+ claim that only generates the first item leaves you with three engineering problems. The
+ flow below covers all four.
+
+
+
Step 1 — describe the tool in plain language
+
+ You write a prompt, not a spec. Name the tools you want, the credentials they need, and
+ what they should do. A working example:
+
+
+
+ Three lines is enough because the generator asks the model for a structured spec, not
+ prose: tool names, input schemas, the API calls behind them, and which environment
+ variables hold secrets. If the description is ambiguous, you see the interpreted spec
+ before anything builds and can edit it.
+
+
+
Step 2 — generation and static checks
+
+ From the spec, the platform renders a TypeScript MCP server. Before anything runs, the
+ generated code goes through static checks against banned patterns — no
+ child processes, no filesystem escapes, no calls to unlisted hosts. This
+ matters more in a no-code flow than in a hand-written one: you did not read the code, so
+ the platform has to.
+
+
+ The output is real, exportable TypeScript. If you cancel your account tomorrow, you can{' '}
+
+ take the source
+ {' '}
+ and run it yourself — there is no proprietary runtime inside.
+
+
+
Step 3 — build and deploy
+
+ The server is packaged into a Docker image and deployed to its own isolated container —
+ one container per server, so a bug in your Notion tool cannot see your Stripe tool's
+ credentials. Secrets you provide (like NOTION_API_KEY) are encrypted
+ with AES-256-GCM at rest and injected as environment variables only at runtime. They are
+ never logged and never echoed back into the dashboard.
+
+
+ The whole pipeline — spec, render, checks, image build, deploy — typically completes in{' '}
+ 45–90 seconds, streamed live to the dashboard so you can watch each
+ stage pass.
+
+
+
Step 4 — the OAuth-protected URL
+
+ The deployed server is a public Streamable HTTP endpoint, but every request is gated by
+ OAuth 2.1 before it reaches your container. The control plane acts as the authorization
+ server — PKCE, Dynamic Client Registration (RFC 7591) and Resource Indicators (RFC 8707)
+ — which is exactly the handshake modern MCP clients expect. You never configure any of
+ it;{' '}
+
+ the OAuth docs
+ {' '}
+ explain what happens under the hood.
+
+
+
Step 5 — install in your client
+
The dashboard renders a copy-paste snippet per client. For Claude Desktop:
+
+
+ On first use the client opens the OAuth consent flow in your browser; approve it once and
+ the tools appear. The same server works in Cursor, ChatGPT custom connectors, VS Code
+ Copilot and Continue.dev — see the client-specific walkthroughs for{' '}
+
+ Claude Desktop
+ {' '}
+ and{' '}
+
+ ChatGPT
+
+ .
+
+
+
What you cannot do without code — honest limits
+
+
+ Complex business logic. Generation is good at “call this API, shape
+ the response”. Multi-step workflows with branching state, retries with compensation, or
+ heavy data transformation deserve hand-written code. Export the generated source and
+ extend it — that is the intended escape hatch.
+
+
+ Unusual protocols. Tools that need gRPC, raw TCP, or binary SDKs are
+ out of scope for prompt-generation; the generated servers speak HTTP to upstream APIs.
+
+
+ Long-running jobs. A tool call is a request/response. Anything that
+ takes minutes belongs in a queue you own, with the MCP tool submitting and polling.
+
+
+ Compliance paperwork. If procurement requires SOC 2 or HIPAA
+ certification today, a generated-and-hosted server will not check that box — no such
+ certifications are claimed. Self-hosting the exported source inside your own audited
+ infrastructure is the workaround.
+
+
+
+ Rule of thumb: if you can describe the tool in three sentences, generation gets you to
+ production. If your description needs a diagram, write code — or generate first, export,
+ then edit.
+
+
+
Try it against a real API first
+
+
+ Pick one API you use daily — Notion, GitHub, your own REST backend (
+
+ wrapping a REST API
+ {' '}
+ is the most common first server).
+
+
Write the three-line prompt: tools, credentials, behavior.
+
Watch the build, paste the snippet, ask your assistant to use the tool.
+
+
+ The{' '}
+
+ free tier
+ {' '}
+ covers one server and 100,000 tool calls a month, which is more than enough to find out
+ whether the no-code route fits your case. If it does not, you have lost ten minutes and
+ gained a working reference implementation to export. Browse{' '}
+
+ the template gallery
+ {' '}
+ if you would rather fork a working server than write a prompt.
+
+
+
FAQ
+ {ARTICLE_FAQ.map((f) => (
+
+
{f.q}
+
{f.a}
+
+ ))}
+
+
+ );
+}
diff --git a/apps/web/app/(marketing)/guides/mcp-oauth-plain-english/opengraph-image.tsx b/apps/web/app/(marketing)/guides/mcp-oauth-plain-english/opengraph-image.tsx
new file mode 100644
index 0000000..567240d
--- /dev/null
+++ b/apps/web/app/(marketing)/guides/mcp-oauth-plain-english/opengraph-image.tsx
@@ -0,0 +1,13 @@
+import { articleOgImage, OG_SIZE } from '@/lib/og-article';
+
+export const runtime = 'edge';
+export const alt = 'OAuth 2.1 for MCP servers: PKCE, DCR and RFC 8707 in plain English';
+export const size = OG_SIZE;
+export const contentType = 'image/png';
+
+export default function Image() {
+ return articleOgImage({
+ title: 'OAuth 2.1 for MCP servers, in plain English',
+ tag: 'Explainer',
+ });
+}
diff --git a/apps/web/app/(marketing)/guides/mcp-oauth-plain-english/page.tsx b/apps/web/app/(marketing)/guides/mcp-oauth-plain-english/page.tsx
new file mode 100644
index 0000000..9535d6e
--- /dev/null
+++ b/apps/web/app/(marketing)/guides/mcp-oauth-plain-english/page.tsx
@@ -0,0 +1,180 @@
+import { JsonLd } from '@/components/json-ld';
+import { articleJsonLd, breadcrumbJsonLd, pageMetadata } from '@/lib/seo';
+import Link from 'next/link';
+import { ArticleShell, H2, Note, OL, P, Strong, UL } from '../article-shell';
+
+const PATH = '/guides/mcp-oauth-plain-english';
+const TITLE = 'OAuth 2.1 for MCP servers: PKCE, DCR and RFC 8707 in plain English';
+const DESCRIPTION =
+ 'The three RFCs behind MCP authorization — PKCE, Dynamic Client Registration and Resource Indicators — explained without jargon: what each one does, the full flow step by step, and what breaks when you skip one.';
+
+export const metadata = pageMetadata({ title: TITLE, description: DESCRIPTION, path: PATH });
+
+export default function Page() {
+ return (
+ <>
+
+
+
+
Why MCP needs more than classic OAuth
+
+ Classic OAuth assumes you know your clients in advance: you register an app in a
+ dashboard, get a client_id and client_secret, and ship them
+ inside your application. MCP breaks both assumptions. The client is someone's Claude
+ Desktop or Cursor install — you will never pre-register it — and it runs on a desktop
+ where a baked-in secret is not a secret. OAuth 2.1 plus three extension RFCs is how the
+ MCP spec resolves this.
+
+
+
The two roles: Authorization Server and Resource Server
+
+ Every OAuth setup splits into two jobs. The Authorization Server (AS){' '}
+ authenticates users and issues tokens. The Resource Server (RS) — your
+ MCP server — accepts requests only when they carry a valid token. They can be the same
+ deployment or separate services; the protocol only cares that the RS can verify what the
+ AS signs, typically via a published JWKS (the AS's public keys).
+
+
+
PKCE (RFC 7636): proof that the token requester started the flow
+
+ The authorization-code flow hands the client a one-time code via a browser redirect, and
+ the client exchanges that code for a token. The classic attack is stealing the code
+ in-flight and exchanging it yourself. PKCE closes this: the client
+ invents a random secret (the verifier), sends only its hash (the challenge) when the flow
+ starts, and must present the original verifier at exchange time. A thief who intercepted
+ the code never saw the verifier, so the code is useless to them.
+
+
+ In OAuth 2.1, PKCE is mandatory for every client — the old exemption for
+ "confidential" server-side clients is gone. If your AS treats PKCE as optional, it is not
+ OAuth 2.1.
+
+ When a user adds your MCP server to Claude Desktop, the client calls your AS's
+ registration endpoint at runtime — "here is my name and redirect URI" — and receives a
+ fresh client_id on the spot. No dashboard, no support ticket, no shared
+ credentials between users. DCR is what makes "paste a URL, connect,
+ done" possible: without it, every user of every MCP client would need you to manually
+ provision app credentials.
+
+
+
Resource Indicators (RFC 8707): tokens bound to one server
+
+ A user might connect their client to ten different MCP servers. Without{' '}
+ Resource Indicators, a token minted for server A could be replayed
+ against server B — any server you talk to could impersonate you elsewhere. RFC 8707 has
+ the client name the exact server (the resource) when requesting the token,
+ and the AS bakes that audience into the token. Your MCP server then rejects any token
+ whose audience is not itself. One token, one server, no cross-server replay.
+
+
+
The full flow, step by step
+
+
+ The client sends an unauthenticated request to your MCP server and gets a{' '}
+ 401 with a WWW-Authenticate header pointing at the
+ protected-resource metadata — this is how the client discovers your AS.
+
+
The client registers itself with the AS via DCR and receives a client_id.
+
+ The client generates a PKCE verifier + challenge and opens the browser to the AS's
+ authorize endpoint, naming your server as the resource.
+
+
The user signs in and approves; the AS redirects back with a one-time code.
+
+ The client exchanges code + PKCE verifier for an access token that is
+ audience-bound to your server.
+
+
+ Every subsequent MCP request carries the token; your server verifies signature, expiry
+ and audience on each call.
+
+
+
+
What breaks when you skip a piece
+
+
+ No protected-resource metadata / wrong 401 — clients can't discover
+ your AS. The symptom: the server "works" with curl but silently fails to install from
+ Claude Desktop. This is the most common failure in the wild.
+
+
+ No DCR — the connect flow dead-ends at "unknown client" for anyone but
+ you.
+
+
+ No PKCE (or PKCE accepted but not enforced) — the flow appears to work
+ but intercepted authorization codes become exchangeable. Invisible until exploited.
+
+
+ No audience check (RFC 8707) — tokens for other servers are accepted
+ by yours, and yours are accepted elsewhere. Also invisible until exploited.
+
+
+
+ The failure modes split into two families: discovery mistakes are loud (nothing
+ connects), security mistakes are silent (everything connects, including attackers). Test
+ for both — an end-to-end install from a real client proves discovery, but only negative
+ tests (expired token, wrong audience, missing PKCE) prove the security half.
+
+
+
Common implementation mistakes
+
+
Substring-matching redirect URIs instead of exact-match comparison.
+
Allowing authorization codes to be exchanged more than once.
+
Accepting plain PKCE instead of requiring S256.
+
+ Verifying token signature and expiry but forgetting the audience claim — RFC 8707 only
+ protects you if the RS actually checks it.
+
+
+ Long-lived access tokens as a substitute for refresh tokens — shorter access-token
+ lifetime plus refresh is the OAuth 2.1 posture.
+
+
+
+
Build it or get it built-in
+
+ None of this is exotic, but it is a genuine authorization-server implementation — days of
+ work plus ongoing spec-tracking, and mistakes are security bugs rather than build
+ failures. If you want to own it, the{' '}
+
+ hosting guide
+ {' '}
+ walks through the deployment options. If you'd rather not: every server generated on
+ BuildMyMCPServer ships behind an OAuth 2.1 AS with PKCE, DCR and Resource Indicators
+ already wired — the flow above is what our{' '}
+
+ OAuth docs
+ {' '}
+ implement, and the free tier{' '}
+ includes it.
+
+
+
+ );
+}
diff --git a/apps/web/app/(marketing)/guides/mcp-server-hosting-pricing/opengraph-image.tsx b/apps/web/app/(marketing)/guides/mcp-server-hosting-pricing/opengraph-image.tsx
new file mode 100644
index 0000000..81e78d2
--- /dev/null
+++ b/apps/web/app/(marketing)/guides/mcp-server-hosting-pricing/opengraph-image.tsx
@@ -0,0 +1,13 @@
+import { articleOgImage, OG_SIZE } from '@/lib/og-article';
+
+export const runtime = 'edge';
+export const alt = 'MCP server hosting: pricing & options compared (2026)';
+export const size = OG_SIZE;
+export const contentType = 'image/png';
+
+export default function Image() {
+ return articleOgImage({
+ title: 'MCP server hosting: pricing & options compared (2026)',
+ tag: 'Comparison',
+ });
+}
diff --git a/apps/web/app/(marketing)/guides/mcp-server-hosting-pricing/page.tsx b/apps/web/app/(marketing)/guides/mcp-server-hosting-pricing/page.tsx
new file mode 100644
index 0000000..cdd2f75
--- /dev/null
+++ b/apps/web/app/(marketing)/guides/mcp-server-hosting-pricing/page.tsx
@@ -0,0 +1,251 @@
+import { JsonLd } from '@/components/json-ld';
+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-server-hosting-pricing';
+const TITLE = 'MCP server hosting: pricing & options compared (2026)';
+const DESCRIPTION =
+ 'What hosting a remote MCP server actually costs in 2026 — Cloudflare Workers, Smithery, Composio, MintMCP and prompt-to-server generation, compared on price, effort and lock-in.';
+
+export const metadata = pageMetadata({ title: TITLE, description: DESCRIPTION, path: PATH });
+
+// Pricing FAQ rendered below AND emitted as FAQPage JSON-LD — single source.
+const PRICING_FAQ = [
+ {
+ q: 'What is the cheapest way to host an MCP server?',
+ a: 'If you can write the code yourself: Cloudflare Workers — the free tier covers 100k requests/day, which is more than most personal MCP servers ever see. If you cannot or do not want to write the code, generator platforms start free (BuildMyMCPServer Hobby: 1 server, 100k tool calls/month at €0).',
+ },
+ {
+ q: 'Do I pay per tool call or per server?',
+ a: 'Both models exist. Composio bills per tool call across its catalog. Cloudflare bills per request/CPU-time. BuildMyMCPServer prices tiers by server count plus a monthly tool-call allowance. Read the overage terms — per-call platforms get expensive at agent-scale traffic.',
+ },
+ {
+ q: 'Is there a free way to get an OAuth-protected remote MCP server?',
+ a: 'Yes, two honest routes: build it yourself on Cloudflare Workers with their OAuth provider library (free tier, your time is the cost), or generate one on a free tier of a hosting generator (BuildMyMCPServer Hobby is €0 for one server with OAuth 2.1 included).',
+ },
+ {
+ q: 'What should enterprises check before picking an MCP host?',
+ a: 'Compliance posture (SOC 2 / HIPAA — MintMCP leads here as of mid-2026), data residency, audit logging, SSO, and an exit path. Ask every vendor: can I export the server code and leave?',
+ },
+];
+
+export default function Page() {
+ return (
+ <>
+
+
+
+
+
The five options at a glance
+
+ "MCP server hosting" covers products that do very different jobs: raw compute you
+ deploy to, directories that also host, connector catalogs that bill per call, wrappers
+ that productionize a server you already wrote, and generators that write and host the
+ server for you. Comparing them on price only makes sense once you know which job you are
+ buying.
+
+
+
+
+
+
Platform
+
What you get
+
Entry price
+
Paid from
+
You bring
+
+
+
+
+
+ Cloudflare Workers
+
+
Edge compute + OAuth provider library; you build and deploy
+
Free — 100k requests/day
+
$5/mo
+
All the code, OAuth wiring, upkeep
+
+
+
+ Smithery
+
+
Registry of 6,000+ servers, optional hosting of listed servers
+
Free to browse/publish
+
Paid tiers for hosting/usage
+
An existing server (or pick one from the catalog)
+
+
+
+ Composio
+
+
1,000+ pre-built SaaS integrations exposed as MCP, managed auth
+
Free — 20k tool calls/mo
+
$29/mo (200k calls)
+
Nothing — but only their catalog, per-call billing
+
+
+
+ MintMCP
+
+
Wraps your existing STDIO server into a remote OAuth deployment; SOC 2 Type II
+
Custom / enterprise pricing
+
Contact sales
+
A working server; budget for enterprise pricing
+
+
+
+ BuildMyMCPServer
+
+
Generates the TypeScript server from a prompt, hosts it behind OAuth 2.1
+
Free — 1 server, 100k tool calls/mo
+
€49/mo (5 servers, 1M calls)
+
A description of the tool. That's it.
+
+
+
+
+
+ Competitor prices are as of mid-2026 and change often — treat the entry-tier shapes as the
+ durable signal, not the exact numbers. Sources: public pricing pages of each vendor.
+
+
+
Cloudflare Workers: cheapest if your time is free
+
+ The free tier (100k requests/day, KV, D1, Durable Objects allowances) comfortably runs a
+ personal or small-team MCP server at €0 forever, and the $5/mo paid plan
+ covers almost anything below serious production traffic. The catch is that the price tag
+ measures compute, not effort: you write the server, wire the OAuth provider library,
+ handle token refresh edge cases, and own every upgrade when the MCP spec moves. For a
+ team with engineers who enjoy that work, it is the best deal on this page.
+
+
+
Smithery: pay for distribution, not development
+
+ Smithery is primarily a registry — thousands of community servers, CLI install, and
+ hosting for servers published there, with OAuth handled for hosted listings. Browsing and
+ publishing are free; hosted execution moves to paid tiers with usage. It answers
+ "where do I find or distribute a server" more than "who builds mine" —
+ if the tool you need already exists in the catalog, this can be the fastest free path of
+ all.
+
+
+
Composio: per-call pricing for a pre-built catalog
+
+ Composio's model is different: you are not hosting your server, you are
+ calling their catalog of 1,000+ integrations with managed auth. Free covers 20k
+ tool calls/month; $29/mo buys 200k, $229/mo buys 2M, with per-call overage beyond. For
+ mainstream SaaS (Gmail, Slack, Salesforce) it is excellent value. The pricing risk is
+ agent-scale traffic — an autonomous agent hammering tools burns per-call budgets fast —
+ and the structural limit is the catalog: your internal API is not in it. More in our{' '}
+
+ Composio alternative guide
+
+ .
+
+
+
MintMCP: compliance has a price tag
+
+ MintMCP wraps an existing STDIO server into a production remote deployment — OAuth
+ brokering, SSO, SCIM, audit trails, SOC 2 Type II, HIPAA-aligned controls. Pricing is
+ custom/enterprise as of mid-2026. If your buyer is a compliance team, this is the honest
+ shortlist leader; nothing else in this table carries that certification set. If you are a
+ solo developer, it is not aimed at you.
+
+
+
BuildMyMCPServer: pay for the whole job, skip the build
+
+ Our own slot in this table, stated plainly: you describe the tool in natural language, the
+ platform generates the TypeScript server, runs static checks, builds a container and
+ deploys it behind a full OAuth 2.1 authorization server (PKCE, Dynamic Client
+ Registration, Resource Indicators). Hobby is €0 — one server, 100k tool
+ calls/month. Pro is €49/mo for 5 servers and 1M calls;{' '}
+ Team €199/mo adds audit logging at 25 servers/10M calls; Enterprise is
+ custom. Full source export on every tier, so the exit path is real. What we do not have:
+ SOC 2 (we are a young product), a giant connector catalog, or edge PoPs on six continents.
+ See{' '}
+
+ full pricing
+ {' '}
+ and the{' '}
+
+ template gallery
+
+ .
+
+
+
Choosing by scenario
+
+
+ Solo dev, comfortable writing TypeScript, hobby traffic: Cloudflare
+ Workers free tier. Unbeatable if you enjoy the build.
+
+
+ Need Gmail/Slack/Notion-class connectors this afternoon: Composio free
+ tier, watch the per-call meter as agents scale.
+
+
+ Have a server, need enterprise compliance sign-off: MintMCP, budget for
+ enterprise pricing.
+
+
+ Want to publish or discover community servers: Smithery.
+
+
+ Need a bespoke tool hosted with OAuth, no code, this hour: a generator
+ — that is the job{' '}
+
+ BuildMyMCPServer
+ {' '}
+ exists for.
+
+
+
+
Pricing FAQ
+ {PRICING_FAQ.map((f) => (
+
+
{f.q}
+
{f.a}
+
+ ))}
+
+
+ Related:{' '}
+
+ the four categories of MCP platform, explained
+ {' '}
+ ·{' '}
+
+ what hosting with OAuth actually involves
+
+ .
+
+
+
+ );
+}
diff --git a/apps/web/app/(marketing)/guides/mcp-server-ohne-code-erstellen/opengraph-image.tsx b/apps/web/app/(marketing)/guides/mcp-server-ohne-code-erstellen/opengraph-image.tsx
new file mode 100644
index 0000000..efa8851
--- /dev/null
+++ b/apps/web/app/(marketing)/guides/mcp-server-ohne-code-erstellen/opengraph-image.tsx
@@ -0,0 +1,13 @@
+import { articleOgImage, OG_SIZE } from '@/lib/og-article';
+
+export const runtime = 'edge';
+export const alt = 'MCP Server ohne Code erstellen und hosten (2026)';
+export const size = OG_SIZE;
+export const contentType = 'image/png';
+
+export default function Image() {
+ return articleOgImage({
+ title: 'MCP Server ohne Code erstellen und hosten',
+ tag: 'Anleitung',
+ });
+}
diff --git a/apps/web/app/(marketing)/guides/mcp-server-ohne-code-erstellen/page.tsx b/apps/web/app/(marketing)/guides/mcp-server-ohne-code-erstellen/page.tsx
new file mode 100644
index 0000000..b2b2b34
--- /dev/null
+++ b/apps/web/app/(marketing)/guides/mcp-server-ohne-code-erstellen/page.tsx
@@ -0,0 +1,176 @@
+import { JsonLd } from '@/components/json-ld';
+import { StaticCodeBlock } from '@/components/static-code-block';
+import { articleJsonLd, breadcrumbJsonLd, pageMetadata } from '@/lib/seo';
+import Link from 'next/link';
+import { ArticleShell, H2, Note, OL, P, Strong, UL } from '../article-shell';
+
+const PATH = '/guides/mcp-server-ohne-code-erstellen';
+const TITLE = 'MCP Server ohne Code erstellen und hosten (2026)';
+const DESCRIPTION =
+ 'Wie Sie ohne Programmierkenntnisse einen eigenen MCP Server erstellen und hosten: Tool auf Deutsch oder Englisch beschreiben, generierten TypeScript-Server mit OAuth 2.1 deployen, Install-Snippet in Claude, Cursor oder ChatGPT einfügen.';
+
+export const metadata = pageMetadata({ title: TITLE, description: DESCRIPTION, path: PATH });
+
+export default function Page() {
+ return (
+ <>
+
+
+
+
Was ist MCP — in zwei Absätzen
+
+ Das Model Context Protocol (MCP) ist ein offener Standard von Anthropic,
+ der KI-Assistenten mit externen Tools, Datenbanken und APIs verbindet. Statt für jeden
+ Assistenten eine eigene Integration zu bauen, stellen Sie einen MCP Server bereit — und
+ jeder kompatible Client (Claude Desktop, Cursor, ChatGPT, VS Code Copilot, Continue.dev)
+ kann ihn nutzen.
+
+
+ Ein MCP Server stellt Tools bereit: klar definierte Funktionen wie
+ „durchsuche unser Notion-Workspace" oder „lies Bestellungen aus der Datenbank". Die KI
+ entscheidet im Gespräch, wann sie ein Tool aufruft; der Server führt aus und liefert das
+ Ergebnis zurück in den Chat.
+
+
+
Warum „ohne Code" bisher nicht selbstverständlich war
+
+ Einen lokalen Test-Server bekommt man mit dem MCP-SDK schnell hin — wenn man
+ programmieren kann. Ein produktiver, erreichbarer Server ist ein anderes
+ Kaliber: Er braucht den Streamable-HTTP-Transport, TLS, eine OAuth-2.1-Autorisierung
+ (damit nicht das ganze Internet Ihre Tools aufrufen kann), sichere Verwahrung Ihrer
+ API-Schlüssel und Hosting, das nicht nach zwei Wochen umfällt. Genau diese Schicht können
+ Sie heute generieren lassen, statt sie zu bauen.
+
+
+
Der Weg: von der Beschreibung zum laufenden Server
+
+
+ Tool beschreiben — auf Deutsch oder Englisch. Ein präziser Satz
+ genügt: welche Aufgabe, welche Tools, welche Zugangsdaten. Beispiel unten.
+
+
+ Spezifikation prüfen. Die Plattform (in unserem Fall
+ BuildMyMCPServer) analysiert die Beschreibung und schlägt die Tool-Definitionen vor —
+ Namen, Parameter, benötigte Secrets. Hier korrigieren Sie, bevor etwas gebaut wird.
+
+
+ Generieren und deployen lassen. Daraus entsteht ein
+ TypeScript-MCP-Server, der statisch geprüft, in ein Docker-Image gebaut und auf einer
+ eigenen Subdomain deployt wird — hinter einem OAuth-2.1-Authorization-Server mit PKCE.
+ Typische Dauer: 45–90 Sekunden.
+
+
+ Secrets eintragen. API-Schlüssel (z. B. Ihr Notion-Token) werden
+ AES-256-GCM-verschlüsselt gespeichert und nur zur Laufzeit als Umgebungsvariablen in
+ den Container injiziert — sie landen nie im Code und nie in Logs.
+
+
+ Install-Snippet in den Client kopieren. Für Claude Desktop, Cursor
+ und ChatGPT gibt es fertige Snippets; beim ersten Zugriff läuft der OAuth-Flow im
+ Browser.
+
+
+
+
Ein konkretes Beispiel
+
So sieht eine ausreichende Beschreibung aus — Deutsch funktioniert:
+
+
Und so das Ergebnis im Client — ein Eintrag in der Konfiguration von Claude Desktop:
+
+
+
Was Sie trotzdem verstehen sollten
+
+ „Ohne Code" heisst nicht „ohne Verantwortung". Drei Dinge bleiben Ihre Entscheidung:
+
+
+
+ Rechteumfang der Schlüssel. Geben Sie dem Server nur die Rechte, die
+ die Tools brauchen — ein Read-only-Schlüssel, wo die Quelle das anbietet. Die KI wird
+ jedes Tool nutzen, das existiert.
+
+
+ Welche Tools existieren. Lesende Tools zuerst; schreibende Tools nur,
+ wenn der Anwendungsfall sie wirklich verlangt. Mehr dazu in unserer{' '}
+
+ Security-Checkliste
+ {' '}
+ (Englisch).
+
+
+ Wem Sie den Betrieb anvertrauen. Prüfen Sie die Sicherheitsangaben
+ des Anbieters auf Konkretes: Verschlüsselung, Container-Isolation, Quellcode-Export.
+ Bei uns steht das auf der Security-Seite{' '}
+ — und jeden generierten Server können Sie als TypeScript-Quellcode exportieren und
+ selbst hosten. Kein Lock-in.
+
+
+
+
Kosten
+
+ Der Einstieg ist kostenlos: Der Hobby-Plan umfasst einen Server mit 100 000
+ Tool-Aufrufen pro Monat auf einer BuildMyMCP-Subdomain. Bezahlpläne skalieren über
+ Server-Anzahl und Aufruf-Volumen — Details auf der{' '}
+
+ Preisseite
+
+ .
+
+
+
+ Für die technischen Hintergründe auf Englisch:{' '}
+
+ MCP-Transporte erklärt
+ {' '}
+ (warum Streamable HTTP der Standard ist) und{' '}
+
+ OAuth 2.1 für MCP Server
+ {' '}
+ (was PKCE, DCR und RFC 8707 leisten).
+
+
+
+ );
+}
diff --git a/apps/web/app/(marketing)/guides/mcp-server-security-checklist/opengraph-image.tsx b/apps/web/app/(marketing)/guides/mcp-server-security-checklist/opengraph-image.tsx
new file mode 100644
index 0000000..f347482
--- /dev/null
+++ b/apps/web/app/(marketing)/guides/mcp-server-security-checklist/opengraph-image.tsx
@@ -0,0 +1,13 @@
+import { articleOgImage, OG_SIZE } from '@/lib/og-article';
+
+export const runtime = 'edge';
+export const alt = 'MCP server security checklist: secrets, isolation, auth';
+export const size = OG_SIZE;
+export const contentType = 'image/png';
+
+export default function Image() {
+ return articleOgImage({
+ title: 'MCP server security checklist: secrets, isolation, auth',
+ tag: 'Checklist',
+ });
+}
diff --git a/apps/web/app/(marketing)/guides/mcp-server-security-checklist/page.tsx b/apps/web/app/(marketing)/guides/mcp-server-security-checklist/page.tsx
new file mode 100644
index 0000000..87dd184
--- /dev/null
+++ b/apps/web/app/(marketing)/guides/mcp-server-security-checklist/page.tsx
@@ -0,0 +1,192 @@
+import { JsonLd } from '@/components/json-ld';
+import { articleJsonLd, breadcrumbJsonLd, pageMetadata } from '@/lib/seo';
+import Link from 'next/link';
+import { ArticleShell, H2, Note, P, Strong, UL } from '../article-shell';
+
+const PATH = '/guides/mcp-server-security-checklist';
+const TITLE = 'MCP server security checklist: secrets, isolation, auth';
+const DESCRIPTION =
+ 'A practical security checklist for production MCP servers: transport auth, secret storage and injection, container isolation, least-privilege tool design, safe logging, and the prompt-injection surface of tool descriptions.';
+
+export const metadata = pageMetadata({ title: TITLE, description: DESCRIPTION, path: PATH });
+
+export default function Page() {
+ return (
+ <>
+
+
+
+
1. Transport and authentication
+
+
+ TLS everywhere. A remote MCP server speaks Streamable HTTP over HTTPS
+ at a stable URL — no plaintext fallback, no self-signed shortcuts in production.
+
+
+ Every request authenticated before it reaches tool code. OAuth 2.1
+ with PKCE, Dynamic Client Registration and audience-bound tokens (RFC 8707) is the MCP
+ standard — the details are in{' '}
+
+ our plain-English OAuth explainer
+
+ . The important checklist item: an unauthenticated request must be rejected by the
+ gateway, not by convention inside your tool logic.
+
+
+ Verify audience, not just signature. A token minted for someone else's
+ server must not work on yours. Signature + expiry + audience — all three, every call.
+
+
+
+
2. Secret storage and injection
+
+
+ Encrypted at rest. API keys your server needs (Notion tokens, database
+ DSNs, Stripe keys) belong in a store that is encrypted with a real scheme —
+ AES-256-GCM, not base64, not "it's an internal database".
+
+
+ Injected at runtime, never baked in. Secrets should enter the process
+ as environment variables at container start — never committed into the generated code,
+ the image, or the template you share.
+
+
+ Never echoed back. No tool response, error message, build log or
+ debug output should ever contain a secret value. Test this deliberately: ask the AI
+ client to print its configuration and confirm the secret does not appear.
+
+
+ Scoped upstream credentials. If the upstream API offers read-only or
+ resource-scoped keys, use them. The MCP server can only leak the power you gave it.
+
+
+
+
3. Isolation between servers
+
+ If you run more than one MCP server — or host servers for more than one user — the
+ blast radius question dominates: what does a compromised or simply buggy server reach?
+
+
+
+ One server, one container. Process-level separation is not enough
+ when different trust domains share a host. Each server should run in its own container
+ with its own secrets, so a bug in one cannot read another's environment.
+
+
+ No host mounts, no docker socket. A tool-serving container has no
+ business seeing the host filesystem or the container runtime.
+
+
+ Resource limits. Memory and CPU caps per container turn a runaway
+ loop into a restart instead of a host outage.
+
+
+
+
4. Least-privilege tool design
+
+ The cheapest security control in MCP is deciding what tools exist at all. The AI will
+ eventually call every tool you expose, with every argument shape it can think of.
+
+
+
+ Read-only by default. Ship search and get{' '}
+ tools first; add write tools only when the use case demands them, and separately.
+
+
+ Narrow arguments. A query_orders(customer_id) tool is
+ auditable; a run_sql(sql) tool is an incident report with a delay timer.
+
+
+ Validate inputs inside the tool. Tool schemas are hints to the model,
+ not enforcement. Your handler must validate as if the input came from the public
+ internet — because via the model, it did.
+
+
+
+
5. Logging without leaking
+
+
+ Log that a tool was called, its latency and result status — the
+ metrics you need for operations.
+
+
+ Be deliberate about logging arguments and results: they routinely
+ contain customer data and occasionally contain secrets a model pasted into a query.
+ Redact or hash by default.
+
+
+ Keep an audit trail of who connected which client and when — OAuth
+ gives you the identity for free; keep it attached to the call records.
+
+
+
+
6. The prompt-injection surface
+
+ Two MCP-specific angles most checklists miss. First:{' '}
+ tool descriptions are instructions to the model. If you install a
+ third-party MCP server, its tool descriptions enter your AI's context — a malicious
+ description can tell the model to exfiltrate data through another tool's arguments.
+ Install servers the way you install browser extensions: from sources you trust, reading
+ what they expose.
+
+
+ Second: tool results are untrusted input to the model. If your tool
+ returns content from the outside world (web pages, tickets, emails), that content can
+ contain instructions the model may follow. You cannot fully solve this server-side, but
+ you can avoid amplifying it: return structured data instead of raw HTML where possible,
+ and never grant one server both broad read and broad write power — that pairing is what
+ turns an injected instruction into an actual exfiltration.
+
+
+
What a checklist can't fix
+
+ Honesty section: no checklist makes an over-privileged design safe. If a server holds an
+ admin API key and exposes a write-anything tool, perfect transport security just means
+ the mistake is encrypted in flight. Prompt injection remains an open research problem —
+ the mitigations above reduce blast radius, they do not eliminate the class. And a hosted
+ platform (ours included) means trusting the platform's own isolation and encryption;
+ read the vendor's{' '}
+
+ security page
+ {' '}
+ and hold them to specifics, not adjectives.
+
+
+
How BuildMyMCPServer maps to this list
+
+ For transparency about our own posture: generated servers run one-per-container behind an
+ OAuth 2.1 authorization server; customer secrets are AES-256-GCM encrypted at rest and
+ injected as environment variables at runtime, never logged or echoed back; and every
+ server's TypeScript source can be exported for review. Templates carry the spec and code,
+ never the author's credentials — you add your own on{' '}
+
+ fork
+
+ .
+
+
+
+ );
+}
diff --git a/apps/web/app/(marketing)/guides/mcp-transports-explained/opengraph-image.tsx b/apps/web/app/(marketing)/guides/mcp-transports-explained/opengraph-image.tsx
new file mode 100644
index 0000000..ebd07d8
--- /dev/null
+++ b/apps/web/app/(marketing)/guides/mcp-transports-explained/opengraph-image.tsx
@@ -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',
+ });
+}
diff --git a/apps/web/app/(marketing)/guides/mcp-transports-explained/page.tsx b/apps/web/app/(marketing)/guides/mcp-transports-explained/page.tsx
new file mode 100644
index 0000000..156a76b
--- /dev/null
+++ b/apps/web/app/(marketing)/guides/mcp-transports-explained/page.tsx
@@ -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 (
+ <>
+
+
+
+
+
The three transports at a glance
+
+
+
+
Transport
+
Status
+
Endpoints
+
Best for
+
+
+
+
+
stdio
+
Current
+
None — subprocess pipes
+
Local, single-user tools
+
+
+
HTTP+SSE
+
Deprecated (2025-03-26)
+
Two: SSE stream + POST
+
Legacy remote servers only
+
+
+
Streamable HTTP
+
Current standard for remote
+
One MCP endpoint (POST/GET)
+
Every remote deployment
+
+
+
+
+
stdio: the local transport
+
+ With stdio, 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.
+
+
+ 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.
+
+
+
HTTP+SSE: the deprecated remote transport
+
+ The first remote transport (protocol version 2024-11-05) paired two endpoints: the client
+ opened a long-lived Server-Sent Events stream to receive messages, and
+ sent its own messages to a separate HTTP POST endpoint the server advertised over that
+ stream.
+
+
This design turned out to be hostile to real infrastructure:
+
+
+ Load balancers had to pin the SSE stream and the POST endpoint to the
+ same backend instance, defeating horizontal scaling.
+
+
+ Serverless platforms bill and time out on connection duration; a
+ permanently open SSE stream is the pathological case.
+
+
+ Proxies and firewalls routinely buffer or kill long-lived streams,
+ producing connections that look healthy but deliver nothing.
+
+
+
+ Spec revision 2025-03-26 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.
+
+
+
Streamable HTTP: the current standard
+
+ Streamable HTTP 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.
+
+
+
Stateless requests by default — load balancers and serverless platforms just work.
+
One URL to configure, secure and monitor instead of two coupled endpoints.
+
+ Sessions are explicit (an Mcp-Session-Id header) instead of implied by a
+ held-open socket, so a server can resume or reject them deliberately.
+
+
Standard HTTP auth applies — which is what makes OAuth 2.1 integration clean.
+
+
A remote server entry in a client config is now just a URL:
+
+
+
Choosing a transport
+
+
+ Only you, on your machine → stdio. Zero infrastructure, strongest
+ isolation.
+
+
+ Anyone else, any other machine, any hosted client → 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.
+
+
+ Existing HTTP+SSE server → 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.
+
+
+
+ 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{' '}
+
+ how to host a remote MCP server with OAuth
+
+ .
+
+
+
FAQ
+ {TRANSPORT_FAQ.map((f) => (
+
+
{f.q}
+
{f.a}
+
+ ))}
+
+
+ );
+}
diff --git a/apps/web/app/(marketing)/guides/rest-api-to-mcp-server/opengraph-image.tsx b/apps/web/app/(marketing)/guides/rest-api-to-mcp-server/opengraph-image.tsx
new file mode 100644
index 0000000..66748fc
--- /dev/null
+++ b/apps/web/app/(marketing)/guides/rest-api-to-mcp-server/opengraph-image.tsx
@@ -0,0 +1,13 @@
+import { articleOgImage, OG_SIZE } from '@/lib/og-article';
+
+export const runtime = 'edge';
+export const alt = 'Wrap any REST API as an MCP server';
+export const size = OG_SIZE;
+export const contentType = 'image/png';
+
+export default function Image() {
+ return articleOgImage({
+ title: 'Wrap any REST API as an MCP server',
+ tag: 'Guide',
+ });
+}
diff --git a/apps/web/app/(marketing)/guides/rest-api-to-mcp-server/page.tsx b/apps/web/app/(marketing)/guides/rest-api-to-mcp-server/page.tsx
new file mode 100644
index 0000000..ae7b79d
--- /dev/null
+++ b/apps/web/app/(marketing)/guides/rest-api-to-mcp-server/page.tsx
@@ -0,0 +1,179 @@
+import { JsonLd } from '@/components/json-ld';
+import { StaticCodeBlock } from '@/components/static-code-block';
+import { articleJsonLd, breadcrumbJsonLd, pageMetadata } from '@/lib/seo';
+import Link from 'next/link';
+import { ArticleShell, H2, Note, P, Strong, Table, UL } from '../article-shell';
+
+const PATH = '/guides/rest-api-to-mcp-server';
+const TITLE = 'Wrap any REST API as an MCP server';
+const DESCRIPTION =
+ 'How to turn a REST API into an MCP server your AI clients can use: designing the tool surface (fewer, better tools beat 1:1 endpoint mapping), handling auth headers with encrypted secrets, and respecting upstream rate limits.';
+
+export const metadata = pageMetadata({ title: TITLE, description: DESCRIPTION, path: PATH });
+
+const BAD_PROMPT = `Create an MCP server for our API.
+Endpoints: GET /users, GET /users/:id, POST /users, PUT /users/:id,
+DELETE /users/:id, GET /orders, GET /orders/:id, POST /orders,
+GET /invoices, GET /invoices/:id, POST /invoices/:id/send ...`;
+
+const GOOD_PROMPT = `Create an MCP server for our billing API (https://api.example.com).
+Tools:
+- find_customer: search customers by name or email, return id, plan, status
+- get_open_invoices: list unpaid invoices for a customer id, with amounts
+- send_invoice_reminder: send the dunning email for one invoice id
+Auth: BILLING_API_KEY sent as "Authorization: Bearer" header.
+Read-heavy; send_invoice_reminder is the only write action.`;
+
+export default function Page() {
+ return (
+ <>
+
+
+
+
The core mistake: 1:1 endpoint mapping
+
+ The obvious approach — one MCP tool per REST endpoint — produces a bad server. An AI
+ assistant choosing between 30 near-identical tools burns context on the choice, chains
+ three calls where one would do, and picks wrong often enough to erode trust. The
+ assistant is not a REST client; it does not want your resource model, it wants{' '}
+ tasks.
+
+
+
+ Design the tool surface the way you would design CLI commands for a colleague:
+ task-shaped, few, with the joins already done.
+
+
+
+
+ 3–7 tools is the sweet spot for a single-purpose server. More than ten
+ and selection quality drops.
+
+
+ Fold lookups into the tool. If sending a reminder needs a customer id,
+ let find_customer exist — but do not expose the four intermediate
+ endpoints the API needs internally.
+
+
+ Return shaped results, not raw payloads. “id, plan, status” beats the
+ full 80-field customer object; the model reads every byte you return.
+
+
+ Separate reads from writes and say so in the description — clients
+ like ChatGPT restrict write tools on individual plans (
+
+ details here
+
+ ), and a clean read/write split keeps the read tools usable everywhere.
+
+
+
+
Auth: the API key never goes in the prompt
+
+ The wrapper needs your API's credential, and there is exactly one right place for it: an{' '}
+ encrypted secret, referenced by name. In the prompt above,{' '}
+ BILLING_API_KEY is a name, not a value. You provide the value separately
+ in the dashboard; it is encrypted with AES-256-GCM at rest and injected into the server's
+ container as an environment variable at runtime — never logged, never echoed back, never
+ part of the generated source.
+
+
+ The second auth layer is between the AI client and your MCP server: every deployed server
+ sits behind OAuth 2.1 (PKCE, Dynamic Client Registration, Resource Indicators), so your
+ wrapped API is not one guessable URL away from the public internet. How that handshake
+ works:{' '}
+
+ OAuth docs
+
+ .
+
+
+ Start read-only. A read-only wrapper cannot damage anything while you learn how the
+ assistant actually uses the tools; add the one or two write actions after a week of
+ watching the call logs.
+
+
+
Rate limits: yours and theirs
+
+
+
+
Layer
+
What limits it
+
What to do
+
+
+
+
+
Client → MCP server
+
OAuth gate before your container; plan quotas (free tier: 100k calls/mo)
+
Nothing — enforced for you.
+
+
+
MCP server → upstream API
+
The upstream's own rate limits
+
+ Tell the generator: “respect a limit of N req/s; on 429, back off and surface the
+ error”. Shaped tools help here too — one task call instead of five endpoint calls.
+
+
+
+
Model behavior
+
Assistants retry failed calls
+
+ Return clear error messages (“rate limited, retry in 30s”) — models read them and
+ actually wait.
+
+
+
+
+
+
From prompt to installed tool, end to end
+
+ With the prompt written, the rest is mechanical:{' '}
+
+ generation, static checks, container build and deploy
+ {' '}
+ take 45–90 seconds, and the dashboard gives you install snippets for{' '}
+
+ Claude Desktop
+
+ , Cursor and ChatGPT. The generated TypeScript is exportable — if your wrapper outgrows
+ prompt-editing (complex retries, multi-step workflows), take the source and continue by
+ hand with the boilerplate already written.
+
+
+ If your API resembles something common — Notion, GitHub, Stripe, PostgreSQL — check{' '}
+
+ the templates
+ {' '}
+ first: forking a working server and swapping in your credential is faster than writing
+ any prompt. Otherwise, the{' '}
+
+ free tier
+ {' '}
+ covers one server — enough to wrap the API you use most and find out what your assistant
+ does with it.
+
+
+
+ );
+}
diff --git a/apps/web/app/(marketing)/guides/smithery-alternative/opengraph-image.tsx b/apps/web/app/(marketing)/guides/smithery-alternative/opengraph-image.tsx
new file mode 100644
index 0000000..b39e381
--- /dev/null
+++ b/apps/web/app/(marketing)/guides/smithery-alternative/opengraph-image.tsx
@@ -0,0 +1,13 @@
+import { articleOgImage, OG_SIZE } from '@/lib/og-article';
+
+export const runtime = 'edge';
+export const alt = 'Smithery alternative: when you need hosting, not a directory';
+export const size = OG_SIZE;
+export const contentType = 'image/png';
+
+export default function Image() {
+ return articleOgImage({
+ title: 'Smithery alternative: when you need hosting, not a directory',
+ tag: 'Alternative',
+ });
+}
diff --git a/apps/web/app/(marketing)/guides/smithery-alternative/page.tsx b/apps/web/app/(marketing)/guides/smithery-alternative/page.tsx
new file mode 100644
index 0000000..e92b62b
--- /dev/null
+++ b/apps/web/app/(marketing)/guides/smithery-alternative/page.tsx
@@ -0,0 +1,196 @@
+import { JsonLd } from '@/components/json-ld';
+import { articleJsonLd, breadcrumbJsonLd, pageMetadata } from '@/lib/seo';
+import Link from 'next/link';
+import { ArticleShell, H2, Note, P, Strong, Table, UL } from '../article-shell';
+
+const PATH = '/guides/smithery-alternative';
+const TITLE = 'Smithery alternative: when you need hosting, not a directory';
+const DESCRIPTION =
+ 'Smithery is the best-known MCP registry — thousands of servers, CLI install, hosting for listed servers. The gap: it assumes the server exists. Here is the route when it does not, and where Smithery clearly wins.';
+
+export const metadata = pageMetadata({ title: TITLE, description: DESCRIPTION, path: PATH });
+
+export default function Page() {
+ return (
+ <>
+
+
+
+
What Smithery does well
+
+ Smithery is the closest thing MCP has to a package index. As of mid-2026 it lists{' '}
+ thousands of community-built servers (their catalog crossed 6,000+ some
+ time ago), searchable by category, installable via CLI, and — for servers published there
+ — runnable as hosted remote endpoints with OAuth handled by the platform. Its Toolbox
+ meta-server can even route an agent dynamically across registry servers so you don't
+ wire each one by hand. Browsing and publishing are free; hosted execution and higher
+ usage sit behind paid tiers.
+
+
+ Two jobs it does better than anyone: discovery ("does a server for X
+ already exist?") and distribution ("let people find and run the
+ server I wrote"). If either is your actual need, stop reading and use Smithery.
+
+
+
The assumption baked into a registry
+
+ Every path through Smithery starts from an existing server: one you found in the catalog,
+ or one you wrote and published. The moment your need is a tool that{' '}
+ nobody has built — a wrapper around your internal API, a scoped read-only view of
+ your own database, a workflow specific to your team — the registry has nothing to list.
+ You are back to the MCP SDK, TypeScript, container images and OAuth wiring before
+ Smithery can help you host or distribute anything.
+
+
+
The alternative: generate, then host
+
+ BuildMyMCPServer replaces the "write it first" step. Describe
+ the tool in natural language; the platform generates the TypeScript MCP server, runs
+ static checks, builds an isolated Docker container and deploys it behind a full OAuth 2.1
+ authorization server (PKCE, Dynamic Client Registration, Resource Indicators) at a public
+ Streamable HTTP URL. Claude Desktop, Cursor and ChatGPT connect with a copy-paste
+ snippet. The full source stays exportable — if you later want to publish the server on
+ Smithery or self-host it, you can take the code and go.
+
+
+
Side by side
+
+
+
+
+
Smithery
+
BuildMyMCPServer
+
+
+
+
+
+ Core job
+
+
Find, publish and run existing servers
+
Create and host a server that doesn't exist yet
+
+
+
+ Starting point
+
+
A server (yours or the catalog's)
+
A sentence describing the tool
+
+
+
+ Catalog size
+
+
Thousands of community servers
+
Small first-party template gallery
+
+
+
+ Hosting & auth
+
+
Hosted endpoints with OAuth for listed servers
+
Every server deployed behind OAuth 2.1, isolated container
+
+
+
+ Pricing shape
+
+
Free registry; paid hosting/usage tiers
+
Free: 1 server, 100k calls/mo; Pro €49/mo
+
+
+
+ Exit path
+
+
Your code was always yours
+
Full TypeScript source export
+
+
+
+
+
+ Smithery details are as of mid-2026 from public materials; check their site for current
+ catalog size and tier pricing.
+
+
+
Decision rule
+
+
+ The tool might already exist → search Smithery first. Genuinely — five
+ minutes there can save the whole build.
+
+
+ You wrote a server and want users → publish on Smithery; that is its
+ home turf.
+
+
+ The tool is bespoke to your company → generate it. A registry cannot
+ list what only you need.
+
+
+ Long-term: the routes compose — generate the bespoke server, export
+ the source, publish it wherever distribution helps.
+
+
+
+
Honest caveats
+
+ We are the young product in this comparison: no SOC 2, a small template gallery next to a
+ registry of thousands, and a generator that is bounded by what a prompt can specify —
+ clear inputs, outputs and API calls. What we ask you to test is the part that matters
+ when nothing in any catalog fits: prompt to hosted, OAuth-protected server in about a
+ minute, on the{' '}
+
+ free tier
+
+ , starting from scratch or from a{' '}
+
+ template
+
+ .
+
+
+
+ Related:{' '}
+
+ MCP hosting pricing compared
+ {' '}
+ ·{' '}
+
+ registries vs connectors vs infra vs generators
+ {' '}
+ ·{' '}
+
+ Composio alternative
+
+ .
+
+
+
+ );
+}
diff --git a/apps/web/lib/articles.ts b/apps/web/lib/articles.ts
index 1924540..82f3337 100644
--- a/apps/web/lib/articles.ts
+++ b/apps/web/lib/articles.ts
@@ -15,6 +15,94 @@ export interface Article {
}
export const ARTICLES: Article[] = [
+ {
+ slug: 'create-mcp-server-without-code',
+ title: 'How to create an MCP server without writing code (2026)',
+ description:
+ 'Turn a plain-language description into a hosted, OAuth-protected MCP server — no SDK, no Docker, no TypeScript. What works, what the limits are, and when you still need code.',
+ tag: 'Guide',
+ datePublished: '2026-07-08',
+ },
+ {
+ slug: 'claude-desktop-mcp-setup',
+ title: 'Connect a custom MCP server to Claude Desktop (step by step)',
+ description:
+ 'How to add a remote MCP server to Claude Desktop: the config snippet, the OAuth flow on first use, and a troubleshooting table for 401s, missing servers and invisible tools.',
+ tag: 'Setup',
+ datePublished: '2026-07-08',
+ },
+ {
+ slug: 'chatgpt-mcp-connector',
+ title: 'Add a custom MCP connector to ChatGPT (2026 guide)',
+ description:
+ 'How to connect a custom MCP server to ChatGPT: setup flow, the HTTPS and OAuth requirements, and the plan limits nobody mentions — write-capable connectors need a Business, Enterprise or Edu workspace.',
+ tag: 'Setup',
+ datePublished: '2026-07-08',
+ },
+ {
+ slug: 'rest-api-to-mcp-server',
+ title: 'Wrap any REST API as an MCP server',
+ description:
+ 'How to turn a REST API into an MCP server your AI clients can use: designing the tool surface, handling auth headers with encrypted secrets, and respecting upstream rate limits.',
+ tag: 'Guide',
+ datePublished: '2026-07-08',
+ },
+ {
+ slug: 'mcp-server-hosting-pricing',
+ title: 'MCP server hosting: pricing & options compared (2026)',
+ description:
+ 'What hosting a remote MCP server actually costs in 2026 — Cloudflare Workers, Smithery, Composio, MintMCP and prompt-to-server generation, compared on price, effort and lock-in.',
+ tag: 'Comparison',
+ datePublished: '2026-07-08',
+ },
+ {
+ slug: 'composio-alternative',
+ title: 'Composio alternative for bespoke MCP tools',
+ description:
+ 'Composio gives agents 1,000+ pre-built SaaS integrations. The gap is everything not in a catalog: your internal API, your database, your workflow. Here is the generate-your-own route — and where Composio clearly wins.',
+ tag: 'Alternative',
+ datePublished: '2026-07-08',
+ },
+ {
+ slug: 'smithery-alternative',
+ title: 'Smithery alternative: when you need hosting, not a directory',
+ description:
+ 'Smithery is the best-known MCP registry — thousands of servers, CLI install, hosting for listed servers. The gap: it assumes the server exists. Here is the route when it does not, and where Smithery clearly wins.',
+ tag: 'Alternative',
+ datePublished: '2026-07-08',
+ },
+ {
+ slug: 'mcp-transports-explained',
+ title: 'MCP transports explained: stdio vs SSE vs Streamable HTTP',
+ 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.',
+ tag: 'Explainer',
+ datePublished: '2026-07-08',
+ },
+ {
+ slug: 'mcp-oauth-plain-english',
+ title: 'OAuth 2.1 for MCP servers: PKCE, DCR and RFC 8707 in plain English',
+ description:
+ 'The three RFCs behind MCP authorization — PKCE, Dynamic Client Registration and Resource Indicators — explained without jargon: what each one does, the full flow step by step, and what breaks when you skip one.',
+ tag: 'Explainer',
+ datePublished: '2026-07-08',
+ },
+ {
+ slug: 'mcp-server-security-checklist',
+ title: 'MCP server security checklist: secrets, isolation, auth',
+ description:
+ 'A practical security checklist for production MCP servers: transport auth, secret storage and injection, container isolation, least-privilege tool design, safe logging, and the prompt-injection surface of tool descriptions.',
+ tag: 'Checklist',
+ datePublished: '2026-07-08',
+ },
+ {
+ slug: 'mcp-server-ohne-code-erstellen',
+ title: 'MCP Server ohne Code erstellen und hosten (2026)',
+ description:
+ 'Wie Sie ohne Programmierkenntnisse einen eigenen MCP Server erstellen und hosten: Tool auf Deutsch oder Englisch beschreiben, generierten TypeScript-Server mit OAuth 2.1 deployen, Install-Snippet in Claude, Cursor oder ChatGPT einfügen.',
+ tag: 'Anleitung',
+ datePublished: '2026-07-08',
+ },
{
slug: 'host-mcp-server-with-oauth',
title: 'How to host a remote MCP server with OAuth (2026)',
diff --git a/apps/web/lib/seo.ts b/apps/web/lib/seo.ts
index ab826bb..635d2c7 100644
--- a/apps/web/lib/seo.ts
+++ b/apps/web/lib/seo.ts
@@ -196,6 +196,8 @@ export function articleJsonLd(opts: {
/** Named human author. Falls back to the Organization. */
authorName?: string;
wordCount?: number;
+ /** BCP-47 language tag; the guides corpus is English except where noted. */
+ inLanguage?: string;
}): object {
const image = opts.image ?? `${SITE_URL}${opts.path}/opengraph-image`;
return {
@@ -208,7 +210,7 @@ export function articleJsonLd(opts: {
image: image.startsWith('http') ? image : `${SITE_URL}${image}`,
datePublished: opts.datePublished,
dateModified: opts.dateModified ?? opts.datePublished,
- inLanguage: 'en',
+ inLanguage: opts.inLanguage ?? 'en',
author: opts.authorName
? { '@type': 'Person', name: opts.authorName }
: { '@id': `${SITE_URL}/#organization` },