Werkzeuge über Schnittstellen und MCP gezielt anbinden

Ein KI-Assistent soll eine passende Leistungsbeschreibung finden, einen Vorgang nachschlagen oder einen Entwurf vorbereiten. Dafür muss er nicht pauschal Zugriff auf eine ganze Datenbank oder die Bedienoberfläche eines Unternehmens erhalten. Ein klar begrenztes Werkzeug kann genau die benötigte Aufgabe anbieten. Schnittstellen und das Model Context Protocol helfen, solche Fähigkeiten zu beschreiben und nutzbar zu machen.

Die entscheidende Arbeit liegt dabei nicht allein in der Verbindung. Ein Werkzeug braucht einen verständlichen Auftrag, überprüfte Eingaben, passende Berechtigungen und ein zutreffendes Ergebnis. Dieser Leitfaden trennt diese Ebenen und zeigt eine vollständig ausführbare Leseoperation. Sie verwendet einen künstlichen öffentlichen Lehrkatalog ohne Netzwerkzugriff. Die 72 ausgeführten Prüfungen gelten für diese Funktion und ihre Ergebnishülle. Ein vollständiger MCP-Server oder eine produktive Anmeldung wird damit nicht behauptet. Quellenstand ist der 9. November 2026.

Mit einer konkreten Aufgabe beginnen

Die erste Frage lautet: Was soll die Person mit Hilfe des Assistenten erreichen? „Systemzugriff ermöglichen“ ist dafür zu unscharf. „Eine öffentliche Leistungsbeschreibung anhand einer bekannten Kennung in einer gewählten Sprache lesen“ ist dagegen eine prüfbare Aufgabe. Ihr Ergebnis und ihre Grenzen lassen sich schon vor einer Modellanbindung beschreiben.

Ein guter Werkzeugvertrag grenzt ähnliche Aufgaben voneinander ab. Eine Beschreibung lesen, einen Entwurf speichern und eine Nachricht versenden haben unterschiedliche Folgen. Werden sie in einem einzigen Werkzeug mit vielen verborgenen Betriebsarten vermischt, werden Auswahl und Kontrolle schwieriger. Die Trennung hilft zudem beim Test: Ein Lesewerkzeug darf nicht abhängig von einem unscheinbaren Parameter plötzlich einen Versand auslösen.

Im Lernfall gibt es zwei Leistungscodes und zwei Sprachen. Weitere Codes werden nicht ungefähr passend ergänzt. Für eine unbekannte Eingabe gibt es keinen frei erfundenen Ersatz. Eine echte Anwendung kann daraus eine verständliche Rückfrage oder eine passende Fehlermeldung ableiten. Sie sollte nicht so tun, als sei eine andere Leistung die angeforderte.

Fachfunktion, Schnittstelle und Modell unterscheiden

Die Fachfunktion führt eine genau beschriebene Operation aus. Ein Adapter übersetzt den Aufruf in die Sprache eines bestehenden Systems. Das Modell kann eine geeignete Operation vorschlagen und Parameter liefern. Diese Rollen sind voneinander unabhängig zu prüfen. Ein korrekt ausgewähltes Werkzeug beweist noch nicht, dass seine übergebenen Kennungen gültig oder für die anfragende Person erlaubt sind.

Eine vorhandene HTTP-API kann die fachliche Grundlage liefern. MCP beschreibt wiederum einen standardisierten Austausch von Fähigkeiten und Aufrufen. Es ersetzt weder automatisch die interne Geschäftslogik noch deren Datenmodell. Wer eine bestehende Anwendung anbinden möchte, sollte zuerst ihre vorhandenen lesenden und schreibenden Wege verstehen. Eine zusätzliche Protokollschicht repariert keine unklare Berechtigung im Zielsystem.

Die offizielle OpenAI-Anleitung für MCP-Server behandelt Werkzeugbeschreibung, Schemas und Autorisierung als zusammengehörige Aufgaben. Für unseren Entwurf folgt daraus eine klare Grenze: Die Beschreibung erleichtert die Auswahl. Ob eine private Information herausgegeben werden darf, entscheidet eine überprüfte serverseitige Berechtigung und keine Vermutung des Modells.

MCP als versioniertes Protokoll verstehen

