From a08f5f05b1b3e17646481674836a5540ad137845 Mon Sep 17 00:00:00 2001 From: Marco Sadjadi Date: Wed, 8 Jul 2026 23:04:19 +0200 Subject: [PATCH] feat(content): 11 new SEO/GEO guide articles with per-article OG images MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 Claude-Session: https://claude.ai/code/session_01SXUwmPVRTD8AKQtio6gCN5 --- .../chatgpt-mcp-connector/opengraph-image.tsx | 13 + .../guides/chatgpt-mcp-connector/page.tsx | 200 ++++++++++++++ .../opengraph-image.tsx | 13 + .../guides/claude-desktop-mcp-setup/page.tsx | 189 +++++++++++++ .../composio-alternative/opengraph-image.tsx | 13 + .../guides/composio-alternative/page.tsx | 206 ++++++++++++++ .../opengraph-image.tsx | 13 + .../create-mcp-server-without-code/page.tsx | 222 ++++++++++++++++ .../opengraph-image.tsx | 13 + .../guides/mcp-oauth-plain-english/page.tsx | 180 +++++++++++++ .../opengraph-image.tsx | 13 + .../mcp-server-hosting-pricing/page.tsx | 251 ++++++++++++++++++ .../opengraph-image.tsx | 13 + .../mcp-server-ohne-code-erstellen/page.tsx | 176 ++++++++++++ .../opengraph-image.tsx | 13 + .../mcp-server-security-checklist/page.tsx | 192 ++++++++++++++ .../opengraph-image.tsx | 13 + .../guides/mcp-transports-explained/page.tsx | 206 ++++++++++++++ .../opengraph-image.tsx | 13 + .../guides/rest-api-to-mcp-server/page.tsx | 179 +++++++++++++ .../smithery-alternative/opengraph-image.tsx | 13 + .../guides/smithery-alternative/page.tsx | 196 ++++++++++++++ apps/web/lib/articles.ts | 88 ++++++ apps/web/lib/seo.ts | 4 +- 24 files changed, 2431 insertions(+), 1 deletion(-) create mode 100644 apps/web/app/(marketing)/guides/chatgpt-mcp-connector/opengraph-image.tsx create mode 100644 apps/web/app/(marketing)/guides/chatgpt-mcp-connector/page.tsx create mode 100644 apps/web/app/(marketing)/guides/claude-desktop-mcp-setup/opengraph-image.tsx create mode 100644 apps/web/app/(marketing)/guides/claude-desktop-mcp-setup/page.tsx create mode 100644 apps/web/app/(marketing)/guides/composio-alternative/opengraph-image.tsx create mode 100644 apps/web/app/(marketing)/guides/composio-alternative/page.tsx create mode 100644 apps/web/app/(marketing)/guides/create-mcp-server-without-code/opengraph-image.tsx create mode 100644 apps/web/app/(marketing)/guides/create-mcp-server-without-code/page.tsx create mode 100644 apps/web/app/(marketing)/guides/mcp-oauth-plain-english/opengraph-image.tsx create mode 100644 apps/web/app/(marketing)/guides/mcp-oauth-plain-english/page.tsx create mode 100644 apps/web/app/(marketing)/guides/mcp-server-hosting-pricing/opengraph-image.tsx create mode 100644 apps/web/app/(marketing)/guides/mcp-server-hosting-pricing/page.tsx create mode 100644 apps/web/app/(marketing)/guides/mcp-server-ohne-code-erstellen/opengraph-image.tsx create mode 100644 apps/web/app/(marketing)/guides/mcp-server-ohne-code-erstellen/page.tsx create mode 100644 apps/web/app/(marketing)/guides/mcp-server-security-checklist/opengraph-image.tsx create mode 100644 apps/web/app/(marketing)/guides/mcp-server-security-checklist/page.tsx create mode 100644 apps/web/app/(marketing)/guides/mcp-transports-explained/opengraph-image.tsx create mode 100644 apps/web/app/(marketing)/guides/mcp-transports-explained/page.tsx create mode 100644 apps/web/app/(marketing)/guides/rest-api-to-mcp-server/opengraph-image.tsx create mode 100644 apps/web/app/(marketing)/guides/rest-api-to-mcp-server/page.tsx create mode 100644 apps/web/app/(marketing)/guides/smithery-alternative/opengraph-image.tsx create mode 100644 apps/web/app/(marketing)/guides/smithery-alternative/page.tsx 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: +

+ + + + + + + + + + + + + + + + + + + + + + + + + +
PlanCustom MCP connectorsPractical meaning
FreeNo custom connectorsOnly 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 / EduFull connectors, including write-capable toolsThe 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

