Wenn du in den Jahren 2025-2026 SaaS-Produkte entwickelt hast, ist dir wahrscheinlich aufgefallen, dass jeder Product Manager jetzt „KI-Features" möchte. Fair enough. Aber die eigentliche Frage ist nicht, ob du KI hinzufügst – sondern wie du KI-Modellen strukturierten, sicheren Zugriff auf die Daten und Funktionen deiner Anwendung gibst. Genau das löst das Model Context Protocol (MCP), und das Deployment von MCP-Servern auf Vercel mit Next.js ist eines der praktischsten Muster, die ich für SaaS-Teams gesehen habe, die schnell vorankommen wollen, ohne neue Infrastruktur aufzubauen.

Ich habe die letzten Monate damit verbracht, MCP-Server für Clients zu erstellen – von einfachen Tool-serving-Setups bis hin zu komplexen Multi-Tenant-Auth-Flows. Dieser Artikel behandelt alles, was ich über das Bauen, Bereitstellen und Skalieren von MCP-Servern auf Vercel mit Next.js gelernt habe.

MCP Server Development: Deploy on Vercel with Next.js for SaaS

Inhaltsverzeichnis

Was ist MCP und warum sollte sich dein SaaS-Team dafür interessieren

Das Model Context Protocol (MCP) ist ein offener Standard – ursprünglich von Anthropic entwickelt und jetzt weit verbreitet – der definiert, wie KI-Modelle mit externen Tools und Datenquellen interagieren. Denk daran als USB-C-Port für KI: eine standardisierte Schnittstelle, die jeder KI-Client verwenden kann, um sich mit jedem MCP-kompatiblen Server zu verbinden.

Vor MCP musste man, wenn man Claude, GPT oder ein anderes Modell mit seiner SaaS-App interagieren lassen wollte, benutzerdefinierte Integrationen für jeden KI-Anbieter erstellen. Function Calling mit OpenAI sah anders aus als Tool Use mit Anthropic. MCP ändert das. Du erstellst einen Server, und jeder MCP-kompatible Client kann ihn verwenden.

Für SaaS-Teams ist das wichtig, weil:

  • Deine Benutzer erwarten KI-Integrationen. Mitte 2026 berichten etwa 68% der B2B-SaaS-Benutzer, dass sie KI-Assistenten zusammen mit ihren primären Tools nutzen (Gartner, Q1 2026).
  • MCP wird zum Standard. Claude Desktop, Cursor, Windsurf, VS Code Copilot und Dutzende andere Clients unterstützen jetzt nativ MCP.
  • Das Bauen eines MCP-Servers ist billiger als das Bauen benutzerdefinierter Integrationen für jeden KI-Anbieter.

MCP vs. traditionelle API-Integrationen

Aspekt Traditionelle API MCP-Server
Client-Kompatibilität Eins-zu-eins pro Provider Jeder MCP-kompatible Client
Discovery Manuelle Dokumentation Automatische Tool-/Ressourcen-Discovery
Auth-Flow Benutzerdefiniert pro Integration Standardisiertes OAuth 2.1 / API-Schlüssel
Wartungsaufwand Hoch (N Integrationen) Niedrig (1 Server)
Echtzeit-Daten Polling oder Webhooks Server-Sent Events / Streaming
Setup-Zeit Tage bis Wochen pro Client Stunden für den Server, Minuten pro Client

Architekturübersicht: MCP auf Vercel

Hier ist die Architektur, auf der ich nach mehreren Iterationen gelandet bin:

┌─────────────────┐     ┌──────────────────────┐     ┌─────────────────┐
│  MCP Clients    │     │  Vercel (Next.js)    │     │  Dein SaaS      │
│                 │     │                      │     │  Backend        │
│  - Claude       │────▶│  /api/mcp (HTTP+SSE) │────▶│  - Datenbank    │
│  - Cursor       │     │  /api/mcp/sse        │     │  - APIs         │
│  - Custom Apps  │◀────│  /api/auth/[...mcp]  │     │  - Services     │
└─────────────────┘     └──────────────────────┘     └─────────────────┘

