Einführung

MCP-Server ermöglichen dir, eigene Datenquellen anzubinden und sie in Cursor nutzbar zu machen. Das ist besonders hilfreich, wenn du Kontext aus Browsern, Datenbanken oder Fehler- und Systemlogs brauchst. Das Einrichten eines MCP-Servers ist unkompliziert und mit Cursor schnell erledigt. In diesem Guide gehen wir durch, wie man einen MCP-Server für Postgres baut. Unser Ziel ist, dass Cursor SQL-Abfragen direkt gegen eine Postgres-Datenbank ausführen kann und Tabellenschemata strukturiert bereitstellt.
Dieses Tutorial vermittelt die Grundlagen zum Aufbau von MCP-Servern.

Was ist ein MCP-Server?

Ein MCP-Server ist ein Prozess, der mit Cursor kommuniziert und Zugriff auf externe Daten oder Aktionen bereitstellt. Er kann auf mehrere Arten implementiert werden, aber hier verwenden wir die einfachste Methode: einen Server, der lokal auf deinem Rechner über stdio (Standard-Ein-/Ausgabeströme) läuft. Das vermeidet komplizierte Sicherheitsüberlegungen und erlaubt uns, uns auf die MCP-Logik selbst zu konzentrieren. Einer der häufigsten Anwendungsfälle für MCP ist der Datenbankzugriff. Beim Bauen von Dashboards, beim Ausführen von Analysen oder beim Erstellen von Migrationen ist es oft nötig, eine Datenbank zu queryen und zu inspizieren. Unser Postgres-MCP-Server wird zwei Kernfunktionen unterstützen: das Ausführen beliebiger Queries und das Auflisten von Tabellenschemata. Auch wenn beide Aufgaben mit purem SQL erledigt werden könnten, bietet MCP Features, die sie leistungsfähiger und allgemein nützlicher machen. Tools bieten eine Möglichkeit, Aktionen wie das Ausführen von Queries bereitzustellen, während Ressourcen es ermöglichen, standardisierten Kontext wie Schema-Informationen zu teilen. Später in diesem Guide schauen wir uns auch Prompts an, die fortgeschrittenere Workflows ermöglichen. Unter der Haube setzen wir auf das npm-Paket postgres, um SQL-Statements gegen die Datenbank auszuführen. Das MCP-SDK dient als Wrapper um diese Calls und ermöglicht es uns, Postgres-Funktionalität nahtlos in Cursor zu integrieren. [Platzhalter: Illustration eines MCP-Servers mit Tools und Ressourcen]

So baust du den MCP-Server

Der erste Schritt beim Bauen des Servers ist, ein neues Projekt aufzusetzen. Wir starten damit, einen neuen Ordner zu erstellen und ein Bun-Projekt zu initialisieren:
> mkdir postgres-mcp-server
> Bun init
Danach wählen wir das Blank-Projekt. Sobald das Boilerplate steht, installieren wir die benötigten Abhängigkeiten. zod wird benötigt, um Schemas für I/O im MCP-SDK zu definieren.
bun add postgres @modelcontextprotocol/sdk zod
Als Nächstes schauen wir in die Repositories der jeweiligen Libraries und holen uns die Links zu den Raw-Inhalten der jeweiligen README-Dateien. Die nutzen wir als Kontext beim Bauen des Servers: Jetzt definieren wir, wie sich der Server verhalten soll. Dafür erstellen wir eine spec.md und schreiben die High-Level-Ziele auf:
# Spec

- Allow defining DATABASE_URL through MCP env configuration
- Query postgres data through tool
  - By default, make it readonly
  - Allow write ops by setting ENV `DANGEROUSLY_ALLOW_WRITE_OPS=true|1`
- Access tables as `resources`
- Use Zod for schema definitions
Wie du siehst, ist das eine ziemlich schlanke Spec. Fühl dich frei, bei Bedarf mehr Details hinzuzufügen. Zusammen mit den README-Links bauen wir daraus den finalen Prompt:
Read the following and follow @spec.md to understand what we want. All necesary dependeies are installed
- @https://raw.githubusercontent.com/modelcontextprotocol/typescript-sdk/refs/heads/main/README.md
- @https://raw.githubusercontent.com/porsager/postgres/refs/heads/master/README.md
Mit diesen drei Bausteinen (der Spezifikation, der MCP-SDK-Dokumentation und der Postgres-Bibliotheksdokumentation) können wir Cursor nutzen, um die Server-Implementierung zu scaffolden. Cursor hilft uns, die Teile zusammenzufügen und den Code zu generieren, der das MCP-SDK mit Postgres verbindet. Nach etwas Hin und Her beim Prompting haben wir jetzt eine erste Version des MCP-Servers am Laufen. Um ihn auszuprobieren, können wir den MCP Inspector verwenden:
npx @modelcontextprotocol/inspector bun run index.ts

Testen des MCP-Servers

Sobald die erste Implementierung fertig ist, kannst du sie mit dem MCP Inspector testen. Der Inspector zeigt dir, was der Server bereitstellt, und hilft zu verifizieren, dass sich Tools und Ressourcen wie erwartet verhalten. Du solltest prüfen, dass Abfragen ausgeführt werden können und Schemainformationen korrekt zurückgegeben werden. MCP Inspector interface Wenn alles gut aussieht, kannst du den Server mit Cursor verbinden und ihn in einer realen Umgebung testen. Ab diesem Zeitpunkt kann Cursor den Postgres-MCP-Server wie eine integrierte Funktion nutzen, sodass du die Datenbank direkt abfragen und inspizieren kannst.

Nächste Schritte

Die lokale Ausführung des MCP-Servers über stdio ist ein guter Start, aber Teams brauchen oft gemeinsamen Zugriff auf dieselbe Datenbank über ihren MCP-Server. In solchen Fällen ist es sinnvoll, den MCP-Server als zentralen HTTP-Dienst zu deployen. Ein deployter MCP-Server bietet mehrere Vorteile gegenüber einzelnen stdio-Instanzen:
  • Gemeinsamer Datenbankzugriff: Mehrere Teammitglieder können über Cursor dieselbe Datenbankinstanz abfragen
  • Zentralisierte Konfiguration: Schema-Updates und Berechtigungsänderungen werden an einem Ort verwaltet
  • Erhöhte Sicherheit: Saubere Authentifizierung, Rate Limiting und Zugriffskontrollen lassen sich implementieren
  • Observability: Nutzungsmuster und Performance-Metriken können teamweit überwacht werden
Dafür stellst du die Transportmethode von stdio auf HTTP um. Wir gehen zwar nicht auf die komplette Einrichtung ein, aber hier ist ein guter Start-Prompt, den du Cursor geben kannst
Based on the existing MCP server, create a new file that implements the HTTP protocol.

Move shared logic to mcp-core, and name each transport implementation by name (mcp-server-stdio, mcp-server-http)

@https://raw.githubusercontent.com/modelcontextprotocol/typescript-sdk/refs/heads/main/README.md 
Die finalen Ergebnisse findest du hier: pg-mcp-server