So verbinden Sie KI-Agenten über MCP mit Laborgeräten

So verbinden Sie KI-Agenten über MCP mit Laborgeräten

Mit dem Model Context Protocol (MCP) können KI-Agenten Laborgeräte über einen einzigen offenen Standard erkennen, validieren und steuern. MCP ersetzt damit die individuellen Adapter und herstellerspezifischen SDKs, die jedes Laborautomatisierungsprojekt verlangsamen. Mit über 10'000 öffentlichen MCP-Servern und 97 Millionen monatlichen SDK-Downloads (Stand Anfang 2026) hat sich MCP zur De-facto-Integrationsschicht für KI-Software zur Gerätesteuerung entwickelt. Dieser Leitfaden zeigt Schritt für Schritt, wie Sie einen realen MCP-Server für einen Plate Reader entwickeln. Behandelt werden die Architektur, der Code und der Workflow, auf dem das Ganze beruht.

Architektur – ein MCP-Server pro Gerät

Das Grundmuster ist einfach: Jedes Gerät erhält einen eigenen MCP-Server. Der KI-Agent fungiert als MCP-Client und verbindet sich mit einem oder mehreren Servern, um Workflows über mehrere Geräte hinweg zusammenzustellen.

Jeder MCP-Server kapselt die Schnittstelle, über die das Gerät bereits verfügt, also seriell, TCP, REST oder ein proprietäres SDK. Der KI-Agent greift nie direkt auf Hardware-APIs zu. Er kommuniziert ausschliesslich über MCP.

Diese Architektur lässt sich horizontal skalieren. Um ein neues Gerät in Ihr Labor einzubinden, stellen Sie lediglich einen neuen MCP-Server bereit. Der KI-Agent erkennt ihn automatisch über den im Protokoll integrierten Mechanismus zur Tool-Erkennung. Auf Seite des Agenten sind keine Codeänderungen nötig.

Der vollständige Workflow – Erkennung, Validierung, Ausführung, Fehlerbehandlung

Bevor Sie Code schreiben, sollten Sie den vierphasigen Workflow verstehen, den MCP für jede Interaktion zwischen einem KI-Agenten und einem Gerät festlegt.

Phase 1 – Erkennung

Der Agent verbindet sich mit einem MCP-Server und ruft tools/list auf. Der Server antwortet mit allen Tools, die er bereitstellt, einschliesslich Namen, Beschreibungen und vollständiger JSON-Schema-Definitionen für die Eingaben. Damit weiss der Agent ohne vorherige Konfiguration, was das Gerät kann.

Phase 2 – Schemavalidierung

Jede Tool-Definition enthält ein inputSchema, das Parametertypen, Wertebereiche, Enums und Pflichtfelder festlegt. Die Validierung erfolgt zweimal: Der KI-Client validiert vor dem Senden, und der Server validiert beim Empfang. Ungültige Befehle erreichen die Hardware nie.

Phase 3 – Ausführung

Der Agent ruft tools/call mit validierten Argumenten auf. Der Server führt die Operation auf dem Gerät aus und gibt strukturierte Ergebnisse in einem content-Array zurück. Die Ergebnisse können Text, Daten-URIs oder Verweise auf Ressourcen enthalten.

Phase 4 – Fehlerbehandlung

Schlägt die Ausführung fehl, etwa wegen eines Timeouts des Geräts, eines Hardwarefehlers oder eines ungültigen Zustands, gibt der Server eine Antwort mit isError: true und einer aussagekräftigen Meldung zurück. Der Agent kann die Operation wiederholen, an einen Menschen eskalieren oder sein Vorgehen anpassen. Fehler bleiben nie unbemerkt.

Code-Walkthrough – MCP-Server für einen Plate Reader

Im Folgenden sehen Sie das Grundmuster für die Entwicklung eines MCP-Servers, der ein Laborgerät kapselt. Das Beispiel registriert ein einzelnes Tool für einen Plate Reader für 96-Well-Platten. Weitere Tools (Statusabfragen, vollständige Platten-Scans, Kalibrierung) folgen derselben Struktur.

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "plate-reader", version: "1.0.0" });

