# Was ist ein MCP-Server? Definition, Funktion und Praxis

> Ein MCP-Server ist die standardisierte Schnittstelle, über die ein KI-Assistent echte Werkzeuge aufruft, statt zu raten.

Source: https://uptimeify.io/de/blog/was-ist-ein-mcp-server

**Update, 8. September 2026:** Der MCP-Server von Uptimeify hat inzwischen eine kleine Reihe von Schreib-Werkzeugen bekommen, zusätzlich zu allem, was unten beschrieben ist: einen Monitor pausieren, einen Incident quittieren und Ähnliches. Jedes davon hängt an einem eigenen Zustimmungs-Scope, den du getrennt vom Lesezugriff und je Bereich erteilst, das ändert also nichts am Abschnitt zur Sicherheit weiter unten: Die 33 Werkzeuge, die dieser Beitrag beschreibt, sind weiterhin alles, was liest, und ohne diesen gesondert erteilten Scope schreibt nichts. Die aktuelle Werkzeugliste und die Scopes stehen auf der [MCP-Server-Seite](/de/mcp-server).

Ein MCP-Server ist eine standardisierte Schnittstelle, über die ein KI-Assistent echte Werkzeuge aufrufen kann, statt zu raten. Das Model Context Protocol legt dabei fest, wie diese Werkzeuge beschrieben, aufgerufen und beantwortet werden. Statt eine Antwort aus dem Modellgedächtnis zu formulieren, ruft der Assistent ein Tool auf, bekommt ein echtes Ergebnis zurück und arbeitet damit weiter. Dieser Beitrag erklärt die Definition, den Ablauf eines Tool Calls, den Unterschied zur REST-API und was das im Agenturbetrieb praktisch bedeutet.

- Ein MCP-Server stellt einem KI-Assistenten Werkzeuge bereit, die dieser selbstständig aufrufen kann.
- Das Model Context Protocol ist der offene Standard dahinter: Es regelt, wie Werkzeuge beschrieben, aufgerufen und beantwortet werden.
- Der entscheidende Unterschied zur REST-API: Das Tool beschreibt sich selbst, damit das Modell weiß, wann sein Einsatz sinnvoll ist.
- Über Streamable HTTP läuft die Verbindung stateless, es gibt also keinen Sitzungszustand zwischen zwei Aufrufen.
- Praktisch heißt das: Ein Assistent, der `check_ssl` für deinkunde.com aufruft, bekommt Aussteller, Gültigkeitsdaten und Kette zurück, statt zu halluzinieren.

## Was ist ein MCP-Server?

Ein MCP-Server ist ein Dienst, der einem KI-Assistenten eine Menge klar beschriebener Werkzeuge zur Verfügung stellt, die dieser während eines Gesprächs selbstständig aufrufen kann. Er ist damit die Brücke zwischen einem Sprachmodell, das Text produziert, und Systemen, die Fakten liefern: Datenbanken, APIs, Dateisysteme, Netzwerk-Prüfungen.

Das Wort "Server" ist dabei wörtlich gemeint, aber weniger schwer, als es klingt. Ein MCP-Server kann ein kleines lokales Programm auf deinem Rechner sein oder ein öffentlicher HTTP-Endpunkt im Netz. Entscheidend ist nicht, wo er läuft, sondern dass er sich an dasselbe Protokoll hält wie alle anderen.

Drei Rollen greifen ineinander:

- **Der Host** ist die Anwendung, mit der du sprichst, also der Chat-Assistent oder die Entwicklungsumgebung.
- **Der Client** sitzt im Host und hält je eine Verbindung zu einem Server.
- **Der Server** stellt die Werkzeuge bereit und führt sie aus.

Ein Host kann mehrere Server gleichzeitig einbinden. Wer im selben Chat einen Kalender, ein Ticketsystem und Netzwerk-Prüfungen verfügbar macht, hat drei Server verbunden und redet trotzdem nur mit einem Assistenten. Die begriffliche Kurzform steht auch im Glossar unter MCP-Server.

Neben Werkzeugen kennt das Protokoll noch zwei weitere Bausteine: Ressourcen, also Daten, die ein Server zum Lesen anbietet, und Prompts, also vorgefertigte Textbausteine. In der Praxis sind Werkzeuge der Baustein, um den es fast immer geht, und deshalb der Fokus dieses Beitrags.

## Was ist das Model Context Protocol?

