Was Blender MCP über den Aufbau nützlicher MCP-Server verrät

Die meisten Ingenieurarbeiten beginnen mit einer vertrauten Ausgangssituation: Jemand öffnet die von Ihnen entwickelte Anwendung.

Sie entwerfen das Dashboard, entscheiden, wo die Schaltflächen platziert werden sollen, und versuchen, die wichtigen Aktionen klar hervorzuheben. Der Benutzer nutzt einen Teil Ihrer Benutzeroberfläche, um seine Aufgabe zu erledigen.

Hinzu kommt zunehmend die interessante Frage, was passiert, wenn dieselbe Person bereits einen KI-Assistenten geöffnet hat und diesen einfach bittet, die Aufgabe direkt zu übernehmen.

Muss der Benutzer überhaupt Ihr Dashboard öffnen?

Manchmal ist die Antwort immer noch ja. Den Einsatz einer funktionierenden Schaltfläche durch drei Absätze an Hin- und Hergesprächen zu ersetzen, ist keine Verbesserung. Doch bei vielen Arbeitsabläufen führt das Zwingen der Nutzer durch die Navigation Ihrer Anwendung nur zu unnötigem Aufwand, ohne zusätzlichen Wert zu schaffen.

Das ist der Hauptgrund, warum MCP-Server voraussichtlich an Bedeutung gewinnen werden. Blender MCP ist eine gute Veranschaulichung dafür, wie das in der Praxis aussehen kann, und wirft zugleich einige weniger attraktive Fragen auf, wie man solche Integrationen im Laufe der Zeit entwickelt, wartet und bewertet.

Genau diese weniger attraktiven Fragen waren der Antrieb für die Arbeit an Pulse.

Was ist MCP und wie funktionieren MCP-Server?

MCP steht für Model Context Protocol, ein offener Standard zur Verbindung von KI-Anwendungen mit externen Tools und Datenquellen. Ein auf diesem Standard basierender Server kann Tools bereitstellen, die Aktionen ausführen, Ressourcen, die Kontext liefern, sowie Anfragen, die wiederverwendet werden können. Dieser Artikel konzentriert sich insbesondere auf Tools.

Die Architektur hält die KI-Anwendung, die als Host bezeichnet wird, getrennt von den MCP-Clienten und -Servern, mit denen sie kommuniziert. Der Host ist dafür verantwortlich, die Interaktion zu orchestrieren. Ein Client ermittelt mithilfe von tools/list, welche Tools verfügbar sind, und ruft anschließend mit tools/call ein ausgewähltes Tool auf. Der Server führt die eigentliche Logik aus und sendet ein Ergebnis zurück. Die Server selbst können lokal gehostet oder fernzugreifbar sein.

Für eine einfache Produktintegration könnte die Abfolge etwa so aussehen:

User asks for something
 → AI application selects an available tool
 → MCP client sends the call
 → Your MCP server checks access and runs the operation
 → Result returns to the AI application

MCP selbst hat keinen Einfluss darauf, ob das Modell auf ein Tool zurückgreifen soll, ob die Anfrage des Benutzers überhaupt sinnvoll ist oder ob die endgültige Antwort gut ist. Das Protokoll verbindet die Komponenten miteinander, doch die umgebende Anwendung muss weiterhin steuern, wie sie als Ganzes funktionieren.

Das Versenden eines Servers garantiert auch nicht, dass jedes KI-Assistenten ihn automatisch abruft. VS Code erfordert beispielsweise explizite Schritte zur Installation, Konfiguration und zum Vertrauensaufbau gegenüber einem MCP-Server. Es gibt weiterhin klare Grenzen bei der Integration und den Berechtigungen, die überschritten werden müssen.

Was Blender MCP tatsächlich demonstriert

Das von der Community entwickelte Projekt ahujasid/blender-mcp verbindet KI-Klienten mit Blender mithilfe eines auf Python basierenden MCP-Servers in Kombination mit einem Blender-Add-on. Es kann Szenen inspizieren, Objekte und Materialien manipulieren sowie Python-Code direkt innerhalb von Blender ausführen. Es sei darauf hingewiesen, dass es sich um eine Integration Dritter handelt und nicht um etwas, das Blender offiziell mitliefern würde.

Ihre Architektur sieht ungefähr so aus:

AI application / MCP client
  ↕ MCP
Python MCP server
  ↕ Project-specific socket connection
Blender add-on
  ↕