+
    +
  1. + Get your server URL — from your own deployment, from{' '} + + a prompt-generated server + + , or by forking a{' '} + + template + + . +
    2. +
  2. + In ChatGPT: Settings → Apps & Connectors. On individual plans, + enable Developer Mode under advanced settings first — the “create + connector” option is hidden without it. +
    3. +
  3. Add a new connector: name it, paste the MCP endpoint URL, select OAuth as the auth method.
    4. +
  4. + ChatGPT registers itself with the authorization server and opens the consent screen. + Approve; the connector shows as connected. +
    5. +
  5. + 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. +
    6. +
+ +

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

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SymptomCauseFix
“Create connector” option missingDeveloper Mode off, or Free planEnable Developer Mode (Plus/Pro) or upgrade the workspace.
Write tools never executeIndividual plan — read/fetch-only restrictionBusiness/Enterprise/Edu workspace, or use a write-capable client.
Connector disconnects after hours/daysNo 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 pathUse 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

+
    +
  1. + 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. +
    2. +
  2. Add the server entry:
    3. +
+ +
    +
  1. Restart Claude Desktop. Config is read at startup, not live.
    2. +
+ + 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

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SymptomLikely causeFix
Server never appears in the clientConfig 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 opensURL points at the server root instead of the /mcp endpointUse the full endpoint URL ending in /mcp, exactly as the install snippet shows.
Consent worked, tools still missingServer 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 errorsUpstream 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 todayToken expired and silent refresh failedRemove 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

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
 ComposioBuildMyMCPServer
+ Core object + Their catalog of pre-built integrationsA 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 moatYou 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 existsFull TypeScript source export, no lock-in
+ Maturity + Established, large developer baseYoung 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 + + . +

+ +

+ Related:{' '} + + MCP hosting pricing compared + {' '} + ·{' '} + + the four platform categories + {' '} + ·{' '} + + MintMCP alternative + + . +

+ + + ); +} 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

+
    +
  1. + Pick one API you use daily — Notion, GitHub, your own REST backend ( + + wrapping a REST API + {' '} + is the most common first server). +
    2. +
  2. Write the three-line prompt: tools, credentials, behavior.
    3. +
  3. Watch the build, paste the snippet, ask your assistant to use the tool.
    4. +
+

+ 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. +

+ +

Dynamic Client Registration (RFC 7591): clients register themselves

+

+ 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

+
    +
  1. + 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. +
    2. +
  2. The client registers itself with the AS via DCR and receives a client_id.
    3. +
  3. + The client generates a PKCE verifier + challenge and opens the browser to the AS's + authorize endpoint, naming your server as the resource. +
    4. +
  4. The user signs in and approves; the AS redirects back with a one-time code.
    5. +
  5. + The client exchanges code + PKCE verifier for an access token that is + audience-bound to your server. +
    6. +
  6. + Every subsequent MCP request carries the token; your server verifies signature, expiry + and audience on each call. +
    7. +
+ +

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. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PlatformWhat you getEntry pricePaid fromYou bring
+ Cloudflare Workers + Edge compute + OAuth provider library; you build and deployFree — 100k requests/day$5/moAll the code, OAuth wiring, upkeep
+ Smithery + Registry of 6,000+ servers, optional hosting of listed serversFree to browse/publishPaid tiers for hosting/usageAn existing server (or pick one from the catalog)
+ Composio + 1,000+ pre-built SaaS integrations exposed as MCP, managed authFree — 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 IICustom / enterprise pricingContact salesA working server; budget for enterprise pricing
+ BuildMyMCPServer + Generates the TypeScript server from a prompt, hosts it behind OAuth 2.1Free — 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

+
    +
  1. + Tool beschreiben — auf Deutsch oder Englisch. Ein präziser Satz + genügt: welche Aufgabe, welche Tools, welche Zugangsdaten. Beispiel unten. +
    2. +
  2. + 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. +
    3. +
  3. + 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. +
    4. +
  4. + 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. +
    5. +
  5. + 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. +
    6. +
+ +

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

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TransportStatusEndpointsBest for
stdioCurrentNone — subprocess pipesLocal, single-user tools
HTTP+SSEDeprecated (2025-03-26)Two: SSE stream + POSTLegacy remote servers only
Streamable HTTPCurrent standard for remoteOne 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

+ + + + + + + + + + + + + + + + + + + + + + + + + +
LayerWhat limits itWhat to do
Client → MCP serverOAuth gate before your container; plan quotas (free tier: 100k calls/mo)Nothing — enforced for you.
MCP server → upstream APIThe 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 behaviorAssistants 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

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
 SmitheryBuildMyMCPServer
+ Core job + Find, publish and run existing serversCreate 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 serversSmall first-party template gallery
+ Hosting & auth + Hosted endpoints with OAuth for listed serversEvery server deployed behind OAuth 2.1, isolated container
+ Pricing shape + Free registry; paid hosting/usage tiersFree: 1 server, 100k calls/mo; Pro €49/mo
+ Exit path + Your code was always yoursFull 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` },