Das Model Context Protocol ist der offene Standard, der festlegt, wie Assistenten und Werkzeuge miteinander sprechen. Anthropic hat es 2024 veröffentlicht und offen gelegt, danach haben weitere Anbieter es in ihre Clients aufgenommen. Es beschreibt drei Dinge: wie ein Client erfährt, welche Werkzeuge es gibt, wie er eines aufruft und in welcher Form die Antwort zurückkommt.

Der Nutzen liegt genau in dieser Standardisierung. Vor MCP musste jede Kombination aus Assistent und Werkzeug einzeln verdrahtet werden: eigene Integration je Anbieter, eigene Beschreibung, eigene Fehlerbehandlung. Mit einem gemeinsamen Protokoll baut ein Werkzeug-Anbieter einmal und ist für jeden kompatiblen Client nutzbar, und ein Client-Anbieter unterstützt einmal das Protokoll statt hundert Einzelintegrationen.

Für den Transport gibt es zwei gängige Wege. Lokale Server sprechen häufig über stdio, also über die Standardein- und -ausgabe des Prozesses. Server im Netz sprechen Streamable HTTP. Der zweite Weg ist der interessantere für Anbieter, weil er ohne Installation beim Nutzer auskommt: eine URL genügt.

MCP löst kein Modellproblem, sondern ein Integrationsproblem: einmal bauen statt für jeden Assistenten neu verdrahten.

## Wie funktioniert ein Tool Call konkret?

Ein Tool Call ist der Moment, in dem der Assistent aufhört zu formulieren und anfängt zu prüfen. Am Beispiel einer SSL-Prüfung sieht der Ablauf so aus:

1. **Verbindung und Inventar.** Der Client verbindet sich mit dem Server und fragt die Werkzeugliste ab. Er bekommt Namen, Beschreibungen und Eingabeschemata zurück, also etwa `check_ssl` mit dem Pflichtfeld `host` und dem optionalen Feld `port`.
2. **Die Frage.** Du schreibst "Läuft das Zertifikat von deinkunde.com bald ab?".
3. **Die Auswahl.** Das Modell erkennt anhand der Beschreibung, dass `check_ssl` zu dieser Frage passt, und schlägt den Aufruf mit dem Argument `host: deinkunde.com` vor.
4. **Die Freigabe.** Je nach Client bestätigst du den Aufruf oder er läuft automatisch, wenn du das Werkzeug freigegeben hast.
5. **Die Ausführung.** Der Server baut die Verbindung zur Domain auf, liest das Zertifikat und antwortet mit Aussteller, Gültigkeitsdaten, Ablaufdatum und Zertifikatskette.
6. **Die Antwort.** Das Modell formuliert daraus eine Antwort in deiner Sprache, jetzt aber auf Basis eines gemessenen Ergebnisses.

Der Unterschied zu einer Antwort ohne Werkzeug ist nicht kosmetisch. Ohne Tool Call kann ein Modell zu einem Ablaufdatum nur schätzen oder ausweichen, weil es diese Information nicht besitzt. Mit Tool Call steht ein Datum da, das jemand nachprüfen kann.

Gut gebaute Server liefern die Antwort zweimal: einmal als lesbaren Text und einmal als strukturierte Daten nach einem veröffentlichten Schema. So kann eine Anwendung das Ergebnis maschinell weiterverarbeiten, während ein einfacher Client denselben Text sieht wie vorher.

### Was passiert, wenn ein Aufruf schiefgeht?

Auch das gehört zum Protokoll. Ein Werkzeug kann fehlschlagen, weil eine Domain nicht auflöst, ein Port dicht ist oder ein Limit erreicht wurde. Der Server antwortet dann nicht mit einem leeren Ergebnis, sondern mit einer als Fehler markierten Antwort und einer Meldung im Klartext.

Für dich im Chat ist das der Unterschied zwischen "der Host antwortet nicht auf Port 443" und einer Antwort, die so klingt, als sei alles in Ordnung. Ein Modell, das einen Fehler als Fehler übermittelt bekommt, kann ihn benennen oder den nächsten sinnvollen Schritt vorschlagen. Genau deshalb ist eine saubere Fehlerform Teil des Standards und nicht Sache des jeweiligen Anbieters.

## Wofür braucht man einen MCP-Server im Betrieb?

Der Nutzen zeigt sich dort, wo heute Kontextwechsel Zeit kosten. Eine Agentur, die 40 Kundenseiten betreut, prüft täglich Kleinigkeiten, für die niemand ein Dashboard öffnen will. Genau diese Prüfungen lassen sich in den Chat holen, in dem ohnehin schon gearbeitet wird.