Bei technischen Beispielen muss die verwendete Revision erkennbar sein. Die am genannten Quellenstand aktuelle MCP-Beschreibung zu Versionen und Kompatibilität unterscheidet moderne Aufrufe ab Revision 2026-07-28 von älteren Varianten. Die moderne Variante übermittelt den Protokollkontext je Anfrage. Ältere Revisionen bis 2025-11-25 verwenden einen Initialisierungsaustausch. Diese Unterschiede sollten nicht unbemerkt vermischt werden.

Ein vorhandener Client kann weiterhin eine ältere Variante unterstützen. Deshalb reicht die Aussage „MCP funktioniert“ als Kompatibilitätsangabe nicht aus. Dokumentieren Sie Client, Serverbibliothek und tatsächlich verwendete Revision. Ein Beispiel mit einem älteren Initialisierungsschritt ist nicht automatisch falsch. Es ist aber keine vollständige Beschreibung jeder heutigen Anbindung.

Das Grundprotokoll der Revision 2026-07-28 enthält weitere Anforderungen an Nachrichten und Metadaten. Die Versionsangabe und Clientfähigkeiten gehören bei dieser Revision zu den erforderlichen Informationen je Anfrage. Clientname und Version sind dagegen empfohlene Angaben. Solche Selbstauskünfte sind keine überprüfte Identität für eine Sicherheitsentscheidung. Das nachfolgende Modul baut ausdrücklich keinen vollständigen Nachrichtenserver nach.

Werkzeuge auffindbar und eindeutig beschreiben

Ein Werkzeugname sollte die Handlung erkennen lassen. Die Beschreibung erklärt, wann die Operation sinnvoll ist und wann ihre Grenzen erreicht sind. Im Lernfall heißt sie get_public_service. Die Beschreibung nennt einen begrenzten fiktiven Leistungskatalog. Sie behauptet keinen Zugriff auf aktuelle Kundenangebote oder auf die tatsächlichen Daten der Agentur.

Die MCP-Spezifikation zu Werkzeugen beschreibt unter anderem Werkzeuglisten, Aufrufe und Ein- sowie Ausgabeschemas. Ein Client kann darüber erkennen, welche Parameter vorgesehen sind. Ein Schema ist jedoch nur dann wirksam, wenn die ausführende Seite die Eingaben auch tatsächlich entsprechend behandelt. Eine schöne Werkzeugbeschreibung ist keine Eingabeprüfung.

Lesen, Berechtigung und Aktionsfreigabe trennen

Eine öffentliche Leistungsbeschreibung benötigt in diesem Lehrfall keine private Identität. Ein Werkzeug für einen Kundenauftrag hätte dagegen andere Anforderungen. Es müsste die anfragende Person verlässlich zuordnen und ihren erlaubten Zugriff auf genau diesen Auftrag prüfen. Eine vom Modell genannte Kundennummer ist kein Beweis, dass diese Person die Daten sehen darf.

Auch eine ausdrücklich bestätigte Aktion ersetzt diese Prüfung nicht. Eine Person kann nur innerhalb ihrer tatsächlichen Rechte handeln. Umgekehrt bedeutet eine gültige Anmeldung nicht automatisch, dass jede vorgeschlagene folgenreiche Handlung ohne weitere Prüfung ausgeführt werden soll. Fachliche Zulässigkeit, Kontoberechtigung und der konkret beauftragte Schritt müssen zusammenpassen.

Die OpenAI-Dokumentation zur MCP-Anbindung in der Responses API beschreibt einen anwendungsspezifischen Freigabeablauf für Werkzeugaufrufe. Das ist von der eigentlichen Autorisierung des Zielsystems zu unterscheiden. Eine Freigabe auf einer Oberfläche darf keine fehlende Datenberechtigung im Backend verdecken. Die konkrete Gestaltung richtet sich nach der verwendeten Integration und den Folgen der Aufgabe.

Hinweise über Nebenwirkungen korrekt einordnen

Werkzeugmetadaten können Hinweise auf lesende, verändernde oder offene externe Zugriffe enthalten. Diese Hinweise sollten das tatsächliche Verhalten beschreiben. Ein Werkzeug, das eine Nachricht versendet oder eine Warteschlange startet, ist nicht rein lesend, nur weil es keine Datenbankzeile unmittelbar verändert. Auch indirekte Folgen gehören zur Betrachtung.

