Ein Agent kann bereits in deinem Repo arbeiten: Code durchsuchen, Dateien bearbeiten, Befehle ausführen und im Web stöbern. Aber er hat keinen Zugriff auf deinen Error-Tracker, deine Datenbank, Tickets oder Dokumentation. Solange diese nicht verbunden sind, kommt er bei allem ins Stocken, was außerhalb des Editors liegt.

Das Model Context Protocol (MCP) ist ein offener Standard, der einen Agent mit externen Tools und Daten verbindet. Verbinde einen MCP-Server, und der Agent fragt die Datenbank ab, statt dich nach dem Schema zu fragen. Er öffnet das Ticket, statt zu beschreiben, was darin stehen sollte.

Dieser Zugriff unterscheidet einen Agent, auf den sich dein Team verlässt, von einem, der Code isoliert schreibt. Deshalb gehört eine MCP-Strategie für Agenten zu den ersten Themen, die Teams klären müssen. Dieser Leitfaden erklärt, was MCP für Agenten in der Praxis leistet, welche Server sich zuerst anzubinden lohnen und wie du in wenigen Minuten einen hinzufügst.

#Warum Agenten echten Tool-Zugriff benötigen

Die Arbeit verlagert sich vom Schreiben von Code hin zum Durchlaufen der Schleife drumherum, und Agenten greifen bereits auf mehr Tools zu, um genau das zu tun. In unserer Nutzung stieg die durchschnittliche Zahl der Tool-Aufrufe pro Sitzung in einem jüngsten Zeitraum von zwei Monaten um etwa 30 %, da Agenten innerhalb einer einzelnen Aufgabe häufiger Dateien lesen, Code durchsuchen, Befehle ausführen und im Web stöbern.

Jeder dieser Tool-Aufrufe ist eine Stelle, an der entweder eine Integration vorhanden ist oder der Agent vor einer Wand steht. MCP verwandelt jeden dieser Aufrufe in eine funktionierende Verbindung statt in eine Sackgasse. Das intelligenteste Modell der Welt kann dir nicht sagen, warum das Staging-Deployment fehlgeschlagen ist, wenn es deinen Error-Tracker nicht sehen kann. Wenn du dasselbe Modell an den Tracker, die Datenbank und die Issue-Queue anbindest, kann es das gesamte Problem oft vom Symptom bis zur Behebung vorantreiben. MCP macht diese Verbindungen portabel, sodass ein Server, den du einmal einrichtest, über die Agenten und Oberflächen hinweg funktioniert, die dein Team benötigt.

#Fragen vor dem Verbinden

Wenn du Agent MCP zum ersten Mal einrichtest, solltest du diese Punkte klären, bevor du mit der Installation von Servern beginnst.

#Was ist ein MCP-Server?

Ein MCP-Server ist ein kleiner Adapter, der ein Tool oder eine Datenquelle (eine Datenbank, eine API, ein SaaS-Produkt) über das Model Context Protocol verfügbar macht, sodass jeder MCP-fähige Agent ihn nutzen kann. In einem MCP-Setup für einen Agenten ist der Agent der Client und der Server der Connector. MCP-Server stellen Funktionen wie Tools, Prompts und Ressourcen über das Protokoll bereit. In der Praxis schreibst du die meisten davon nicht selbst: Der Anbieter liefert einen aus, oder die Community tut das, und du konfigurierst deinen Agent so, dass er ihn nutzt.

#Worin unterscheidet sich MCP von einem Plugin oder einer normalen API-Integration?

Ein Plugin ist für eine einzelne App entwickelt. Eine direkte API-Integration ist für ein bestimmtes Systempaar ausgelegt, und für den nächsten Agenten musst du sie wieder neu erstellen. MCP ist die standardisierte Schicht dazwischen, sodass ein einmal geschriebener Server mit jedem Client funktioniert, der das Protokoll spricht. Verbinde Sentry oder Postgres über MCP, und es funktioniert in Cursor genauso wie in jedem anderen MCP-Client, ohne dass jedes Mal eine individuelle Integration nötig ist.