Vier Muster tauchen im Alltag am häufigsten auf:

- **Kontrolle nach dem Livegang.** Redirects verfolgen, Security-Header der Zielseite ansehen, DNS-Propagation prüfen. Ein Satz statt vier Tabs.
- **Mail-Zustellbarkeit klären.** SPF, DKIM und DMARC in einem Rutsch prüfen, wenn ein Kunde meldet, dass Mails im Spam landen.
- **Vorbereitung eines Onboardings.** Zertifikatslaufzeit, Domain-Ablauf und Erreichbarkeit einer neuen Kundendomain abfragen, bevor der Monitor überhaupt angelegt wird.
- **Erste Einordnung bei einer Störung.** Ist die Domain erreichbar, antwortet der Port, stimmt die Auflösung? Bevor jemand ins Ticket schreibt, steht der Befund.

Dazu kommt die zweite Ebene: Server, die mit einem API-Token deine eigenen Daten lesen. Dann beantwortet der Assistent nicht nur Fragen zu beliebigen Domains, sondern auch Fragen zu deinem Bestand, etwa welche Monitore gerade down sind oder wie die Verfügbarkeit eines Kunden im letzten Monat aussah.

Der Zeitgewinn entsteht nicht durch eine einzelne schnellere Prüfung, sondern durch den weggefallenen Kontextwechsel. Eine Zertifikatsprüfung dauert im Browser vielleicht 30 Sekunden. Der Weg dorthin, das Wiederfinden des richtigen Tabs und das Zurückfinden in die eigentliche Aufgabe kosten ein Vielfaches davon. Wer denselben Befund im laufenden Gespräch bekommt, verliert den Faden nicht.

Wichtig für die Erwartungshaltung: Ein MCP-Server ersetzt kein Monitoring. Er prüft auf Zuruf, nicht im Intervall, und er weckt niemanden nachts um drei. Er ist das Werkzeug für die Frage zwischendurch, nicht die Überwachung im Hintergrund.

Dieselben Prüfungen gibt es auch als Web-Tools, wenn du sie lieber im Browser fährst oder einem Kunden einen Link schickst.

## Was unterscheidet einen MCP-Server von einer REST-API?

Technisch liegt oft dieselbe Logik darunter. Viele MCP-Server sind eine dünne Schicht über einer bestehenden REST-API. Der Unterschied liegt darin, für wen die Schnittstelle geschrieben ist.

Eine REST-API richtet sich an Entwickler. Jemand liest die Dokumentation, versteht sie und schreibt Code, der einen bestimmten Endpunkt zu einem bestimmten Zeitpunkt aufruft. Ein MCP-Server richtet sich an ein Modell. Das Werkzeug muss sich deshalb selbst beschreiben, und zwar so, dass ein Modell aus der Beschreibung ableiten kann, wann der Aufruf sinnvoll ist und welche Argumente hineingehören.

| Merkmal | REST-API | MCP-Server |
| --- | --- | --- |
| Adressat | Entwickler, der Code schreibt | Modell, das zur Laufzeit auswählt |
| Beschreibung | externe Dokumentation | Werkzeug beschreibt sich selbst, abrufbar zur Laufzeit |
| Aufruf | fester Endpunkt im Code | Auswahl aus dem Kontext des Gesprächs |
| Antwort | Nutzdaten für die Anwendung | Text plus strukturierte Daten für Modell und Anwendung |
| Integration | je Anbieter neu gebaut | einmal gebaut, für jeden kompatiblen Client nutzbar |

Ein zweiter Unterschied betrifft den Zustand. Über Streamable HTTP läuft ein Server üblicherweise stateless: Es gibt keinen Sitzungszustand zwischen zwei Aufrufen, jeder Request steht für sich. Das macht den Betrieb einfach und den Server gut skalierbar, verschiebt aber die Verantwortung für den Gesprächskontext dorthin, wo sie hingehört, nämlich in den Client.

Die praktische Konsequenz für Anbieter: Eine gute Werkzeugbeschreibung ist kein Beiwerk, sondern die eigentliche Schnittstelle. Ein präzise benanntes Werkzeug mit klarem Schema wird zur richtigen Zeit aufgerufen. Ein vage beschriebenes wird ignoriert oder falsch eingesetzt.

## Wie sicher ist das?