Unsere Funktion liest ausschließlich aus einem festen Katalog im Programm. Sie verändert diesen Bestand nicht und ruft keine fremde Adresse auf. Dazu passen ihre angegebenen Hinweise. Ein späterer Umbau zu einem Werkzeug mit Speicherung oder Websuche würde eine neue Prüfung der Beschreibung und der Hinweise erfordern. Ein unverändert stehen gebliebenes Etikett macht eine neue Nebenwirkung nicht ungefährlich.

Insbesondere sind die Hinweise keine technische Schranke. Die ausführende Anwendung muss ihre Berechtigungen und erlaubten Ziele unabhängig durchsetzen. Eine positive Selbstauskunft eines unbekannten Servers reicht nicht als Vertrauensbeweis. Für die Abnahme wird daher zuerst das wirkliche Verhalten betrachtet und anschließend geprüft, ob die Metadaten es zutreffend wiedergeben.

Die vollständige begrenzte Werkzeugfunktion

Das folgende Modul kann ohne externe Bibliothek als JavaScript-Modul importiert werden. Es enthält den Werkzeugvertrag, den künstlichen Katalog, die Argumentprüfung und die Ergebnishülle. Eine gültige Kombination ergibt eine neue Rückgabeinstanz. Das verhindert, dass ein Aufrufer durch Änderungen am zurückgegebenen Objekt den internen Bestand unabsichtlich verändert.

export const toolDefinition = {
  name: 'get_public_service',
  description: 'Liest eine öffentliche, fiktive Leistungsbeschreibung aus dem begrenzten Lehrkatalog.',
  inputSchema: {
    type: 'object',
    properties: {code: {type: 'string', enum: ['web', 'automation']}, locale: {type: 'string', enum: ['de', 'en']}},
    required: ['code', 'locale'],
    additionalProperties: false
  },
  outputSchema: {
    type: 'object',
    properties: {code: {type: 'string'}, locale: {type: 'string'}, title: {type: 'string'}, summary: {type: 'string'}},
    required: ['code', 'locale', 'title', 'summary'],
    additionalProperties: false
  },
  annotations: {readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: false}
};

const catalogue = {
  web: {
    de: {title: 'Fiktive Leistung: Webseite', summary: 'Lehrangebot für die Planung einer verständlichen Unternehmenswebseite.'},
    en: {title: 'Fictional service: website', summary: 'Teaching offer for planning an understandable business website.'}
  },
  automation: {
    de: {title: 'Fiktive Leistung: Automatisierung', summary: 'Lehrangebot zur Beschreibung und Prüfung eines begrenzten Arbeitsablaufs.'},
    en: {title: 'Fictional service: automation', summary: 'Teaching offer for specifying and evaluating a bounded workflow.'}
  }
};

export function getPublicService(args) {
  if (!args || typeof args !== 'object' || Array.isArray(args) ||
      Object.keys(args).sort().join(',') !== 'code,locale' ||
      !['web', 'automation'].includes(args.code) || !['de', 'en'].includes(args.locale)) {
    throw new TypeError('Invalid service arguments');
  }
  const item = catalogue[args.code][args.locale];
  return {code: args.code, locale: args.locale, title: item.title, summary: item.summary};
}

export function serviceToolResult(args) {
  const value = getPublicService(args);
  return {
    resultType: 'complete',
    structuredContent: value,
    content: [{type: 'text', text: JSON.stringify(value)}],
    isError: false
  };
}

Die Argumentprüfung erlaubt genau die beiden vorgesehenen Felder. Unbekannte Codes, unbekannte Sprachen und zusätzliche Werte werden zurückgewiesen. Insbesondere werden keine frei übergebenen Pfade, URLs oder Befehle interpretiert. Der feste Katalog ist eine bewusste Begrenzung der Aufgabe. Eine allgemeine Funktion „hole beliebige Daten“ hätte eine erheblich größere Prüf- und Berechtigungsfläche.

Das Modul ist eine Fachfunktion mit einer Ergebnishülle. Transport, Protokollerkennung, Serverbeschreibung, Zugriffsprüfung privater Konten und die Einbindung in einen konkreten Client sind eigene Aufgaben eines vollständigen Adapters. Ein dort gefangener Eingabefehler muss in eine passende Protokollantwort übersetzt werden. Das Werfen eines JavaScript-Fehlers ist allein noch keine vollständige MCP-Fehlerbehandlung.