Die Kernidee: Dein MCP-Server ersetzt deine bestehende API nicht. Er sitzt davor als Translationsschicht. Der MCP-Server stellt Tools und Ressourcen zur Verfügung, die auf deine bestehende SaaS-Funktionalität abgebildet werden, aber in einem Format, das KI-Modelle entdecken und verwenden können.

Auf Vercel läuft dies als serverlose Funktionen. Die neueste MCP-Spezifikation (v2025-12) unterstützt HTTP mit Server-Sent Events (SSE) als Transport, was gut mit Vercels Streaming-Unterstützung in Next.js Route-Handlern funktioniert.

Warum Next.js auf Vercel?

Du könntest einen MCP-Server mit jedem Framework bauen – Express, Fastify, Hono, was auch immer. Aber Next.js auf Vercel bietet dir einige echte Vorteile für SaaS:

  1. Deine Marketing-Site, App und MCP-Server leben in einem Repo. Weniger Infrastruktur zum Verwalten.
  2. Edge-Middleware handhaben Auth, bevor Anfragen deine MCP-Endpunkte erreichen.
  3. Vercels Streaming-Unterstützung funktioniert gut mit SSE-basiertem MCP-Transport.
  4. Automatische Skalierung – du denkst nicht über Server nach.
  5. Falls du bereits Next.js betreibst (und statistisch gesehen tust du das wahrscheinlich), gibt es null neue Infrastruktur.

Wir machen viel Next.js-Entwicklung bei Social Animal, und dieses Muster ist zu einer unserer am meisten angeforderten Architekturen geworden.

MCP Server Development: Deploy on Vercel with Next.js for SaaS - architecture

Einrichten deines Next.js MCP-Servers

Lass uns das bauen. Ich gehe davon aus, dass du auf Next.js 15+ mit dem App Router bist.

Abhängigkeiten installieren

pnpm add @modelcontextprotocol/sdk zod
pnpm add -D @types/node

Das @modelcontextprotocol/sdk-Paket (v1.12+ ab Anfang 2026) enthält alles, was du für HTTP+SSE-Transport brauchst. Frühere Versionen unterstützten nur stdio, was auf serverlos nicht funktioniert.

Erstellen des MCP-Route-Handlers

// app/api/mcp/route.ts
import { McpServer } from '@modelcontextprotocol/sdk/server';
import { httpTransport } from '@modelcontextprotocol/sdk/server/http';
import { z } from 'zod';

const server = new McpServer({
  name: 'your-saas-mcp',
  version: '1.0.0',
  description: 'MCP server for YourSaaS platform',
});

// Register tools (we'll flesh these out next)
server.tool(
  'get-projects',
  'List all projects for the authenticated user',
  {
    status: z.enum(['active', 'archived', 'all']).optional().default('active'),
    limit: z.number().min(1).max(100).optional().default(20),
  },
  async ({ status, limit }, context) => {
    // Your actual business logic here
    const projects = await fetchProjects(context.auth.userId, { status, limit });
    return {
      content: [
        {
          type: 'text',
          text: JSON.stringify(projects, null, 2),
        },
      ],
    };
  }
);

const handler = httpTransport(server, {
  sessionManagement: true,
  cors: {
    origin: '*', // Lock this down in production
  },
});

export const GET = handler;
export const POST = handler;
export const DELETE = handler;

SSE-Endpunkt für Streaming

Einige MCP-Clients bevorzugen den SSE-Transport für lang laufende Operationen:

// app/api/mcp/sse/route.ts
import { sseTransport } from '@modelcontextprotocol/sdk/server/sse';
import { server } from '../mcp-server'; // Extract server config to shared module

export const GET = sseTransport(server, {
  // Vercel has a 30-second timeout on Hobby, 300s on Pro
  // For long-running tools, you'll need Pro plan minimum
  keepAliveInterval: 15000,
});

Implementieren von MCP-Tools und Ressourcen