Die ehrliche Antwort: Es hängt an drei Fragen, die du je Server beantworten solltest, bevor du ihn verbindest.

**Was darf der Server?** Ein Werkzeug, das nur liest, kann im schlimmsten Fall etwas Falsches anzeigen. Ein Werkzeug, das schreibt oder löscht, kann Schaden anrichten. Read-only ist deshalb der sichere Ausgangspunkt, und ein Anbieter sollte klar sagen, welche seiner Werkzeuge schreiben können. Der Uptimeify MCP-Server macht genau das: 33 Tools lesen nur, und eine weitere Reihe von 43 Schreib-Tools gibt es hinter einem eigenen Zustimmungs-Scope, getrennt vom Lesezugriff erteilt und standardmäßig aus, sodass nichts schreibt, bis du diesen Haken selbst setzt.

**Wessen Daten sieht er?** Bei anonymen Werkzeugen keine: Sie prüfen öffentlich erreichbare Domains und brauchen weder Konto noch Token. Sobald ein Server eigene Daten liest, entscheidet der Zugang über den Umfang. Ein kundenbezogener Token sollte genau einen Kunden sehen, eine OAuth-Verbindung genau das, was der freigebende Account selbst sieht. Prüfe außerdem, ob du eine Verbindung jederzeit widerrufen kannst.

**Wo landen Anfragen und Ergebnisse?** Ein Remote-Server ist ein Dienst wie jeder andere: Standort, Betreiber und Sub-Prozessoren sind Teil deiner eigenen Auskunftspflicht gegenüber Kunden. Der Uptimeify MCP-Server läuft auf europäischem Stack in Frankfurt, ohne US-Sub-Prozessoren. Das nimmt dir in Ausschreibungen und Datenschutzgesprächen eine Diskussion ab.

Ein vierter Punkt betrifft nicht den Server, sondern die Arbeitsweise: Ergebnisse aus Werkzeugen sind Daten, keine Anweisungen. Ein Assistent, der den Inhalt einer fremden Seite liest, sollte darin gefundene Aufforderungen nicht ausführen. Gute Clients trennen das sauber; wer Automatisierungen baut, sollte es ebenfalls tun.

## Wie bindest du einen ein?

Bei einem Remote-Server genügt in den meisten Assistenten die URL. Beim Uptimeify MCP-Server ist das `https://uptimeify.io/mcp`. Du fügst sie als Remote-MCP-Server hinzu, und die 20 anonymen Check-Tools stehen ohne Account und ohne Token bereit. Willst du zusätzlich deine eigenen Monitore lesen, kommt eine Freigabe per OAuth oder ein API-Token dazu.

Clients, die nur stdio sprechen, brauchen eine kleine Konfigurationsdatei und eine Bridge auf den HTTP-Endpunkt. Ob ein Server erreichbar ist und welche Werkzeuge er heute anbietet, beantwortet ein einziger Aufruf der Methode `tools/list`.

### Wo findest du MCP-Server?

Es gibt keinen einen offiziellen Katalog, sondern mehrere Wege. Viele Assistenten bringen inzwischen ein eigenes Verzeichnis mit, in dem verbundene Dienste mit einem Klick hinzugefügt werden. Daneben existieren öffentliche Sammlungen und Registries, in die Anbieter ihre Server eintragen.

Damit ein Server dort sauber auftaucht, veröffentlicht er zwei Beschreibungsdateien an festen Orten: eine Server-Card mit seinen Fähigkeiten und Werkzeug-Metadaten sowie ein Registry-Manifest für Verzeichnisse. Beim Uptimeify MCP-Server liegen sie unter `/.well-known/mcp/server-card.json` und `/.well-known/mcp/server.json`.

Ein Blick lohnt sich vor dem Verbinden in beide Richtungen. Die Server-Card sagt dir, was der Server kann, bevor du ihn einbindest. Und wenn du selbst einen Server baust, entscheidet sie darüber, ob Clients und Verzeichnisse ihn überhaupt sinnvoll darstellen können.

Die Schritt-für-Schritt-Anleitung mit fertiger Konfiguration, Tool-Liste und Rate Limits steht in einem eigenen Beitrag: [MCP-Server in Claude einbinden](/de/blog/mcp-server-claude-einbinden). Wer nur die Begriffe nachschlagen will, findet sie im Glossar unter [Model Context Protocol](/de/ressourcen/plattform-und-support/glossar/model-context-protocol).