Ein konkretes Ergebnis nachvollziehen

Für code: "web" und locale: "de" liefert die Funktion eine ausdrücklich fiktive Webseitenleistung. Der strukturierte Inhalt enthält dieselben Werte wie die textuelle JSON-Ausgabe. Beide Darstellungen entstehen aus demselben Objekt. Sie sollen nicht voneinander abweichende Zahlen, Kennungen oder Beschreibungen vermitteln.

{
  "resultType": "complete",
  "structuredContent": {
    "code": "web",
    "locale": "de",
    "title": "Fiktive Leistung: Webseite",
    "summary": "Lehrangebot für die Planung einer verständlichen Unternehmenswebseite."
  },
  "content": [
    {
      "type": "text",
      "text": "{\"code\":\"web\",\"locale\":\"de\",\"title\":\"Fiktive Leistung: Webseite\",\"summary\":\"Lehrangebot für die Planung einer verständlichen Unternehmenswebseite.\"}"
    }
  ],
  "isError": false
}

Die Ergebnishülle verwendet resultType: "complete" entsprechend der hier beschriebenen modernen Revision. Ein SDK oder Adapter für eine andere Revision muss deren Vertrag einhalten. Diese einzelne Hülle enthält weder die vollständige JSON-RPC-Antwort noch alle Metadaten einer tatsächlichen Verbindung. Sie darf nicht unverändert als Beweis einer erfolgreichen Serveranbindung ausgegeben werden.

Die 72 tatsächlich ausgeführten Prüfungen lesen

Der gespeicherte Prüflauf untersucht alle vier gültigen Kombinationen aus Code und Sprache. Er kontrolliert wiederholbare Ergebnisse, die genaue Form, die übernommenen Kennungen, die Übereinstimmung von Text und strukturiertem Inhalt sowie den Abschlussstatus. Zusätzlich verändert er ein zurückgegebenes Objekt und prüft, dass eine neue Abfrage weiterhin den unveränderten Katalog liefert.

Zwanzig ungültige Argumentvarianten werden jeweils an der Fachfunktion und an der Hülle geprüft. Dazu gehören fehlende Felder, falsche Typen, zusätzliche Ziele und spezielle Eigenschaftsnamen. Vier weitere Erwartungen betreffen die geschlossenen Schemas und den beschriebenen Lesecharakter. Zusammen bestanden 72 Erwartungen. Diese Zahl belegt die untersuchten Eigenschaften des Moduls und keine universelle Sicherheit einer MCP-Installation.

Es wurde kein Sprachmodell aufgerufen, keine OAuth-Verbindung hergestellt und kein produktiver Dienst abgefragt. Für eine reale Einbindung kommen weitere Tests hinzu: passende Protokollrevision, echte Transportfehler, nicht berechtigte Konten, begrenzte Laufzeiten und das Verhalten des verwendeten Clients. Die Trennung der Nachweise schützt davor, einen gelungenen Funktionstest als vollständige Integrationsabnahme zu missverstehen.

Fehler und Wiederholungen fachlich behandeln

Ungültige Argumente, fehlende Berechtigung, ein nicht vorhandener Datensatz und ein ausgefallenes Zielsystem sind unterschiedliche Situationen. Sie sollten nicht sämtlich als leeres erfolgreiches Ergebnis erscheinen. Ein verständlicher Fehler hilft dem Assistenten und der Person, den nächsten sinnvollen Schritt zu wählen. Interne Zugangsdaten oder vertrauliche Diagnoseinhalte gehören dafür nicht in die Antwort.

Beim Schreiben wird die Wiederholung besonders wichtig. Wenn nach einem Zeitlimit unklar ist, ob eine Aktion ausgeführt wurde, kann ein blindes erneutes Auslösen doppelte Vorgänge erzeugen. Die betreffende Operation braucht dann ein eigenes fachliches Verfahren für eindeutige Vorgänge und Statusabfragen. Ein Hinweis auf Idempotenz im Werkzeugvertrag implementiert dieses Verfahren nicht von selbst.