Das ist, wo die echte Arbeit passiert. MCP unterscheidet zwischen Tools (Aktionen, die die KI durchführen kann) und Ressourcen (Daten, die die KI lesen kann). Das richtig zu machen, macht den Unterschied zwischen einem MCP-Server, den KI-Clients lieben, und einem, mit dem sie kämpfen.

Gute Tools entwerfen

Der größte Fehler, den ich sehe: Tools, die zu granular oder zu breit sind. Wenn du 50 kleine Tools offenlegst, werden KI-Modelle überfordert. Wenn du 3 Mega-Tools offenlegst, die jeweils 20 Parameter benötigen, machen Modelle Fehler.

Meine Faustregel: ein Tool pro Benutzerintention. Wenn ein Benutzer sagen würde „zeig mir meine Rechnungen der letzten Zeit", das ist ein Tool. Teile es nicht in list-invoices + filter-invoices + format-invoices auf.

// Good: clear intent, reasonable parameters
server.tool(
  'search-customers',
  'Search for customers by name, email, or account ID. Returns matching customer profiles with recent activity.',
  {
    query: z.string().describe('Search term - can be name, email, or account ID'),
    includeInactive: z.boolean().optional().default(false),
  },
  async ({ query, includeInactive }, context) => {
    const customers = await customerService.search({
      query,
      tenantId: context.auth.tenantId,
      includeInactive,
    });
    
    return {
      content: [{
        type: 'text',
        text: JSON.stringify(customers.map(c => ({
          id: c.id,
          name: c.name,
          email: c.email,
          plan: c.plan,
          mrr: c.mrr,
          lastActive: c.lastActiveAt,
        })), null, 2),
      }],
    };
  }
);

Ressourcen offenlegen

Ressourcen sind schreibgeschützte Daten, die KI-Clients als Kontext abrufen können. Denk daran als Dateien, auf die das Modell verweisen kann:

server.resource(
  'api-docs',
  'Your SaaS API documentation',
  'text/markdown',
  async () => {
    const docs = await fs.readFile('./docs/api-reference.md', 'utf-8');
    return { content: docs };
  }
);

// Dynamic resource with URI template
server.resourceTemplate(
  'project/{projectId}/analytics',
  'Analytics summary for a specific project',
  'application/json',
  async ({ projectId }, context) => {
    const analytics = await analyticsService.getSummary(projectId, context.auth.tenantId);
    return { content: JSON.stringify(analytics) };
  }
);

Authentifizierung und Multi-Tenancy

Das ist der Teil, den alle beim ersten Versuch falsch machen. MCP unterstützt OAuth 2.1 für die Authentifizierung, und wenn du eine Multi-Tenant-SaaS aufbaust, brauchst du das absolut.

OAuth 2.1-Flow für MCP

// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  if (request.nextUrl.pathname.startsWith('/api/mcp')) {
    const authHeader = request.headers.get('authorization');
    
    if (!authHeader?.startsWith('Bearer ')) {
      return NextResponse.json(
        { error: 'Missing or invalid authorization header' },
        { status: 401 }
      );
    }
    
    // Validate the token and inject tenant context
    // This is where your existing auth system plugs in
  }
}

export const config = {
  matcher: '/api/mcp/:path*',
};

Für den OAuth-Discovery-Endpunkt, den MCP-Clients brauchen:

// app/.well-known/oauth-authorization-server/route.ts
export function GET() {
  return Response.json({
    issuer: 'https://your-saas.com',
    authorization_endpoint: 'https://your-saas.com/oauth/authorize',
    token_endpoint: 'https://your-saas.com/api/oauth/token',
    registration_endpoint: 'https://your-saas.com/api/oauth/register',
    scopes_supported: ['mcp:read', 'mcp:write', 'mcp:admin'],
    response_types_supported: ['code'],
    code_challenge_methods_supported: ['S256'],
  });
}

Multi-Tenant-Isolation

Jede MCP-Tool-Invokation muss auf den authentifizierten Tenant begrenzt sein. Ich verwende ein Muster, bei dem der Auth-Kontext automatisch in jeden Tool-Handler injiziert wird:

const withTenant = (handler) => async (params, context) => {
  const tenant = await resolveTenant(context.auth.token);
  if (!tenant) throw new McpError('Invalid tenant');
  return handler(params, { ...context, tenant });
};

Vertraue nicht auf Tool-Parameter für die Tenant-Identifizierung. Leite sie immer vom Auth-Token ab.

Bereitstellen auf Vercel: Konfiguration und Fallstricke

vercel.json-Konfiguration

{
  "functions": {
    "app/api/mcp/route.ts": {
      "maxDuration": 60
    },
    "app/api/mcp/sse/route.ts": {
      "maxDuration": 300
    }
  },
  "headers": [
    {
      "source": "/api/mcp/(.*)",
      "headers": [
        { "key": "Cache-Control", "value": "no-store" }
      ]
    }
  ]
}

Die Fallstricke, die niemand dir sagt

1. Funktions-Timeouts. Vercels Hobby-Plan maxiert bei 30 Sekunden. Pro gibt dir 300 Sekunden. Für MCP-Tools, die langsame APIs aufrufen oder Daten verarbeiten, brauchst du mindestens Pro. Bei $20/Monat pro Teammitglied ist es für die meisten SaaS-Teams kein großes Problem.

2. Cold Starts. Serverlose Cold Starts können 200-800ms zu der ersten Anfrage hinzufügen. MCP-Clients handhaben das generell gut – sie erwarten keine Sub-50ms-Antworten. Aber wenn es dich stört, verwende Vercels Cron, um Funktionen warm zu halten.

3. SSE und Streaming. Vercel unterstützt Streaming-Antworten, aber es gibt Edge-Cases mit ihrer CDN-Schicht. Setze Cache-Control: no-store auf alle MCP-Routen. Ich habe das auf die harte Tour gelernt, als gecachte SSE-Antworten dazu führten, dass Clients veraltete Tool-Listen erhielten.

4. Request-Body-Größe. Vercel begrenzt Request-Body auf 4,5MB auf serverlosen Funktionen. Wenn deine MCP-Tools Datei-Uploads oder große Payloads handhaben, musst du stattdessen signierte Upload-URLs verwenden.

5. Umgebungsvariablen. Vergiss nicht, die öffentliche URL deines MCP-Servers als Env-Variable zu setzen. Während der Entwicklung wirst du etwas wie ngrok oder Vercels Preview-URLs verwenden, aber in der Produktion muss es deine kanonische Domain sein.

# .env.production
MCP_SERVER_URL=https://your-saas.com/api/mcp
MCP_SERVER_NAME=your-saas-mcp

Performance-Optimierung und Skalierung

Caching-Strategien

MCP-Tool-Antworten können gecacht werden, wenn sich die Daten nicht häufig ändern:

import { unstable_cache } from 'next/cache';

const getCachedAnalytics = unstable_cache(
  async (tenantId: string, projectId: string) => {
    return analyticsService.getSummary(tenantId, projectId);
  },
  ['analytics-summary'],
  { revalidate: 300 } // 5 minutes
);

Connection Pooling

Wenn deine MCP-Tools eine Datenbank treffen, verwende Connection Pooling. Auf Vercel bekommt jede Funktionsaufruft seinen eigenen Ausführungskontext, daher wirst du ohne Pooling schnell Datenbankverbindungen erschöpfen.

import { Pool } from '@neondatabase/serverless';

// Neon's serverless driver handles pooling automatically
const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
});

Ich würde Neon oder PlanetScale für datenbankgestützte MCP-Tools auf Vercel empfehlen. Beide handhaben das serverlose Verbindungsmodell gut.

Benchmarks

Hier ist, was wir über mehrere Produktions-MCP-Bereitstellungen auf Vercel Pro gemessen haben:

Metrik Cold Start Warm P99
Einfaches Tool (keine DB) 420ms 45ms 180ms
DB-gestütztes Tool (Neon) 680ms 95ms 320ms
Tool mit externer API 850ms 280ms 1200ms
SSE-Verbindungsaufbau 520ms 60ms 250ms
Tool-Discovery (Liste) 380ms 30ms 120ms