// Each tool: name, description, Zod schema for validation, handler function
server.tool(
  "read_absorbance",
  "Measure optical absorbance at a specified wavelength for wells on a 96-well microplate",
  {
    wells: z
      .array(z.string().regex(/^[A-H][1-9]$|^[A-H]1[0-2]$/))
      .min(1).max(96)
      .describe("Well positions, e.g. ['A1', 'A2', 'B6']"),
    wavelength_nm: z
      .number().min(200).max(1000)
      .describe("Measurement wavelength in nanometers (200-1000)"),
  },
  async ({ wells, wavelength_nm }) => {
    // In production: send SCPI commands over serial/TCP to the instrument
    const readings = await driver.readAbsorbance(wells, wavelength_nm);
    return {
      content: [{ type: "text", text: formatReadings(readings) }],
    };
  }
);

const transport = new StdioServerTransport();
await server.connect(transport);

Die Hauptarbeit leistet das Zod-Schema. Der reguläre Ausdruck ^[A-H][1-9]$|^[A-H]1[0-2]$ beschränkt die Well-Positionen auf gültige Koordinaten. Die Wellenlänge ist auf 200–1000 nm begrenzt, den physikalischen Bereich der Lampe. Ein KI-Agent kann nicht versehentlich wavelength_nm: -50 oder wells: ["Z99"] senden. Das Schema weist solche Werte zurück, bevor der Befehl das Gerät erreicht.

Wenn sich der Agent verbindet und tools/list aufruft, erhält er das vollständige JSON-Schema für jedes Tool, einschliesslich Parametertypen, Wertebereichen, Regex-Mustern und Beschreibungen. Der Agent weiss ohne vorherige Konfiguration oder Dokumentation, was das Gerät kann.

MCP vs. REST-API vs. Hersteller-SDK – ein konkreter Vergleich

Um zu verstehen, warum MCP für KI-Software zur Gerätesteuerung wichtig ist, vergleichen Sie dieselbe Operation, das Auslesen der Absorbanz eines Plate Readers, über drei Integrationsansätze hinweg.

Klassische REST-API

// REST: you must know the endpoint, auth scheme, and payload format in advance
const response = await fetch("https://plate-reader.local:8443/api/v2/measure", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    wells: ["A1", "A2"],
    wavelength: 450,
    unit: "nm",
  }),
});

// No standard error format - every vendor is different
if (!response.ok) {
  const error = await response.json(); // maybe? could be text, could be XML
  throw new Error(error.message ?? response.statusText);
}
const data = await response.json(); // schema unknown until you read vendor docs

Hersteller-SDK

// SDK: locked to one vendor, version-coupled, often Windows-only
import { PlateReaderSDK } from "@vendor/plate-reader-sdk"; // proprietary

const reader = new PlateReaderSDK({ port: "COM3" });
await reader.connect();
await reader.initialize(); // vendor-specific init sequence
const result = await reader.measureAbsorbance({
  wells: ["A1", "A2"],
  wavelength: 450,
}); // vendor-specific types
await reader.disconnect();

MCP

// MCP: universal protocol, dynamic discovery, validated schemas
import { Client } from "@modelcontextprotocol/sdk/client/index.js";

const client = new Client({ name: "lab-agent", version: "1.0.0" });
await client.connect(transport);

// Agent discovers tools dynamically - no hardcoded knowledge needed
const { tools } = await client.listTools();
const absorbanceTool = tools.find((t) => t.name === "read_absorbance");

// Schema validation happens automatically
const result = await client.callTool("read_absorbance", {
  wells: ["A1", "A2"],
  wavelength_nm: 450,
});
// Structured response with standard format

Der Unterschied ist grundlegend. Bei REST müssen Sie Endpunkte, Authentifizierung und Payload-Schemas kennen, bevor Sie die erste Codezeile schreiben. Hersteller-SDKs binden Sie an einen einzigen Hersteller. Mit MCP erkennt der Agent zur Laufzeit, was verfügbar ist, und jede Interaktion wird gegen ein Schema validiert. Für Labore mit 10–50 Geräten verschiedener Hersteller macht dies den Unterschied zwischen monatelanger und wenige Tage dauernder Integrationsarbeit aus.

Sicherheit – Schemavalidierung als erste Verteidigungslinie

Im Labor kann ein falscher Befehl teure Reagenzien verschwenden oder Geräte beschädigen. Die Schemavalidierung von MCP ist nicht optional, sondern struktureller Bestandteil des Protokolls.