Blender scene and operations

Diese Trennung ist wichtig. MCP steuert die Schnittstelle zwischen Client und Server. Was zwischen dem Server und Blender abläuft, hängt vollständig von der Implementierung ab. Jeder MCP-Server benötigt weiterhin sein eigenes Mechanismus, um die zugrunde liegende Software tatsächlich anzusteuern.

Stellen Sie sich vor, Sie bitten einen Assistenten, eine Szene zu überprüfen, einige Objekte umzupositionieren und ihre Materialien anzupassen. Mit einer solchen Integration kann der Assistent Operationen direkt in der Szene durchführen, anstatt nur anzugeben, auf welche Menüpunkte geklickt werden soll. Ob das Ergebnis tatsächlich gut ist, ist eine völlig separate Frage.

Hervorzuheben ist, dass die eigentliche Arbeit weiterhin innerhalb von Blender stattfindet. Die Anwendung, ihr vorhandenes Funktionsumfang sowie Ihre Möglichkeit, zu überprüfen, was sich geändert hat, bleiben weiterhin zentral.

Dieses Muster scheint auch in anderen Arten von Software auftreten zu können: Jemand beantragt eine bestimmte Änderung, prüft das Ergebnis in der vertrauten Benutzeroberfläche und wechselt wieder zu manueller Arbeit, sobald dies schneller ist.

Das erscheint weitaus realistischer, als zu erwarten, dass die Menschen ihre vorhandenen Tools aufgeben und stattdessen alles über ein Chat-Fenster erledigen.

MCP gegen APIs: Was ändert sich eigentlich?

Ein MCP-Server kann frei auf einer bestehenden API basieren. Er kann genauso gut eine Datenbank, eine lokale Bibliothek oder eine speziell entwickelte Brücke wie die im Blender MCP verwenden. Die Einführung von MCP zwingt Sie nicht dazu, Ihren Backend-System neu zu bauen, nur weil nun eine KI-Anwendung es aufruft.

Was wirklich einen Wandel bewirkt, ist die Existenz einer gemeinsamen Schnittstelle zur Bereitstellung von Funktionen für jeden kompatiblen Client. Werkzeuge werden durch Definitionen beschrieben, die die verfügbaren Aktionen sowie deren Eingaben auflisten, sodass individuelle Client-Integrationen nicht mehr jeweils eigene Verfahren zur Erkennung und Aufrufung entwickeln müssen.

Es hilft, dies als einen dritten Zugangspunkt zu einem Produkt zu betrachten, der neben der bestehenden Benutzeroberfläche und der bestehenden API liegt.

Nehmen wir ein Inventarsystem als Beispiel. Die Geschäftslogik weiß bereits, wie man ein Produkt abruft, prüft, ob es auf Lager ist, und Einheiten davon reserviert. Die Wiederverwendung dieser Logik macht viel mehr Sinn, als eine parallele Implementierung ausschließlich für einen KI-Assistenten zu schreiben.

Doch die Vorteile von MCP sind nicht bedingungslos. Wenn Sie es mit einem einzigen internen Skript zu tun haben, das mit einer bekannten API kommuniziert, ist es vermutlich immer noch der einfachste Weg, diese direkt aufzurufen. MCP lohnt sich erst dann, wenn Sie tatsächlich Kompatibilität zwischen mehreren KI-Clienten benötigen oder wenn eine wiederverwendbare Tool-Schnittstelle ein echtes Problem löst, das Sie haben. Einfach ein weiteres Protokoll hinzuzufügen, nur weil es derzeit beliebt ist, bedeutet lediglich, dass Sie nun auch noch ein weiteres Protokoll warten müssen.

Die Entwicklung von MCP-Tools ist auch Gestaltung einer Schnittstelle

Das ist der Schritt, bei dem man langsamer vorgehen sollte.

Ein Agent muss herausfinden, welches Tool für eine bestimmte Aufgabe geeignet ist und wie dieses richtig aufgerufen werden kann. Anthropics eigene technische Richtlinien empfehlen, Tools um sinnvolle Arbeitseinheiten zu gestalten, jedem Tool klare Grenzen zu geben und deren Leistung in der Praxis zu bewerten, anstatt alle vorhandenen Endpunkte unverändert zur Verfügung zu stellen.

Für eine hypothetische Kataloganwendung könnte eine angemessene Ausgangsdefinition wie folgt aussehen:

{
  "name": "search_catalog",
  "description": "Find products in the authorized catalog by name or SKU. Returns product IDs, names, and availability. Read-only; does not reserve stock.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string", "minLength": 1 },
      "limit": { "type": "integer", "minimum": 1, "maximum": 20 }
    },
    "required": ["query", "limit"],
    "additionalProperties": false
  }
}

Dies dient als Veranschaulichung einer Tool-Definition, nicht als vollständige Serverimplementierung oder als tatsächliches Blender MCP-Tool. Der hier gezeigte Name, die Beschreibung sowie der JSON Schema-Eingabevertrag folgen dem von MCP vorgeschriebenen Format.

In der Beschreibung wird genau beschrieben, wonach das Tool suchen kann, was es zurückgibt und was es bewusst nicht tut. Seine Eingaben sind eng gefasst. Das Reservieren von Beständen wird absichtlich als separate Aktion behandelt, da dies andere Konsequenzen hat als eine einfache Abfrage.

Trotzdem macht das Beschriften von etwas als „autorisiert“ in einer Beschreibung es noch nicht dazu. Die tatsächliche Umsetzung von Zugriffskontrollen und Eingabenauswertungen muss in der Implementierung erfolgen. Jede Handlung mit echten Konsequenzen erfordert außerdem einen geeigneten BestätigungsSchritt. MCPs Sicherheitshinweise für Tools beziehen sich direkt auf diese Verantwortlichkeiten.

Blender MCP veranschaulicht diesen Kompromiss klar: Sein Python-Exekutionswerkzeug ist wirklich leistungsstark, und das Projekt selbst warnt ausdrücklich vor den Gefahren, einem Assistenten die Ausführung beliebigen Codes zu erlauben.

Für eigene Produktivtools lohnt es sich, mit dem kleinsten möglichen Berechtigungssatz zu beginnen, den man nur dann erweitert, wenn es einen konkreten Grund dafür gibt. Es ist auch sinnvoll, die Tools anhand echter Anfragen zu testen. Eine für Sie klar lesbare Beschreibung ist kein Beweis dafür, dass ein Agent sie richtig interpretieren und nutzen wird.

Wie erkennt man, ob ein MCP-Server nützlich ist?

Eine funktionierende Demo beantwortet nur eine einzige, enge Frage: Funktioniert dieser Workflow überhaupt?

Sie sagt nichts darüber aus, ob die Nutzer das Tool weiterhin verwenden, auf welche spezifischen Funktionen sie sich verlassen oder was schiefgeht, sobald echte Anfragen außerhalb des von Ihnen skriptierten Szenarios erfolgen.

Nehmen wir einen Katalogserver als Beispiel. Man möchte wissen, ob search_catalog tatsächlich aufgerufen wird, ob das Versenden einer neuen Version die Verarbeitung verlangsamt und ob Fehler eher um eine bestimmte Operation herum auftreten als gleichmäßig verteilt sind.

Auch bei der Interpretation ist hier Vorsicht geboten. Ein Anstieg der Tool-Aufrufe kann auf wirklich nützliche Arbeit hindeuten. Oder er kann darauf hinweisen, dass ein Agent etwas erneut versucht, was beim ersten Versuch bereits erfolgreich gewesen sein sollte. Allein die Rohzahlen der Aufrufe reichen nicht aus, um zwischen diesen beiden sehr unterschiedlichen Situationen zu unterscheiden.

Was das Monitoring angeht, handelt es sich um getrennte Aspekte, die separat erfasst werden sollten. Betriebsmetriken umfassen Aspekte wie Latenz und Fehlerraten. Produktanalysen zeigen Nutzungsmuster sowie, sofern der entsprechende Identitätskontext vorliegt, wiederholte Interaktionen. Die Bewertung auf Task-Ebene gibt Aufschluss darüber, ob der End-to-End-Ablauf tatsächlich das geliefert hat, was der Benutzer benötigte.

Dieser Unterschied ist wichtig, denn ein erfolgreich zurückgegebener Handler ist nicht gleichbedeutend mit der Erfüllung einer Benutzeraufgabe. Ein Aufruf eines Handlers kann technisch gesehen erfolgreich sein, doch danach kann es bei der Validierung der Ausgabe oder in der Übertragungsschicht zu Fehlern kommen. Selbst ein technisch gültiges Ergebnis kann für die Person, die es angefordert hat, nutzlos sein.

Das alles sollte nicht in einem einzigen grünen Statusindikator zusammengefasst werden, der den Unterschied verdeckt.