Diese Zahlen sind gut für KI-Client-Interaktionen. Modelle brauchen ohnehin Sekunden, um Antworten zu generieren – dein MCP-Server wird nicht der Engpass sein.

Monitoring und Observability

Du musst wissen, was in der Produktion passiert. MCP-Server haben einzigartige Observability-Anforderungen, weil die „Benutzer" KI-Modelle sind, keine Menschen.

Was man verfolgen sollte

  • Tool-Aufrufs-Häufigkeit – welche Tools verwenden Modelle tatsächlich?
  • Fehlerrate pro Tool – schlägt ein spezifisches Tool häufiger fehl?
  • Token/Tenant-Verteilung – hämmert ein Tenant deinen Server?
  • Response-Payload-Größen – überdimensionierte Antworten verschwenden Modell-Kontextfenster
// Simple logging middleware for MCP tools
const withLogging = (toolName: string, handler: Function) => {
  return async (params: any, context: any) => {
    const start = performance.now();
    try {
      const result = await handler(params, context);
      const duration = performance.now() - start;
      
      console.log(JSON.stringify({
        type: 'mcp_tool_invocation',
        tool: toolName,
        tenant: context.auth?.tenantId,
        duration,
        success: true,
        responseSize: JSON.stringify(result).length,
      }));
      
      return result;
    } catch (error) {
      console.error(JSON.stringify({
        type: 'mcp_tool_error',
        tool: toolName,
        tenant: context.auth?.tenantId,
        error: error.message,
      }));
      throw error;
    }
  };
};

Leite diese Logs an Axiom (Vercels integriertes Logging), Datadog oder das weiter, was du bereits verwendest. Vercels integrierte Log Drains machen dies unkompliziert.

Kostenanalyse: MCP-Server auf Vercel betreiben

Lass uns über Geld sprechen. Hier ist eine realistische Kostenaufschlüsselung für eine mittelgroße SaaS, die einen MCP-Server auf Vercel 2026 betreibt:

Komponente Hobby Pro Enterprise
Basis-Plan $0/mo $20/mo pro Sitz Benutzerdefiniert
Funktionsaufrufe (enthalten) 100K 1M Benutzerdefiniert
Zusätzliche Aufrufe N/A $0,60 pro 1M Verhandelbar
Bandbreite (enthalten) 100GB 1TB Benutzerdefiniert
Max. Funktionsdauer 30s 300s 900s
Edge Middleware Enthalten Enthalten Enthalten
Geschätzt monatlich (10K MCP-Anfragen/Tag) Nicht praktikabel ~$25-40 Benutzerdefiniert

Für die meisten SaaS-Produkte handhaben der Pro-Plan MCP-Traffic komfortabel. Bei 10.000 MCP-Tool-Aufrufen pro Tag (was ziemlich aktiv ist), sprichst du von ~300K Funktionsausführungen pro Monat – gut innerhalb der Proplans Zuteilung.

Vergleich das mit dem Betrieb eines dedizierten MCP-Servers auf AWS: Du brauchst mindestens eine EC2-Instanz ($30-50/mo), einen Load Balancer ($18/mo), und deine Zeit, um die Infrastruktur zu verwalten. Vercel gewinnt bei operativer Einfachheit.

Wenn du die richtige Architektur für deine SaaS evaluierst, können wir dir helfen, diese auszuloten. Sieh dir unsere Preisseite an oder kontaktiere uns direkt.

FAQ

Was ist das Model Context Protocol (MCP) und wie unterscheidet es sich vom Function Calling?

