Remote MCP als Zielbild für SaaS — nicht Localhost-Demo
Nutzer wollen Claude, Cursor oder andere Clients direkt mit eurem Produkt sprechen — ohne Integrationsingenieur zu werden. MCP strukturiert das: Tools, Resources, optional Prompts statt Scraping und Prompt-Glue. Für SaaS zählt der Unterschied Stdio lokal vs. HTTP remote — erst Letzteres ermöglicht gehostete Auth und normales Onboarding.
Remote MCP hält Logik in eurer Infrastruktur: Monitoring, Rate Limits, Updates ohne Client-Config-Pflege auf tausenden Rechnern. Nutzer wollen „verbinden und nutzen“, nicht Token erzeugen und in JSON kleben.
Kontext: MCP-Grundlagen für Docs, CLI vs. MCP. Discovery-Layer: llms.txt.
Drei Deployment-Modelle — und ihre Reibung
1. Local stdio: Schnellster Start (@modelcontextprotocol/sdk, StdioServerTransport). Nutzer installiert Paket/Binary, Client spawnt Prozess — Node, PATH und OS werden Teil eures Produkts.
2. Remote + manuelles Token: Gehosteter Server, oft mit mcp-remote-Bridge wenn Client nur Stdio kennt. Besser als rein lokal, aber Token-Friction bleibt.
3. Remote + OAuth (tokenless): Connector-URL, Sign-in, Consent — kein Bearer in Config. Aufwand in Discovery, Consent, Edge — aber das gewünschte SaaS-Erlebnis.
Empfohlene Build-Reihenfolge: Tools lokal validieren → gleiche Tools hinter Streamable HTTP → 401-Challenge → Discovery-Metadaten → OAuth → Tunnel-Test.
Tool-Oberfläche schmal halten — dann Transport richtig bauen
Nicht jede interne API spiegeln. Kohärente Workflows: Docs = listen, pull, push, publish; CRM = search, fetch, note, stage update. RPC-Zoo vermeiden.
Öffentliche URL bewusst wählen — https://app.de/dashboard-mcp liest sich wie Capability, /api/internal/v1/mcp wie Leak. Endpoint muss Streamable HTTP sprechen: POST mit JSON-RPC, Accept: application/json, text/event-stream, optional Mcp-Session-Id.
Unauthenticated Endpoint muss 401 mit `WWW-Authenticate` und resource_metadata liefern — sonst fehlt der Onboarding-Pfad für tokenlose Flows.
OAuth, Discovery und Edge-Härtung
Client braucht: Protected-Resource-Metadaten (/.well-known/oauth-protected-resource/...), Authorization-Server-Metadaten, optional Dynamic Client Registration. Jede Discovery-Route mit curl testen — HTML-Redirects statt JSON sind häufigster Connector-Killer.
Consent-Schicht neben normalem Login: Scopes für read/write/publish. Resource-Parameter im OAuth-Flow — Token-Audience muss zur MCP-URL passen, sonst nur „opaque Bearer“. Edge: Origin prüfen, keine Tokens in Query-Strings, 401/403/400 unterscheidbar.
Tunnel-Tests (z. B. ngrok) sind Pflicht: Custom Connectors laufen in der Cloud, nicht auf localhost — Callback-, Cookie- und Discovery-Mismatches zeigen sich erst öffentlich.
Endzustand für Beratungs-Deliverables
Gutes Remote-MCP für Kunden: stabile Public-URL, schmale Tool-Fläche, explizite Discovery, App-Login + Consent, kein lokales Runtime-Setup. MCP selbst ist oft nicht der harte Teil — Onboarding verschwinden lassen ist es.
Typische Bugs: Discovery liefert HTML, Origin-Mismatch, Redirect-Ketten, Zeitskala in Token-Expiry. Erster funktionierender Tunnel-Test schlägt Wochen localhost-Vertrauen.
Read-only Public Docs: oft llms.txt + Negotiation zuerst; MCP wenn Suche, private Daten oder Schreibzugriff — Skills via skill.md für Nutzungsregeln.