Für den Lernkatalog ist die Lage einfach: Das Lesen hat keine solche Schreibwirkung. Mehrfache gültige Aufrufe liefern denselben Inhalt. Daraus folgt keine Aussage über eine spätere Nachrichtenschnittstelle oder Zahlungsanbindung. Jede neu hinzugefügte Operation bekommt einen eigenen beschriebenen Vertrag und entsprechende Gegenfälle statt eine pauschale Übernahme der Freigabe des Lesewerkzeugs.

Zugangsdaten und fremde Inhalte begrenzen

Die MCP-Sicherheitshinweise beschreiben unter anderem Risiken ungeprüft weitergereichter Tokens und ungewollter Netzwerkziele. Für die Architektur folgt daraus: Ein Token muss für seinen tatsächlichen Empfänger und Zweck geprüft werden. Es gehört weder in den Prompt noch in ein frei sichtbares Werkzeugergebnis. Ein allgemeiner Zugang zu beliebigen Adressen benötigt weitere Schutzmaßnahmen.

Auch eine gelesene Beschreibung kann unzuverlässige Inhalte enthalten. Wenn ein externer Datensatz den Assistenten auffordert, eine andere Aktion auszuführen, ist das zunächst Dateninhalt und keine neue Berechtigung. Der eigentliche Werkzeugvertrag und die zuständige Anwendung bestimmen die erlaubte Operation. Eine solche Grenze sollte mit gezielten Beispielen untersucht werden, sobald externe Inhalte eingebunden werden.

Unser künstlicher Katalog enthält ausschließlich feste neutrale Texte. Er führt deshalb keinen realen Angriffstest gegen einen Anbieter durch. Für eine spätere Erweiterung sollte der Testbestand sowohl normale Anfragen als auch irreführende Inhalte und unberechtigte Zugriffsversuche aufnehmen. Ein einzelner abgewehrter Beispielsatz rechtfertigt keine Behauptung, alle Manipulationen seien ausgeschlossen.

Eine echte Integration schrittweise abnehmen

Beginnen Sie mit dem kleinsten brauchbaren Leseablauf und prüfen Sie ihn unabhängig vom Modell. Danach wird der Adapter mit seinem tatsächlichen Client verbunden. Erst anschließend wird untersucht, ob der Assistent bei verschiedenen Formulierungen das richtige Werkzeug wählt und zulässige Argumente übergibt. So lässt sich ein Auswahlproblem von einem fachlichen oder technischen Fehler unterscheiden.

Bei privaten Daten braucht die Abnahme mindestens eine berechtigte und eine nicht berechtigte Situation. Prüfen Sie außerdem eine gültige Kennung aus einem anderen Zuständigkeitsbereich. Ein korrekt formatiertes Argument kann trotzdem unzulässig sein. Die ausführende Anwendung muss diesen Unterschied erkennen. Eine Prüfung nur mit einem allmächtigen Administratorkonto würde diese Grenze nicht ausreichend untersuchen.

Änderungen an Namen, Parametern oder Ergebnissen benötigen eine erkennbare Version und gezielte erneute Tests. Ein Client kann ältere Informationen zwischenspeichern. Bestehende Abläufe sollten deshalb einen geänderten Vertrag nicht stillschweigend erhalten. Dokumentieren Sie, welche Kombination tatsächlich geprüft wurde und wie ein fehlerhafter Stand zurückgenommen werden kann. Zusätzliche Werkzeuge werden als neue Fähigkeiten bewertet.

Checkliste für eine nachvollziehbare Werkzeuganbindung

Ein konkreter Abnahmeablauf kann mit der deutschen Webseitenbeschreibung beginnen. Der erwartete Code bleibt web, die Sprache bleibt de und der Titel bezeichnet ausdrücklich eine fiktive Leistung. Danach wird dieselbe Leistung in Englisch angefragt. Ein Sprachwechsel darf keine andere fachliche Kennung erzeugen. Erst danach folgen unbekannte Codes und zusätzliche Parameter. Dadurch bleibt klar, welche Eigenschaft jeder Schritt untersucht.

Für die Modellauswahlprüfung lassen sich unterschiedliche Formulierungen derselben Absicht verwenden. „Zeige die Webseitenleistung auf Englisch“ und eine ausführlichere Frage sollten zur gleichen erlaubten Kombination führen, sofern der Kontext eindeutig ist. Eine unklare Bitte wie „zeige das andere Angebot“ benötigt dagegen Kontext oder eine Rückfrage. Das Werkzeug selbst sollte diese Unklarheit nicht durch einen willkürlichen Standardcode kaschieren.