MCP ist ein offener Standard zum Verbinden von KI-Modellen mit externen Tools und Daten. Im Gegensatz zu Provider-spezifischem Function Calling (OpenAI's Function Calling, Anthropics Tool Use) ist MCP universell. Du erstellst einen MCP-Server, und jeder kompatible Client – Claude, Cursor, benutzerdefinierte Apps – kann deine Tools automatisch entdecken und verwenden. Function Calling erfordert, dass du Tools separat für jeden KI-Provider definierst.

Kann ich einen MCP-Server auf Vercels kostenlosem Hobby-Plan bereitstellen?

Technisch ja, aber ich würde es nicht für die Produktion empfehlen. Das 30-Sekunden-Funktions-Timeout ist zu restriktiv für MCP-Tools, die Datenbanken abfragen oder externe APIs aufrufen. Du erhältst auch begrenzte Aufrufe (100K/Monat). Der Pro-Plan zu $20/Monat pro Sitz ist das Minimum, das ich für jede echte Workload vorschlagen würde.

Wie handhabe ich die Authentifizierung zwischen MCP-Clients und meiner SaaS?

Die MCP-Spezifikation unterstützt OAuth 2.1. Du exponierst einen .well-known/oauth-authorization-server-Endpunkt, den MCP-Clients automatisch entdecken. Wenn ein Benutzer sich über einen KI-Client wie Claude verbindet, wird er zu deinem Standard-OAuth-Flow umgeleitet, erteilt Berechtigungen, und der Client erhält einen Scoped-Access-Token. Dieser Token wird mit jeder MCP-Anfrage gesendet.

Was ist der Unterschied zwischen MCP-Tools und MCP-Ressourcen?

Tools sind Aktionen – Dinge, die die KI tun kann (ein Projekt erstellen, eine E-Mail senden, eine Abfrage ausführen). Ressourcen sind Daten – Dinge, die die KI zum Kontextualisieren lesen kann (Dokumentation, Konfigurationsdateien, Analytikssammlungen). Tools werden auf Abruf aufgerufen; Ressourcen werden in das Kontextfenster des Modells geladen. Entwerfe Tools für Aktionen, Ressourcen für Referenzmaterial.

Wie viele MCP-Tools sollte mein Server offenlegen?

Aus meiner Erfahrung sind 5-15 Tools das Sweet Spot für die meisten SaaS-Produkte. Weniger als 5 und dein MCP-Server ist nicht sehr nützlich. Mehr als 20 und KI-Modelle beginnen, schlechte Tool-Auswahlentscheidungen zu treffen. Gruppiere verwandte Operationen in einzelne Tools mit Parameteroptionen, anstatt jede CRUD-Operation separat offenzulegen.

Funktioniert das mit anderen Frameworks außer Next.js?

Absolut. Das @modelcontextprotocol/sdk funktioniert mit jedem Node.js-Framework. Du könntest Hono, Express oder sogar Astro mit SSR-Endpunkten verwenden. Next.js auf Vercel ist nur eine besonders praktische Kombination wegen der eingebauten Streaming-Unterstützung, Edge-Middleware und Zero-Config-Bereitstellung. Falls du einen anderen Stack verwendest, hat unser Headless-CMS-Entwicklungs-Team MCP-Server über mehrere Frameworks gebaut.

Wie teste ich meinen MCP-Server während der Entwicklung?

Der MCP Inspector (Teil des offiziellen MCP-Toolkits) ist dein bester Freund. Er verbindet sich mit deinem lokalen Server und lässt dich Tools aufrufen, Ressourcen durchsuchen und Antworten interaktiv debuggen. Für automatisierte Tests schreib Integrationstests, die deinen MCP-Server in Prozess instanziieren und Tools programmatisch aufrufen – das SDK unterstützt dies ohne HTTP-Transport zu brauchen.

Was passiert, wenn Vercel-Funktionen während einer MCP-Anfrage einen Cold Start haben?

MCP-Clients sind entworfen, um tolerant gegenüber Latenz zu sein – sie warten typischerweise auf KI-Modell-Antworten, die ohnehin Sekunden dauern. Ein 400-800ms Cold Start ist in der Praxis unmerklich. Wenn du dir Sorgen machst, lässt dich Vercels Pro-Plan Cron-basiertes Warming konfigurieren, und das SDK enthält automatische Retry-Logik für transiente Fehler. In sechs Monaten Produktionsnutzung waren Cold Starts nie ein von Benutzern gemeldetes Problem für unsere Clients.