Hat deine App einen MCP-Server? Der 2-Minuten-Check

Die kurze Antwort: Ob eine App einen MCP-Server hat, findest du meist in unter zwei Minuten heraus, mit vier Checks: Anbieter-Doku, Verzeichnis-Lookup, Changelog-Suche und ein paar vorhersehbare URLs. "Hat meine App einen MCP-Server" ist eine Frage ohne kanonische Antwortseite, weil MCP-Support App für App auslief, oft still, durch 2025 und 2026 hindurch. Daher diese Routine.

Falls unscharf ist, wonach du überhaupt suchst, lies zuerst [Was ist ein MCP-Server?](/de/blog/what-is-an-mcp-server). Dauert fünf Minuten.

Der 2-Minuten-Check: Hat deine App einen MCP-Server?

Geh die Schritte der Reihe nach durch. Meistens entscheidet Schritt 1 oder 2.

Schritt 1: Anbieter-Doku durchsuchen (30 Sekunden). Such im Web nach dem App-Namen plus "MCP server" oder "Model Context Protocol", und probier dann die Suche der Doku-Seite mit nur "MCP". Offizielle Server sind dokumentiert, meist unter Developers, API oder Integrationen. Ein dokumentierter Server ist das beste Ergebnis: Endpunkt, Auth-Geschichte und Support-Kanal an einer Stelle.

Schritt 2: In einem MCP-Verzeichnis nachschlagen (30 Sekunden). Ein Verzeichnis macht aus der Frage eine Suche. Das [Tulimoa-Verzeichnis](/de/discover) ist kostenlos nutzbar und lässt dich Listings nach MCP-Support filtern; "hat dieses CRM einen Server" wird zum Filter-Klick. Verzeichnisse fangen auch, was Doku-Suchen verpassen: Community-Server, und Apps, die Support ausgeliefert haben, ohne es jemandem zu sagen. Mehr Quellen stehen im Guide [MCP-Server finden](/de/blog/find-mcp-servers).

Schritt 3: Changelog nach "MCP" durchsuchen (30 Sekunden). Viele SaaS haben MCP-Support als Release-Notiz statt als Launch-Seite ergänzt. Öffne Changelog oder Release Notes des Anbieters und such auf der Seite nach "MCP". Das fängt Server, die live, aber kaum vermarktet sind, und das passiert öfter, als man denkt.

Schritt 4: Die vorhersehbaren URLs probieren (30 Sekunden). Remote-Server wohnen gern an erratbaren Adressen. Die zwei üblichen Muster sind mcp.anbieter.com/mcp und anbieter.com/mcp; unserer liegt auf mcp.tulimoa.com/mcp, um ein Beispiel zu nennen, für das wir bürgen können. Manche Anbieter veröffentlichen zudem Discovery-Metadaten unter einem /.well-known-Pfad, eine Konvention, die sich verbreitet, seit MCP v2 final ist. Antwortet eine Adresse auf den MCP-Handshake deines Clients, hast du deine Antwort.

Das ist die ganze Routine. Zwei Minuten, vier Checks, am Ende ein klares Ja oder Nein.

Offizieller MCP-Server oder Community-Server?

Der Check oben findet beide Sorten, und der Unterschied zählt mehr, als er aussieht.

Einen offiziellen MCP-Server baut und pflegt der Anbieter. Er folgt der echten API des Produkts, der Auth-Flow ist dokumentiert, und wenn er bricht, ist die Reparatur jemandes Job. Durch 2025 und 2026 wurden offizielle Server von der Neuheit zu etwas nahe am Standard: Viele beliebte SaaS liefern inzwischen einen, und die Liste wächst.

Einen Community-Server baut ein Dritter gegen die öffentliche API des Anbieters. Manche sind hervorragend. Aber bevor du einem deine Zugangsdaten gibst, prüf drei Dinge: wer ihn pflegt und wann das letzte Update kam, wie er deinen API-Key oder dein Token speichert und überträgt, und welche Scopes er wirklich anfragt. Ein aufgegebener Community-Server mit breiten Scopes ist genau die stille Sorte Risiko, die wir in [MCP-Sicherheit](/de/blog/mcp-security-basics) durchgehen.

Existieren beide, nimm den offiziellen, außer du hast einen konkreten Grund dagegen.

Was tun, wenn die Antwort nein ist

Gar kein Server? Drei Optionen, grob nach Präferenz sortiert.

Die API überbrücken. Hat die App eine brauchbare REST-API, wickle sie ein. Mehrere Tools generieren einen MCP-Server aus einer OpenAPI-Spec, und einen dünnen Server um die zwei, drei Endpunkte zu schreiben, die du wirklich brauchst, ist ein Nachmittagsprojekt, kein Plattform-Bau. Du verlierst Anbieter-Support, behältst aber volle Kontrolle über Scopes und Umgang mit Zugangsdaten.

Einen Community-Server übernehmen, vorsichtig. Wende die drei Checks oben an, gewähre die engsten verfügbaren Scopes und widerrufe den Zugriff, sobald das Projekt einschläft.

Den Anbieter fragen. Stell den Feature-Request und sag warum: "Unsere Agenten müssen euer Produkt erreichen" ist ein Satz, den Anbieter zunehmend ernst nehmen, weil Agent-Fähigkeit zum Kaufkriterium wird. Sitzt du auf der Anbieter-Seite dieses Gesprächs, zeigt unsere [Agent-ready-SaaS-Checkliste](/de/blog/agent-ready-saas-checklist), was ein eigener Server konkret bedeutet.

Häufige Fragen

Woran erkenne ich, ob ein MCP-Server offiziell ist?

Er ist auf der Domain des Anbieters dokumentiert und läuft typischerweise auf dessen Infrastruktur, unter einer Adresse wie mcp.anbieter.com. Ist die einzige Spur eines Servers ein Dritt-Repository, behandle ihn als Community-Server und prüf entsprechend.

Gibt es eine Standard-URL für MCP-Server?

Keine vorgeschriebene, aber Konventionen haben sich gesetzt. Die meisten Remote-Server liegen auf mcp.anbieter.com/mcp oder anbieter.com/mcp, und /.well-known-Discovery-Metadaten werden häufiger, seit MCP v2 final ist. Die Doku des Anbieters bleibt die verbindliche Quelle.

Was, wenn die App nur einen lokalen MCP-Server hat?

Auch das zählt als MCP-Support. Einen lokalen Server betreibst du auf deiner eigenen Maschine und installierst ihn selbst, ein Remote-Server ist nur eine URL für deinen Client. Lokal ist bei Entwickler-Tools üblich; Remote ist bei SaaS zum Default geworden.

Kann mein Agent eine App ganz ohne MCP-Server nutzen?

Ja, über die rohe API per Function Calling oder eine OpenAPI-zu-MCP-Brücke. Es funktioniert, aber die Wartung gehört dir: Schema-Änderungen, Auth-Refresh und Fehlerbehandlung landen bei dir statt beim Anbieter.