Wenn du viele WordPress-Websites verwaltest, bist du immer auf der Suche nach der nächsten einfachen Möglichkeit, den Zeitaufwand für den Zugriff auf Dashboards und das Klicken durch eine Reihe von Schaltflächen zu reduzieren.
MCPs (Model Context Protocols) haben in letzter Zeit für viel Aufsehen gesorgt, und wir haben uns vorgenommen zu untersuchen, wie MCPs in Verbindung mit der Kinsta-API einer Agentur helfen können, die so viele Websites verwaltet.
In diesem Artikel führen wir dich durch ein praktisches Beispiel für den Aufbau eines MCP-Servers, der KI-Assistenten wie Claude mit der Kinsta-API verbindet, um WordPress-Hosting-Aufgaben zu verwalten, die Agenturen ohnehin schon täglich erledigen.
Was wir aufbauen
Wir bauen einen MCP-Server, der eine Reihe von Tools bereitstellt, damit KI-Assistenten Aktionen ausführen können wie:
- Alle WordPress-Websites unter deinem Konto auflisten
- Umgebungen für eine bestimmte Website anzeigen
- Den Cache in einer bestimmten Umgebung leeren
- Eine bestehende Website klonen, um eine neue zu erstellen
- Anzeigen, welche Plugins und Themes veraltet oder anfällig sind
- Plugin-Updates in bestimmten Umgebungen auslösen
Sobald der Server eingerichtet ist, wird er mit einem MCP-Host/Client verbunden (in diesem Fall Claude for Desktop):
Beachte, wie es verschiedene Tools aufruft und dann die folgende Antwort zurückgibt:
Erste Schritte
Bevor wir uns mit dem Code beschäftigen, ist es hilfreich, ein paar Grundlagen darüber zu verstehen, wie MCP in dieses Setup passt.
Ein MCP-Server sitzt zwischen einem KI-Assistenten und einer bestehenden API. Er ersetzt die API nicht und verändert auch nicht ihre Funktionsweise. Stattdessen stellt er eine Reihe von Tools bereit, die die KI bei Bedarf aufrufen kann. Jedes Tool ist einer bestimmten Aktion zugeordnet, wie zum Beispiel das Auflisten von Websites oder das Leeren des Caches deiner Website.
Wenn du eine Frage an einen KI-Assistenten stellst, entscheidet dieser, ob eines dieser Tools relevant ist. Ist dies der Fall, ruft der Assistent das Tool über den MCP-Server auf, der Server kommuniziert mit der API und das Ergebnis wird als einfache Antwort zurückgegeben. Nichts läuft automatisch ohne deine Zustimmung, und es stehen nur die Tools zur Verfügung, die du bereitstellst.
In diesem Beispiel kommuniziert der MCP-Server mit der Kinsta-API und stellt eine begrenzte Anzahl von WordPress-Hosting-Aktionen bereit. Es ist keine benutzerdefinierte Benutzeroberfläche, keine Hintergrundautomatisierung und keine spezielle KI-Konfiguration erforderlich.
Voraussetzungen
Um mitzumachen, brauchst du ein paar Dinge:
- Eine stabile Node.js-Installation
- Grundlegende Kenntnisse in TypeScript
- Ein Kinsta-Konto mit aktiviertem API-Zugriff
- Deinen Kinsta-API-Schlüssel und deine Unternehmens-ID
Du brauchst keine Vorkenntnisse in MCP und musst kein KI-Modell erstellen oder trainieren. Wir konzentrieren uns ausschließlich darauf, bestehende Tools miteinander zu verknüpfen.
Einrichten des Projekts
Erstelle zunächst ein neues Verzeichnis für das Projekt und initialisiere eine Node.js-App:
mkdir kinsta-mcp
cd kinsta-mcp
npm init -yInstalliere anschließend das MCP SDK und die wenigen Abhängigkeiten, die wir verwenden:
npm install @modelcontextprotocol/sdk zod@3
npm install -D typescript @types/nodeErstelle eine grundlegende Projektstruktur:
mkdir src
touch src/index.tsAktualisiere dann deine package.json, damit Node den erstellten Server ausführen kann:
{
"name": "kinsta-mcp-server",
"version": "1.0.0",
"description": "MCP-Server zur Verwaltung von WordPress-Seiten über die Kinsta-API",
"type": "module",
"scripts": {
"build": "tsc"
},
"dependencies": {
"@modelcontextprotocol/sdk": "^1.0.0",
"zod": "^3.24.0"
},
"devDependencies": {
"@types/node": "^22.0.0",
"typescript": "^5.0.0"
}
}Füge zum Schluss eine tsconfig.json im Stammverzeichnis des Projekts hinzu:
{
"compilerOptions": {
"target": "ES2022",
"module": "Node16",
"moduleResolution": "Node16",
"outDir": "./build",
"rootDir": "./src",
"strict": true,
"esModuleInterop": true,
"skipLibCheck": true,
"forceConsistentCasingInFileNames": true
},
"include": ["src/**/*"],
"exclude": ["node_modules"]
}Damit bist du bereit, mit dem Erstellen des MCP-Servers selbst zu beginnen.
Erstellen des MCP-Servers
Nachdem das Projekt nun eingerichtet ist, ist es an der Zeit, den MCP-Server selbst zu erstellen.
Wir beginnen damit, die erforderlichen Pakete zu importieren und die Serverinstanz zu erstellen. Dann fügen wir einen kleinen Helfer für die Kommunikation mit der API hinzu. Danach registrieren wir Tools, die direkt mit WordPress-Hosting-Aktionen verknüpft sind.
Pakete importieren und den Server erstellen
Öffne src/index.ts und füge die folgenden Importe am Anfang der Datei hinzu:
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";Diese Importe bewirken drei Dinge:
McpServerist der Kernserver, der Tools registriert und Anfragen vom KI-Client verarbeitet.StdioServerTransportermöglicht es dem Server, über Standard-Ein- und -Ausgabe zu kommunizieren – so verbinden sich die meisten Desktop-KI-Clients.zodwird verwendet, um die Eingaben zu definieren und zu validieren, die jedes Tool akzeptiert.
Als Nächstes definierst du ein paar Konstanten für die API und die Anmeldedaten:
const KINSTA_API_BASE = "https://api.kinsta.com/v2";
const KINSTA_API_KEY = process.env.KINSTA_API_KEY;
const KINSTA_COMPANY_ID = process.env.KINSTA_COMPANY_ID;Erstelle nun die MCP-Serverinstanz:
const server = new McpServer({
name: "kinsta",
version: "1.0.0",
});Der Name gibt an, wie der Server innerhalb eines MCP-Clients angezeigt wird. Die Version ist optional, aber nützlich, sobald du mit der Iteration beginnst.
Hinzufügen einer Hilfsfunktion für API-Anfragen
Die meisten Tools, die wir erstellen, müssen HTTP-Anfragen an die API senden. Anstatt diese Logik überall zu wiederholen, erstelle eine einzige Hilfsfunktion. Füge dies unterhalb der Server-Einrichtung ein:
async function kinstaRequest(
endpoint: string,
options: RequestInit = {}
): Promise {
const url = `${KINSTA_API_BASE}${endpoint}`;
const headers = {
Authorization: `Bearer ${KINSTA_API_KEY}`,
"Content-Type": "application/json",
...options.headers,
};
const response = await fetch(url, { ...options, headers });
if (!response.ok) {
const errorText = await response.text();
throw new Error(`Kinsta-API-Fehler (${response.status}): ${errorText}`);
}
return response.json() as Promise;
}Implementierung der Tool-Ausführung
Tools sind das Wichtigste, was ein MCP-Server bereitstellt. Jedes Tool ist eine Funktion, die ein KI-Assistent mit deiner Zustimmung aufrufen kann, um eine bestimmte Aufgabe auszuführen.
In diesem Server folgt jedes Tool derselben Struktur:
- Ein Tool-Name (z. B.
list_sites) - Eine kurze Beschreibung (damit der Assistent weiß, wann er es einsetzen soll)
- Ein Eingabeschema (damit das Tool nur mit gültigen Eingaben läuft)
- Eine Handler-Funktion (in der wir die API aufrufen und die Ausgabe formatieren)
Wir formatieren die Antworten bewusst als Klartext. KI-Assistenten funktionieren am besten, wenn Tools klare, lesbare Ausgaben liefern, anstatt rohes JSON auszugeben.
Tool 1: Websites auflisten
Dieses Tool ruft alle WordPress-Websites unter deinem Unternehmenskonto ab. Das ist normalerweise das Erste, was du brauchst, wenn du mit mehreren Websites arbeitest, da die meisten anderen Aktionen mit einer Website-ID beginnen.
Die API-Antwort enthält grundlegende Informationen zu jeder Seite, daher definieren wir eine einfache Struktur, mit der wir arbeiten können:
interface Site {
id: string;
name: string;
display_name: string;
status: string;
site_labels: Array;
}
interface ListSitesResponse {
company: {
sites: Site[];
};
}Damit können wir das Tool registrieren:
server.registerTool(
"list_sites",
{
description:
"Ruft alle WordPress-Websites deines Unternehmens ab. Gibt Website-IDs, Namen und Status zurück.",
inputSchema: {},
},
async () => {
const data = await kinstaRequest(
`/sites?company=${KINSTA_COMPANY_ID}`
);
const sites = data.company.sites;
if (!sites || sites.length === 0) {
return {
content: [
{ type: "text", text: "Keine Websites für dieses Unternehmen gefunden." }
],
};
}
const siteList = sites
.map((site) => {
const labels =
site.site_labels?.map((l) => l.name).join(", ") || "none";
return `• ${site.display_name} (${site.name})
ID: ${site.id}
Status: ${site.status}
Labels: ${labels}`;
})
.join("\n\n");
return {
content: [
{
type: "text",
text: `Found ${sites.length} site(s):\n\n${siteList}`,
},
],
};
}
);Dieses Tool benötigt keine Eingaben, daher ist das Eingabeschema leer. Im Handler rufen wir die API auf, prüfen, ob das Ergebnis leer ist, und formatieren die Antwort dann als lesbaren Text.
Anstatt rohes JSON zurückzugeben, geben wir eine kurze Zusammenfassung zurück, die sich gut für eine Chat-Oberfläche eignet. Das macht es einem KI-Assistenten leicht, Fragen wie „Welche Websites habe ich?“ oder „Zeig mir alle meine WordPress-Websites“ zu beantworten, ohne dass zusätzliches Parsen nötig ist.
Tool 2: Umgebungen abrufen
Sobald du eine Site-ID hast, ist der nächste übliche Schritt, die zugehörigen Umgebungen zu überprüfen. Dieses Tool gibt alle Umgebungen für eine bestimmte Site zurück, einschließlich Live-, Staging- und Premium-Staging-Umgebungen.
interface Environment {
id: string;
name: string;
display_name: string;
is_premium: boolean;
primaryDomain?: {
id: string;
name: string;
};
container_info?: {
php_engine_version: string;
};
}
interface GetEnvironmentsResponse {
site: {
environments: Environment[];
};
}Einige Felder sind optional, wie die primäre Domain oder die PHP-Version, daher sind sie entsprechend gekennzeichnet. Das Tool selbst benötigt nur die Website-ID:
server.registerTool(
"get_environments",
{
description:
"Umgebungen (Live, Staging) für eine bestimmte Website abrufen. Erfordert die Website-ID.",
inputSchema: {
site_id: z.string().describe("Die Website-ID, für die Umgebungen abgerufen werden sollen"),
},
},
async ({ site_id }) => {
const data = await kinstaRequest(
`/sites/${site_id}/environments`
);
const envs = data.site.environments;
if (!envs || envs.length === 0) {
return {
content: [
{ type: "text", text: "Keine Umgebungen für diese Website gefunden." }
],
};
}
const envList = envs
.map((env) => {
const domain = env.primaryDomain?.name || "Keine Domain";
const php = env.container_info?.php_engine_version || "Unbekannt";
const type = env.is_premium
? "Premium Staging"
: env.name === "live"
? "Live"
: "Staging";
return `• ${env.display_name} (${type})
ID: ${env.id}
Domain: ${domain}
PHP: ${php}`;
})
.join("\n\n");
return {
content: [
{
type: "text",
text: `${envs.length} Umgebung(en) gefunden:\n\n${envList}`,
},
],
};
}
);Dies ist normalerweise der nächste Schritt vor Aktionen wie dem Leeren des Caches, dem Klonen einer Website oder dem Aktualisieren von Plugins.
Tool 3: Website-Cache leeren
Das Leeren des Caches ist eine Routineaufgabe, aber auch ein asynchroner Vorgang. Wenn du ihn auslöst, antwortet die API sofort mit einer Vorgangs-ID, während das Leeren des Caches im Hintergrund weiterläuft.
Hier sind die Typdefinition und die Tool-Funktion:
interface OperationResponse {
operation_id: string;
message: string;
status: number;
}
server.registerTool(
"clear_site_cache",
{
description:
"Cache für eine Website-Umgebung löschen. Erfordert die Umgebungs-ID.",
inputSchema: {
environment_id: z
.string()
.describe("Die Umgebungs-ID, für die der Cache gelöscht werden soll"),
},
},
async ({ environment_id }) => {
const data = await kinstaRequest(
"/sites/tools/clear-cache",
{
method: "POST",
body: JSON.stringify({ environment_id }),
}
);
return {
content: [
{
type: "text",
text: `Cache-Leerung gestartet!
Vorgangs-ID: ${data.operation_id}
Meldung: ${data.message}
Verwende get_operation_status, um den Fortschritt zu überprüfen.`,
},
],
};
}
);Anstatt darauf zu warten, dass der Vorgang abgeschlossen ist, gibt das Tool sofort die Vorgangs-ID zurück. Das sorgt für eine schnelle Interaktion und ermöglicht es dem KI-Assistenten, bei Bedarf später nachzufassen.
Tool 4: Website klonen
Das Klonen einer Website ist eine der Aktionen, die Agenturen ständig ausführen, insbesondere wenn sie mit Vorlagen arbeiten oder neue Kundenwebsites einrichten. Anstatt bei Null anzufangen, nimmst du eine bestehende Umgebung und erstellst darauf basierend eine neue Website.
Die Antwort verwendet dieselbe Operationsform, die wir zuvor gesehen haben, daher musst du sie nicht erneut definieren. Das Tool benötigt einen Anzeigenamen für die neue Website und die Umgebungs-ID, von der geklont werden soll:
server.registerTool(
"clone_site",
{
description:
"Klone eine bestehende Website-Umgebung, um eine neue Website zu erstellen. Ideal, um neue Kunden-Websites aus einer Vorlage zu erstellen.",
inputSchema: {
display_name: z
.string()
.describe("Name für die neue geklonte Website"),
source_env_id: z
.string()
.describe("Die Umgebungs-ID, von der geklont werden soll"),
},
},
async ({ display_name, source_env_id }) => {
const data = await kinstaRequest(
"/sites/clone",
{
method: "POST",
body: JSON.stringify({
company: KINSTA_COMPANY_ID,
display_name,
source_env_id,
}),
}
);
return {
content: [
{
type: "text",
text: `Klon der Website gestartet!
Neue Website: ${display_name}
Vorgangs-ID: ${data.operation_id}
Meldung: ${data.message}
Verwende get_operation_status, um den Fortschritt zu überprüfen.`,
},
],
};
}
);Dieses Tool ist besonders nützlich, wenn es mit anderen Tools kombiniert wird. Ein KI-Assistent kann beispielsweise eine Website klonen und dann sofort die Umgebungen auflisten oder den Plugin-Status überprüfen, sobald der Vorgang abgeschlossen ist.
Tool 5: Betriebsstatus abrufen
Da einige Aktionen asynchron ablaufen, brauchen wir eine Möglichkeit, ihren Fortschritt zu überprüfen. Dafür ist dieses Tool da.
interface OperationStatusResponse {
status?: number;
message?: string;
}
server.registerTool(
"get_operation_status",
{
description:
"Den Status eines asynchronen Vorgangs prüfen (Cache leeren, Site klonen usw.)",
inputSchema: {
operation_id: z
.string()
.describe("Die zu prüfende Vorgangs-ID"),
},
},
async ({ operation_id }) => {
const response = await fetch(
`${KINSTA_API_BASE}/operations/${encodeURIComponent(operation_id)}`,
{
headers: {
Authorization: `Bearer ${KINSTA_API_KEY}`,
},
}
);
const data: OperationStatusResponse = await response.json();
if (response.status === 200) {
return {
content: [
{
type: "text",
text: `Vorgang erfolgreich abgeschlossen!
Message: ${data.message || "Vorgang abgeschlossen"}`,
},
],
};
}
if (response.status === 202) {
return {
content: [
{
type: "text",
text: `Vorgang läuft noch...
Meldung: ${data.message || "Wird verarbeitet"}`,
},
],
};
}
return {
content: [
{
type: "text",
text: `Vorgangsstatus: ${response.status}
Meldung: ${data.message || "Unbekannter Status"}`,
},
],
};
}
);Tool 6: Plugins über alle Websites hinweg abrufen
Wenn du viele WordPress-Websites verwaltest, sind Plugins oft der Punkt, an dem es zu Abweichungen kommt. Dieses Tool löst das Problem, indem es Plugins im gesamten Unternehmenskonto betrachtet, statt nur eine Website nach der anderen.
Die API liefert viele Informationen zurück, darunter in welchen Umgebungen jedes Plugin installiert ist, ob Updates verfügbar sind und ob eine Version als anfällig markiert ist. Um mit diesen Daten zu arbeiten, definieren wir die folgenden Shapes:
interface PluginEnvironment {
id: string;
site_display_name: string;
display_name: string;
plugin_status: string;
plugin_update: string | null;
plugin_version: string;
is_plugin_version_vulnerable: boolean;
plugin_update_version: string | null;
}
interface Plugin {
name: string;
title: string;
latest_version: string | null;
is_latest_version_vulnerable: boolean;
environment_count: number;
update_count: number;
environments: PluginEnvironment[];
}
interface GetPluginsResponse {
company: {
plugins: {
total: number;
items: Plugin[];
};
};
}Das Tool selbst benötigt keine Eingaben:
server.registerTool(
"get_plugins",
{
description:
"Alle WordPress-Plugins auf allen Websites abrufen. Zeigt an, für welche Plugins Updates verfügbar sind oder Sicherheitslücken bestehen.",
inputSchema: {},
},
async () => {
const data = await kinstaRequest(
`/company/${KINSTA_COMPANY_ID}/wp-plugins`
);
const plugins = data.company.plugins.items;
if (!plugins || plugins.length === 0) {
return {
content: [
{ type: "text", text: "Keine Plugins gefunden." }
],
};
}
const sorted = [...plugins].sort(
(a, b) => b.update_count - a.update_count
);
const pluginList = sorted.slice(0, 20).map((plugin) => {
const status =
plugin.update_count > 0
? `⚠️ ${plugin.update_count} Website(s) müssen aktualisiert werden`
: "✅ Auf dem neuesten Stand";
const vulnerable =
plugin.is_latest_version_vulnerable ? " 🔴 ANFÄLLIG" : "";
return `• ${plugin.title} (${plugin.name})${vulnerable}
Aktuellste Version: ${plugin.latest_version || "unbekannt"}
Installiert auf: ${plugin.environment_count} Umgebung(en)
${status}`;
}).join("\n\n");
const outdatedCount = plugins.filter(
(p) => p.update_count > 0
).length;
return {
content: [
{
type: "text",
text: `${data.company.plugins.total} Plugins gefunden (${outdatedCount} haben verfügbare Updates):\n\n${pluginList}`,
},
],
};
}
);Tool 7: Themes auf allen Websites abrufen
Themes haben ähnliche Probleme wie Plugins, werden aber oft noch seltener überprüft. Dieses Tool funktioniert genauso wie das Plugin-Tool, konzentriert sich aber stattdessen auf WordPress-Themes.
Die Antwortstruktur entspricht dem Plugin-Endpunkt, nur mit themenspezifischen Feldern:
interface ThemeEnvironment {
id: string;
site_display_name: string;
display_name: string;
theme_status: string;
theme_update: string | null;
theme_version: string;
is_theme_version_vulnerable: boolean;
theme_update_version: string | null;
}
interface Theme {
name: string;
title: string;
latest_version: string | null;
is_latest_version_vulnerable: boolean;
environment_count: Zahl;
update_count: Zahl;
environments: ThemeEnvironment[];
}
interface GetThemesResponse {
company: {
themes: {
total: Zahl;
items: Theme[];
};
};
}Tool 8: Plugin aktualisieren
Probleme aufzulisten ist nützlich, aber irgendwann musst du sie beheben. Mit diesem Tool kannst du ein bestimmtes Plugin in einer bestimmten Umgebung aktualisieren.
Der Update-Endpunkt gibt dieselbe asynchrone Operationsform zurück wie zuvor, daher können wir ihn überspringen. Hier ist die Tool-Definition:
server.registerTool(
"update_plugin",
{
description:
"Ein bestimmtes Plugin in einer Site-Umgebung auf eine neue Version aktualisieren.",
inputSchema: {
environment_id: z
.string()
.describe("Die Umgebungs-ID, in der das Plugin installiert ist"),
plugin_name: z
.string()
.describe("Der Name/Slug des Plugins (z. B. 'akismet', 'elementor')"),
update_version: z
.string()
.describe("Die Version, auf die aktualisiert werden soll (z. B. '5.3')"),
},
},
async ({ environment_id, plugin_name, update_version }) => {
const data = await kinstaRequest(
`/sites/environments/${environment_id}/plugins`,
{
method: "PUT",
body: JSON.stringify({
name: plugin_name,
update_version,
}),
}
);
return {
content: [
{
type: "text",
text: `Plugin-Update gestartet!
Plugin: ${plugin_name}
Zielversion: ${update_version}
Vorgangs-ID: ${data.operation_id}
Meldung: ${data.message}
Verwende get_operation_status, um den Fortschritt zu überprüfen.`,
},
],
};
}
);Genau wie beim Leeren des Caches und beim Klonen von Websites laufen Updates asynchron ab. Durch die Rückgabe der Vorgangs-ID kann der KI-Assistent den Fortschritt verfolgen, anstatt davon auszugehen, dass das Update sofort abgeschlossen ist.
Den Server starten
Nachdem alle Tools registriert sind, besteht der letzte Schritt darin, den MCP-Server zu starten und ihn für einen KI-Client verfügbar zu machen.
Füge am Ende deiner Datei die Hauptfunktion hinzu, die den Server über den STDIO-Transport verbindet:
async function main() {
const transport = new StdioServerTransport();
await server.connect(transport);
console.error("Kinsta MCP Server läuft auf stdio");
}
main().catch((error) => {
console.error("Schwerwiegender Fehler:", error);
process.exit(1);
});Dies weist den MCP-Server an, auf Anfragen über die Standardeingabe und -ausgabe zu warten. Dadurch wird der Server für MCP-kompatible Desktop-Clients auffindbar.
Ein wichtiges Detail hierbei ist die Protokollierung. Da dieser Server über STDIO kommuniziert, müssen alle Protokolle an stderr gesendet werden. Das Schreiben in stdout kann MCP-Nachrichten stören und die Verbindung unterbrechen.
Als Nächstes erstellst du das Projekt:
npm run buildDadurch werden die TypeScript-Dateien in das Build-Verzeichnis kompiliert und der Einstiegspunkt wird ausführbar gemacht.
Sobald der Build abgeschlossen ist, kann der Server von einem MCP-Client gestartet werden. Den vollständigen Code findest du auf GitHub.
Testen deines Servers mit Claude for Desktop
Um deinen MCP-Server zu nutzen, muss Claude for Desktop wissen, wie er gestartet wird. Öffne die Konfigurationsdatei von Claude Desktop:
~/Library/Application Support/Claude/claude_desktop_config.jsonErstelle die Datei, falls sie noch nicht existiert. Wenn du VS Code verwendest, kannst du sie direkt über das Terminal öffnen:
code ~/Library/Application\ Support/Claude/claude_desktop_config.jsonFüge in der Datei deinen MCP-Server unter dem Schlüssel „mcpServers“ hinzu. Zum Beispiel:
{
"mcpServers": {
"kinsta": {
"command": "node",
"args": ["/ABSOLUTE/PATH/TO/mcp-server-demo-kinsta-api/build/index.js"],
"env": {
"KINSTA_API_KEY": "dein-api-schlüssel-hier",
"KINSTA_COMPANY_ID": "deine-firm-id-hier"
}
}
}
}Diese Konfiguration teilt Claude for Desktop mit, dass es einen MCP-Server namens kinsta gibt, der mit Node.js gestartet werden soll, und dass der Einstiegspunkt die kompilierte Datei index.js ist.
Stelle sicher, dass der Pfad auf die kompilierte Datei im Build-Verzeichnis verweist, nicht auf die TypeScript-Quelldatei. Speichere die Datei und starte Claude for Desktop neu.
Verbindung überprüfen
Sobald Claude neu gestartet ist, öffne einen neuen Chat. Klicke auf das Symbol „ “ neben dem Eingabefeld und fahre dann mit der Maus über Connectors. Dein MCP-Server sollte dort aufgeführt sein.
Sobald der Server verbunden ist, kannst du ihn sofort nutzen. Claude entscheidet, welches Tool verwendet wird, übergibt die erforderlichen Eingaben und gibt das Ergebnis als Klartext zurück.
Eine andere Art, mit den Tools zu arbeiten, die du bereits hast
Was sich gerade ändert, sind nicht die zugrunde liegenden Tools. APIs sind immer noch APIs. Hosting-Plattformen funktionieren nach wie vor auf die gleiche Weise. Was sich ändert, ist die Art und Weise, wie wir mit ihnen interagieren.
KI-Tools fühlen sich langsam weniger wie Chatboxen und mehr wie Schnittstellen an. Dieser MCP-Server ist ein kleines Beispiel für diesen Wandel. Er führt keine neuen Funktionen ein. Er macht bestehende Funktionen auf eine Weise zugänglich, die der tatsächlichen Arbeitsweise der Menschen entspricht.
Wie es weitergeht, liegt ganz bei dir. Du kannst die Dinge einfach und schreibgeschützt halten. Du kannst mehr Automatisierung mit Genehmigungen und Sicherheitsvorkehrungen hinzufügen. Oder du kannst denselben Server mit anderen Tools in deinem Workflow verbinden.
Wenn du neue Tools und Workflows wie diesen ausprobierst, ist eine solide Hosting-Grundlage wichtig. Das Letzte, was du willst, ist, Zeit mit Ausfällen oder Leistungsproblemen zu verschwenden, anstatt deine Websites aufzubauen und zu verbessern.
Kinsta bietet Managed Hosting für WordPress, das deine Websites zuverlässig am Laufen hält, auch wenn du offline bist. Du kannst dir unsere Hosting-Pakete ansehen oder mit unserem Vertriebsteam sprechen, um das richtige Paket für dich zu finden.
Joel ist Frontend-Entwickler und arbeitet bei Kinsta als Technical Editor. Er ist ein leidenschaftlicher Lehrer mit einer Vorliebe für Open Source und hat über 200 technische Artikel geschrieben, die sich hauptsächlich um JavaScript und seine Frameworks drehen.