Die Zod-Schemas im obigen Servercode leisten mehr als eine Typprüfung. Sie setzen fachliche Einschränkungen durch:

• Well-Positionen müssen einem Regex-Muster entsprechen – ungültige Koordinaten erreichen das Gerät nicht
• Wellenlänge ist auf 200–1000 nm begrenzt – den physikalischen Bereich der Lampe
• Volumen (bei Liquid-Handling-Geräten) lässt sich auf die maximale Kapazität der Pipette begrenzen
• Geschwindigkeits-Enums verhindern Motorbefehle ausserhalb der Spezifikation

Diese Validierung erfolgt auf zwei Ebenen. Der KI-Client validiert die Parameter vor dem Senden gegen das JSON-Schema. Der MCP-Server validiert sie beim Empfang erneut mit Zod. So bestehen zwei Schutzebenen, bevor eine physische Aktion stattfindet.

Für sicherheitskritische Operationen unterstützt MCP zudem eine Bestätigung durch einen Menschen (Human-in-the-Loop) über das Elicitation-Primitiv. Der Server kann die Ausführung anhalten und vor dem Fortfahren eine ausdrückliche Freigabe durch eine Wissenschaftlerin oder einen Wissenschaftler anfordern.

Bereitstellung von MCP-Servern in einem Labornetzwerk

Im Produktivbetrieb stehen Ihnen verschiedene Optionen zur Verfügung, wie MCP-Server mit Clients kommunizieren.

Stdio-Transport – Der Server läuft als Kindprozess des KI-Agenten. Diese Option eignet sich am besten für Einzelrechner-Setups, bei denen das Gerät direkt über USB oder eine serielle Schnittstelle angeschlossen ist. Geringe Latenz, kein Netzwerk-Overhead.

Streamable-HTTP-Transport – Der Server läuft als HTTP-Dienst und nimmt Verbindungen von entfernten KI-Agenten an. Diese Option eignet sich am besten für vernetzte Labore, in denen Geräte und Agenten auf separaten Rechnern laufen. Sie unterstützt mehrere gleichzeitige Clients, Standard-HTTP-Authentifizierung und Lastverteilung.

Eine praxisnahe Bereitstellung im Labor sieht so aus:

Jeder MCP-Server kapselt die herstellerspezifische Kommunikationsschicht. Der KI-Agent verbindet sich über das Netzwerk mit jedem Server und erkennt dessen Tools dynamisch. Um ein neues Gerät einzubinden, stellen Sie einen neuen MCP-Server bereit – ohne Änderungen am Agenten oder an anderen Servern.

Aktueller Stand der MCP-Verbreitung

MCP hat das experimentelle Stadium längst hinter sich gelassen. Im Dezember 2025 hat Anthropic MCP an die Agentic AI Foundation übergeben, die unter dem Dach der Linux Foundation angesiedelt ist. OpenAI, Google, Microsoft, AWS und Block sind Mitgründer und unterstützende Mitglieder.

Die Zahlen, Stand Anfang 2026:

• über 10'000 aktive öffentliche MCP-Server
• über 97 Millionen monatliche SDK-Downloads für Python und TypeScript
• Native Unterstützung in Claude, ChatGPT, VS Code, Cursor und Dutzenden weiterer Clients
• Offizielle SDKs für TypeScript, Python, Java, Kotlin, C#, Go, Swift und Rust

Für die Laborautomatisierung bedeutet dies, dass das Protokoll stabil und gut unterstützt ist und Bestand haben wird. Anbieter von Plattformen für die industrielle Automatisierung wie Inductive Automation (Ignition) haben bereits MCP-Module angekündigt. Als Nächstes folgt der Bereich der Laborgeräte.

Bei QPillars entwickeln wir bereits heute MCP-Server für Laborgeräte und kapseln dabei bestehende Hersteller-APIs mit der universellen Protokollschicht. Unsere Plattform für digitale Zwillinge verwendet dieselbe MCP-Schnittstelle für simulierte wie für reale Geräte. So können KI-Agenten Protokolle in der Simulation testen, bevor sie auf der Hardware ausgeführt werden.

Häufig gestellte Fragen

Wie verbinde ich einen KI-Agenten mit einem Laborgerät, das nur über eine serielle Schnittstelle verfügt?