Datenumfang und Betriebsbeobachtung gezielt planen

Eine Antwort sollte die für die Aufgabe nötigen Informationen enthalten. Im Lernfall reichen Code, Sprache, Titel und Zusammenfassung. Eine echte Anbindung könnte weitere fachlich erforderliche Felder benötigen. Interne Kontokennungen, vollständige Protokolle und Zugangsinformationen sind aber nicht automatisch nützlich, nur weil sie im Zielsystem verfügbar sind. Der Ausgabevertrag muss erklären, was die aufrufende Seite tatsächlich erhält.

Auch Betriebsnachweise brauchen einen beschriebenen Umfang. Für eine Fehlersuche können Werkzeugname, Ergebnisart und eine geeignete technische Zuordnung hilfreich sein. Daraus folgt keine pauschale Aufforderung, sämtliche Argumente und Inhalte dauerhaft mitzuschreiben. Je nach Aufgabe können darin vertrauliche Informationen stehen. Legen Sie fest, welche Diagnoseangaben benötigt werden, wer darauf zugreifen darf und wie sie mit dem fachlichen Vorgang zusammenhängen.

Bei einer entfernten Schnittstelle werden außerdem Laufzeit und Ausfallverhalten Teil des Vertrags. Ein Zeitlimit begrenzt das Warten. Es beweist nicht, dass das Zielsystem die Operation abgebrochen hat. Besonders bei Veränderungen muss deshalb erkennbar bleiben, ob das Ergebnis unbekannt ist oder die Ausführung sicher unterblieben ist. Diese Unterscheidung schützt vor einer falschen Erfolgsmeldung ebenso wie vor einer unnötigen doppelten Ausführung.

Im Betrieb sollte eine Änderung nicht nur anhand eines erfolgreichen Beispiels beurteilt werden. Wiederholen Sie die bereits bekannten Gegenfälle. Prüfen Sie zusätzlich, ob frühere Clients die neue Antwort noch verstehen. Wenn ein bisheriges Feld verschwindet oder seine Bedeutung wechselt, kann eine formal gültige Antwort fachlich falsch verarbeitet werden. Eine kompatible Erweiterung und eine bewusst neue Vertragsversion sind unterschiedliche Wege mit jeweils eigenen Voraussetzungen.

Die Verantwortung für diese Entscheidungen liegt bei der Anwendung. Der Assistent kann einen Vorschlag formulieren, einen Aufruf auswählen oder ein Ergebnis erklären. Er ersetzt damit keine festgelegte Datenberechtigung und keine eindeutige Geschäftsregel. Ein begrenztes Werkzeug ist gerade deshalb nützlich, weil es die zulässige Operation konkret macht und sich an nachvollziehbaren Erwartungen prüfen lässt.

• Eine konkrete Aufgabe und ihr korrektes Ergebnis beschreiben.
• Lesen, Entwurf und folgenreiche Aktionen sinnvoll trennen.
• Modell, Adapter und Fachfunktion unabhängig prüfen.
• Client, Bibliothek und Protokollrevision dokumentieren.
• Eingaben serverseitig auf erlaubte Felder und Werte begrenzen.
• Private Daten je Anfrage anhand überprüfter Berechtigungen schützen.
• Nebenwirkungen wahrheitsgemäß beschreiben und tatsächlich begrenzen.
• Textuelle und strukturierte Ergebnisse konsistent halten.
• Fehler, Zeitlimits und Wiederholungen ohne erfundene Erfolge behandeln.
• Zugangsdaten und unnötige vertrauliche Informationen aus Ergebnissen heraushalten.
• Gültige, ungültige und nicht berechtigte Situationen getrennt testen.
• Den Nachweis einer Fachfunktion nicht mit einer vollständigen Serverabnahme verwechseln.

Eine gute Anbindung macht eine nützliche Fähigkeit verständlich und begrenzt. Die Person erhält ein zutreffendes Ergebnis und die ausführende Anwendung behält klare Zuständigkeiten. MCP kann den Austausch vereinheitlichen. Die Qualität entsteht aus dem passenden Auftrag, überprüften Grenzen und einer Abnahme der tatsächlich eingesetzten Komponenten.