#Führt der Agent diese Tools eigenständig aus?

Er nutzt sie im Rahmen seiner Arbeit und nur mit dem Zugriff, den du ihm gewährst. Du entscheidest, welche Server du installierst, und bei allem Sensiblen authentifizierst du dich über OAuth, damit der Server nur auf das zugreifen kann, worauf auch dein Konto Zugriff hat. Remote-Server können sich über OAuth authentifizieren, wenn der Server dies erfordert, oder über Header und API-Schlüssel; lokale Server werden als Shell-Befehl auf deiner Maschine ausgeführt. Der Agent erhält einen klar definierten Satz an Tools, keinen Blankoscheck für deine Systeme.

#Was unterscheidet einen guten MCP-Server von einem überladenen?

Die guten geben dem Agent eine klar abgegrenzte Auswahl gut benannter Aktionen, damit er weiß, wann er sie einsetzen sollte. Die schlechten packen Dutzende Tools mit geringem Mehrwert in jeden Prompt, blähen das Kontextfenster mit ungenutzten Tool-Beschreibungen auf, was sich mit jedem hinzugefügten Server verstärkt. Fang mit Servern für die Systeme an, die du während einer Aufgabe tatsächlich nutzt – deine Datenbank, deinen Error-Tracker, alles, zwischen dem du ständig per Alt-Tab wechselst – und füge weitere nur hinzu, wenn ein echter Workflow danach verlangt.

#Die besten MCP-Server für Cursor nach Anwendungsfall

Der Cursor Marketplace listet offizielle Plugins, die sich mit einem Klick installieren lassen und einen MCP-Server mitbringen (oft zusammen mit Regeln und Skills). Das sind die MCP-Server, die du am besten zuerst verbindest — gruppiert nach Anwendungsfall.

Datenbanken. Gib dem Agenten Lesezugriff (und vorsichtigen Schreibzugriff) auf dein Schema und deine Daten, damit er nicht mehr über deine Tabellen rätseln muss.

• Supabase: Tabellen verwalten, Konfiguration abrufen und Daten projektübergreifend in deinen Supabase-Projekten abfragen.
• MongoDB: Mit Datenbanken verbinden, Daten untersuchen, Collections verwalten und Abfragen optimieren.
• Neon Postgres: Neon-Projekte und -Datenbanken über den Neon MCP-Server verwalten.
• Prisma: MCP-Server, Regeln und Skills für die Datenbankentwicklung.

Entwicklungs-Workflows. Binde den Agenten in die Tools ein, in denen Arbeit geplant, ausgeliefert und überwacht wird.

• Linear: Issues, Projekte und Dokumente in deinem Linear-Workspace verwalten.
• Sentry: Fehler und Traces abrufen, damit der Agent anhand echter Produktionsprobleme debuggen kann.
• GitLab: Issues, Merge Requests und Pipelines direkt im Editor planen und verwalten.
• Datadog: Logs, Metriken, Traces und Dashboards über einen vorkonfigurierten MCP-Server abfragen (in der Vorschau).

Hinweis: GitHub ist nicht in der MCP-Liste aufgeführt, da es eine native Cursor-Integration ist. Die Cursor GitHub app verbindet deine Repositories über das Dashboard, damit Features wie Cloud-Agent und Bugbot mit deinen PRs arbeiten können. Du verbindest sie einmal unter Integrationen, statt sie über mcp.json hinzuzufügen.

Browser-Automatisierung. Lass den Agenten einen echten Browser steuern, um zu testen, Bugs zu reproduzieren und Live-Daten abzurufen.

• Browserbase Browse: Navigieren, klicken, Formulare ausfüllen, Daten extrahieren und Screenshots aufnehmen — gesteuert über MCP.
• BrowserStack: Websites und mobile Apps auf echten Geräten testen und Fehler beheben.
• Bright Data: Websuche, Content-Extraktion und Browser-Automatisierung über eine Webdaten-Plattform.