Entwickeln Sie einen MCP-Server, der die serielle Kommunikation kapselt. Der Server übersetzt MCP-Tool-Aufrufe in serielle Befehle (SCPI, ASCII oder ein proprietäres Protokoll) und gibt strukturierte Antworten zurück. Der KI-Agent interagiert nie direkt mit der seriellen Schnittstelle. Er kommuniziert über MCP, und der Server übernimmt die Übersetzung. Bibliotheken wie serialport für Node.js machen dies unkompliziert.

Was passiert, wenn der KI-Agent ungültige Parameter an ein Gerät sendet?

MCP weist ungültige Parameter zurück, bevor sie die Hardware erreichen. Jede Tool-Definition enthält ein JSON-Schema mit Typen, Wertebereichen und Einschränkungen. Der KI-Client validiert ausgehende Parameter, und der MCP-Server validiert sie beim Empfang erneut mit Zod. Eine Anfrage mit wavelength_nm: 50000 oder wells: ["Z99"] scheitert bereits auf Schemaebene und nicht erst am Gerät.

Können mehrere KI-Agenten dasselbe Gerät gleichzeitig steuern?

Ja, allerdings mit Koordination. Ein MCP-Server mit Streamable-HTTP-Transport kann Verbindungen von mehreren Clients annehmen. Der Server ist für die Verwaltung des gleichzeitigen Zugriffs verantwortlich, typischerweise über eine Warteschlange oder einen Sperrmechanismus. Das unterscheidet sich nicht von anderen gemeinsam genutzten Ressourcen: Der MCP-Server bildet die Grenze für die Nebenläufigkeit und stellt sicher, dass eine Operation abgeschlossen ist, bevor die nächste beginnt.

Wie schneidet MCP im Vergleich zu SiLA 2 bei der Integration von Laborgeräten ab?

SiLA 2 standardisiert Geräteschnittstellen für die klassische Orchestrierung durch Software. Es definiert Befehle, Parameter und Datentypen für Laborgeräte. MCP standardisiert, wie KI-Agenten Tools erkennen und aufrufen. Die beiden ergänzen sich. Ein SiLA-2-Gerät lässt sich mit einem MCP-Server kapseln. Dadurch wird es für KI-Agenten zugänglich, während die SiLA-2-Schnittstelle für bestehende LIMS-Workflows erhalten bleibt.

Ist MCP ausgereift genug für den Produktiveinsatz in regulierten Laborumgebungen?

Auf der Protokollebene ist MCP produktionsreif. Die Spezifikation wird von der Linux Foundation verwaltet, von Anthropic, OpenAI, Google und Microsoft unterstützt und verzeichnet über 97 Millionen monatliche SDK-Downloads. In GxP-regulierten Umgebungen benötigen Sie rund um den MCP-Server weiterhin Validierungsdokumentation, Audit-Trails und Zugriffskontrollen. Dies sind jedoch Fragen der Implementierung und keine Einschränkungen des Protokolls.

Die wichtigsten Erkenntnisse

• MCP bietet KI-Agenten ein universelles Protokoll zum Erkennen und Steuern von Laborgeräten: ein MCP-Server pro Gerät, automatische Tool-Erkennung und schemavalidierte Befehle.
• Die Schemavalidierung auf Client- und Serverseite verhindert, dass ungültige Befehle die Hardware erreichen. Das ist entscheidend bei teuren Reagenzien und empfindlichen Geräten.
• Im Vergleich zu REST-APIs (individuell je Hersteller) und SDKs (an einen Hersteller gebunden) verkürzt MCP die Integration mehrerer Geräte von Monaten auf Tage.
• Mit über 10'000 öffentlichen Servern und der Verwaltung durch die Linux Foundation (Stand 2026) ist MCP der stabile, von der Branche getragene Standard für KI-Software zur Gerätesteuerung.
• Beginnen Sie noch heute, indem Sie bestehende Geräte-APIs mit MCP-Servern kapseln. Änderungen an der Hardware sind nicht nötig, und Ihre Geräte sind sofort für jeden MCP-kompatiblen KI-Agenten zugänglich.

---

Verfasst von Iacob Marian, Technischer Leiter und Mitgründer bei QPillars. Veröffentlicht am 2026-03-21.