Warum ich Pulse für MCP-Analysen entwickle

Genau diese Fragen haben zur Entstehung von Pulse geführt – einem Open-Source-SDK in Kombination mit einem optionalen, separat gehosteten Cloud-Dienst.

Das öffentliche Repository des Projekts finden Sie unter github.com/selimeneserd/pulse-sdk, und indem Sie es dort markieren, helfen Sie anderen, es zu entdecken.

Es wird unter der MIT-Lizenz veröffentlicht. Die Bibliothek überwacht die Fertigstellung von MCP-Tool-Handlern und kann diese Metadaten an ein lokales Ziel, an einen von Ihnen kontrollierten Sammler oder über einen optionalen OpenTelemetry-Exporter senden. Für die Verwendung ist kein Anmelden bei Pulse Cloud erforderlich, und in der Integration ist kein standardmäßiger Cloud-Endpunkt heimlich eingebaut.

Eine minimale lokale Einrichtung sieht ungefähr so aus:

import { McpServer } from '@modelcontextprotocol/server';
import { createPulse } from '@reviseflow/pulse';
import { createJsonlExporter } from '@reviseflow/pulse-core/jsonl';

const analytics = createPulse({
  environment: 'development',
  exporter: createJsonlExporter({
    path: './catalog-events.jsonl',
  }),
});

const server = analytics.wrapServer(
  new McpServer({ name: 'catalog-server', version: '1.0.0' }),
);

// Register tools on `server`, then connect your existing MCP transport.

Dieser Auszug dient dazu, Instrumentierung zu veranschaulichen, und soll keine vollständige Serverimplementierung darstellen. Er wurde unter Verwendung von Pulse 0.2.1 sowie Version 2.0.0 von @modelcontextprotocol/server geschrieben, wobei Node.js 24.20.0 zu den unterstützten Laufzeiten gehört. Das Einfügen eines Tools allein erzeugt keine Analyseereignisse; nur tatsächliche Aufrufe der Handler tun dies. Beim ordnungsgemäßen Herunterfahren, nachdem alle laufenden Handler abgeschlossen sind, ruft man await analytics.shutdown({ timeoutMs: 2_000 }) auf.

Dieses spezielle Beispiel bezieht sich auf einen MCP-Server basierend auf TypeScript. Im SDK gibt es derzeit keinen Python-Adapter, der etwas wie Blender MCP abdecken könnte.

Pulse Cloud stellt die verwaltete Speicherschicht sowie das Dashboard bereit, die auf diesen Metadaten basieren: Muster der Tool-Nutzung, Dauer der Verarbeitung, Status des Ergebnisses sowie die Möglichkeit, nach Umgebung oder Version zu filtern. Sie arbeitet mit ihrem eigenen Telemetrie-Stream, sodass der tatsächliche Tool-Datenverkehr niemals darüber geleitet wird.

Das Senden von Daten an die Cloud ist optional und muss explizit erfolgen – über den HTTP-Exporter unter Verwendung einer Collector-URL zusammen mit einem serverseitigen Schreibschlüssel. Das Cloud-Produkt selbst ist geschlossene Quelle, während die zugrunde liegende Instrumentierungsschicht weiterhin vollständig offen ist und eigenständig genutzt werden kann.

Es ist wichtig, diese Grenze klar zu halten. Entwickler, die lieber in lokale JSONL-Dateien schreiben oder bereits eine Observability-Stack besitzen, sollten allen Grund haben, die Open-Source-Schicht zu nutzen, ohne zunächst Kunde der Cloud werden zu müssen.

Ehrliche Analysen benötigen klare Grenzen

Pulses Telemetriedaten ausschließen bewusst Rohanfragen, Tool-Argumente, Tool-Ausgaben, Fehlermeldungen, Stack-Traces sowie Anfrage-Header. Selbst etwas Einfaches wie der Name eines Tools oder eine technische Bezeichnung verdient genaue Prüfung, da Metadaten selbst sensible Informationen preisgeben können. Alle optionalen Kontoinhalter sind aus Designgründen pseudonym – das garantiert jedoch keine vollständige Anonymität.