Dokumentation abrufen. Sorge dafür, dass der Agent mit aktueller, versionsspezifischer Dokumentation arbeitet statt mit veralteten Trainingsdaten.

• Context7: Aktuelle, versionsspezifische Dokumentation und Codebeispiele direkt in den Kontext holen.
• Notion: Die Dokumentation, Spezifikationen und Anforderungen deines Teams in den Coding-Workflow einbringen.

Der Marketplace bietet noch viele weitere Einträge (Figma, Stripe, Postman und andere) — stöbere also nach deinem Stack. Neue Server kommen regelmäßig dazu.

#So fügst du einen MCP-Server in Cursor hinzu

Zwei Wege: per Klick aus dem Marketplace oder über eine kleine Konfigurationsdatei für alles Individuelle.

Mit einem Klick. Klicke bei einem Eintrag im Marketplace auf Add to Cursor, um den Server zu installieren und dich per OAuth zu authentifizieren. Das ist der schnellste Weg, die oben genannten Server zu verbinden.

Konfigurationsdatei. Füge einen benutzerdefinierten oder selbstgehosteten Server zu mcp.json hinzu. Verwende .cursor/mcp.json in einem Projekt für projektspezifische Tools oder ~/.cursor/mcp.json in deinem Home-Verzeichnis für Tools, die überall verfügbar sind. Ein lokaler (befehlsbasierter) Server sieht so aus:

{
  "mcpServers": {
    "server-name": {
      "command": "npx",
      "args": ["-y", "mcp-server"],
      "env": {
        "API_KEY": "value"
      }
    }
  }
}

Bei einem Remote-Server (HTTP oder SSE) wird stattdessen eine URL verwendet:

{
  "mcpServers": {
    "server-name": {
      "url": "http://localhost:3000/mcp",
      "headers": {
        "API_KEY": "value"
      }
    }
  }
}

Für Teams. Admins können Team-MCP-Server einmal über das Dashboard für Cloud-Agenten konfigurieren und dieselben Server mit einem Team-Marketplace für das Agents-Fenster, die IDE und die CLI verknüpfen. Teammitglieder müssen sie möglicherweise weiterhin installieren und sich authentifizieren, müssen mcp.json aber nicht jeweils manuell bearbeiten.

Die Dokumentation behandelt Transportmechanismen, Authentifizierung und die vollständige Konfigurationsreferenz. Folge der Anleitung unter cursor.com/docs/mcp.

#Eigenen MCP-Server erstellen

Falls es für deinen internen Service noch keinen Server gibt, kannst du selbst einen erstellen. Schreibe ihn in einer beliebigen Sprache, die nach stdout ausgeben oder einen HTTP-Endpunkt bereitstellen kann, und stelle eine kleine Auswahl gut benannter Tools bereit, die deine API kapseln.

Am schnellsten geht es, wenn du den Agent damit beauftragst. Gib Cursor die API-Referenz, die OpenAPI-Spezifikation oder die Client-Bibliothek deines Service und bitte ihn, einen MCP-Server für die Endpunkte zu erstellen, die dir wichtig sind. Er kann das Schema lesen, für jedes Tool das JSON-Schema und den Handler generieren und die Authentifizierung einrichten, sodass du nur noch prüfen und verfeinern musst, statt mit einer leeren Datei zu beginnen. Halte die Tool-Auswahl klein, benenne jede Aktion eindeutig und füge den Server genauso zu mcp.json hinzu wie einen Drittanbieter-Server.

#Integriere es in den Stack, den du bereits nutzt

Ein Modell allein kann Code schreiben. Ein Agent, der per MCP mit den Systemen verbunden ist, mit denen du arbeitest, führt eine Aufgabe vom Ticket bis zum Fix und überprüft seine eigene Arbeit unterwegs. MCP macht diese Verbindungen über die von dir genutzten Tools hinweg portierbar. Wähle die zwei oder drei Server aus, die zu deinem Stack passen, verbinde sie und gib dem Agent direkten Zugriff auf die Systeme, zu denen du immer wieder wechselst.