Dort, wo die Messung endet, ist genauso wichtig wie das, was sie erfasst. Pulse kann erkennen, dass ein Handler ausgeführt wurde und wie lange dies dauerte, hat aber keine Kenntnis darüber, warum das Modell gerade dieses Tool gewählt hat, was der Benutzer eigentlich erreichen wollte oder ob das daraus resultierende Geschäftsergebnis gut war. Zudem gibt es keine Möglichkeit, einen Anruf aufzuzeichnen, der bereits vor Erreichen des Handlers blockiert wurde.

Die Übermittlung der Telemetriedaten erfolgt nach dem Best-Effort-Prinzip: Die Warteschlangen sind begrenzt und es werden Wiederholungsversuche unternommen, doch nichts garantiert, dass jedes Ereignis ankommt. Ein verloren gegangenes Telemetrieereignis beeinflusst niemals das tatsächliche Ergebnis der Tool, das der Benutzer erhält, bedeutet aber, dass in den Daten Lücken entstehen können. Dieses System dient der Analyse und nicht dazu, einen manipulationssicheren Audit-Trail bereitzustellen.

Angesichts dessen erscheint es ehrlicher, diese Einschränkungen direkt aufzuzählen, anstatt dem Feature einfach den Begriff „Observability“ zuzuweisen und die Nutzer im Unklaren darüber zu lassen, was tatsächlich erfasst wird und was nicht.

Zukunftsaussichten

Es ist wahrscheinlich, dass eine wirklich nützliche MCP-Integration zu einem weiteren Kriterium wird, das die Menschen bei der Beurteilung eines Produkts neben den üblichen Kriterien heranziehen.

Kann ein Assistent tatsächlich die Funktionalität erreichen, die ein Benutzer benötigt? Sind die von ihm ausgeführten Aktionen leicht nachvollziehbar und verständlich? Kann eine Person eingreifen und alles Wichtige vor dem Eintreten der jeweiligen Situation überprüfen? Und funktioniert die Integration weiterhin, sobald die anfängliche Neuheit nachlässt?

Blender MCP zeichnet sich dadurch aus, dass es ein konkretes Beispiel dafür bietet, wie ein Assistent echte, bereits vorhandene Software bedient – anstatt nur darüber zu sprechen. Diese Richtung erscheint vielversprechender als wieder ein weiterer Chatbot, dessen Hauptaufgabe darin besteht, Schritte zu beschreiben, die der Benutzer woanders selbst ausführen könnte.

Das bedeutet keineswegs, dass jedes Produkt derzeit einen MCP-Server benötigt oder dass traditionelle grafische Benutzeroberflächen veraltet werden. Es deutet lediglich darauf hin, dass einige Arbeitsabläufe zunächst innerhalb eines Assistenten beginnen und anschließend in der eigentlichen Anwendung fortgesetzt werden können, wodurch einige manuelle Hin- und Herbewegungen zwischen den Systemen entfallen.

Pulse selbst könnte bereits ein früher Schritt sein, und es ist unklar, wie schnell dieses Muster zur Standardpraxis werden wird. Dennoch scheinen die zugrundeliegenden ingenieurtechnischen Probleme jetzt schon wert, angegangen zu werden: die Entwicklung wirklich nützlicher Tools, das Festlegen sinnvoller Berechtigungsregeln, die Gewährleistung einer zuverlässigen Ausführung sowie Ehrlichkeit darüber, wie diese Tools in der Praxis eingesetzt werden.

Einfach nur einen MCP-Server zu veröffentlichen, reicht allein nicht aus. Die Server, die es wert sind, entwickelt zu werden, sind jene, zu denen die Nutzer auch nachdem die anfängliche Neugier verflogen ist, weiterhin zurückkehren.

Falls Sie selbst einen solchen Server entwickeln, wie entscheiden Sie dann, welche Tools tatsächlich erhalten bleiben sollten?

Verwandte Artikel

• MCP für AI-Agenten: Standardisierung der Tool-Integration in LangGraph — Dieser Artikel erläutert, was MCP in agierenden KI-Systemen tatsächlich standardisiert, indem er ad hoc durchgeführte Tool-Integrationen mit solchen auf MCP basierenden Integrationen innerhalb eines LangGraph-Orchestriers vergleicht.
• Lektionen aus der Veröffentlichung eines Next.js SaaS und der Erstellung einer Scaffolding CLI — Es werden die grundlegenden Entscheidungen erläutert – wie z. B. Wahl der Technologiestacke, Authentifizierung, Multi-Tenancy, Abrechnung und Zustandsverwaltung – sowie die Entwicklung einer CLI, die die Einrichtung von Next.js-Projekten vereinfacht.