Die Idee hinter dem Vertec MCP Server

MCP (Model Context Protocol) ist ein relativ neuer Standard in der Schnittstellenwelt: Ende 2024 von Anthropic vorgeschlagen, um es LLMs zu ermöglichen, für die Antwortbereitstellung mit der Aussenwelt zu kommunizieren, wurde es von anderen AI Firmen wie OpenAI erst im Laufe des 2025 adaptiert. Doch trotz der noch jungen Geschichte haben sich MCP Server rasant verbreitet, weil der Nutzen für die User auf der Hand liegt: So kann ein Chat in einem AI Client wie Claude sich nicht mehr nur um allgemein verfügbares Weltwissen drehen, sondern es können auch eigene Daten und Dienste in den Chat mit einbezogen werden.

Der im Juli 2026 publizierte Vertec MCP Server ermöglicht genau das: sich in einem Chat auf die eigenen Vertec Daten zu beziehen. In diesem Blogartikel möchte ich die Idee hinter dem Vertec MCP Server etwas erläutern.

Wie funktionieren MCP Server überhaupt? Ein MCP Server wird im eigenen AI Client / AI Agent als «Connector» hinzugefügt und publiziert «Tools» gegenüber dem LLM. So ein «Tool» kann z.B. ein Rechner sein, der dem LLM hilft, mathematische Rechnungen anzustellen. Das «Tool» calculator hat folgende Description:

Evaluates a mathematical expression and returns the numeric result. Use this whenever a query requires precise arithmetic, such as sums, percentages, or multi-step calculations, rather than relying on estimation.

Diese nimmt es als Parameter expression auf, was z.B. (240 - 15%) / 3 sein könnte. Adressat von «... use this ...» ist dabei das LLM selber, es liest diese Descriptions und wenn es der Meinung ist, man müsse was rechnen, weiss es genau, wie man dieses Tool aufrufen muss.

Der Vertec MCP Server stellt aktuell 13 «Tools» zur Verfügung und gibt dem LLM via Description einen genauen Ablauf vor, wie dieses vorgehen soll: 

1. Das LLM muss sich zuerst über schema_list_objects informieren, welche Vertec Datenklassen es überhaupt gibt. Der Webservice ModelMetadata stellt diese Information bereit und macht eine Auswahl, die für CRM und ERP Abfragen in der Regel relevant sind, also Project, Invoice aber auch Approval und Offer. Hinzugefügt zu der statischen Liste («Whitelist») werden alle Klassen, für die es Klasseneinstellungen gibt: Das können Klassen sein, die nicht in der «Whitelist» sind, aber auch Zusatzklassen aus Zusatzfunktionen oder anderen kundenspezifischen Implementationen. Wichtig zu wissen: Für Zusatzklassen werden die Bemerkungen als Erklärung, was diese Klasse ist, mitgeliefert.
2. Weiss das LLM über die Klassenliste, an welchen Klassen es im Detail interessiert ist, ruft es schema_describe_object auf. Dieses «Tool» nimmt einen Klassennamen als Parameter und liefert alle Daten der Klasse selber, alle Attribute und Associations, jeweils mit Erklärungstexten. Dies sind für fix eingebaute Attribute und Associations die Texte, die man auch im Model Browser oder im Expression Editor sieht, für eigene Attribute (=Zusatzfelder) und Associations (=Custom-Link-Typen) sind es die Bemerkungen auf diesen Einstellungsobjekten.
3. Erst mit diesen Informationen «erlauben» wir dem LLM dann Vertec Objekte zu suchen und mit diesen weiterzuarbeiten, z.B. BI Kennzahlen abzufragen, Funktionen aufzurufen oder von einem Objekt weiter zu navigieren.

Wer die Descriptions und die Tools selber mal anschauen möchte, kann seinen AI Client bei verbundenem Vertec MCP Server mal danach fragen. Zentral an dem Konzept hinter dem Vertec MCP Server ist also die Idee, dass es nur generische Methoden gibt und kein search_invoice oder create_address. Dieser Ansatz erlaubt es dem LLM via MCP und Vertec REST API also auch kundenspezifische Implementationen abzufragen und zu bearbeiten und ganz generell Fragen zu beantworten, an die kein Vertec Entwickler je gedacht hat. Zentral ist, dass das LLM überhaupt «entdeckt», was für die Frage relevant ist. Darum sind sprechende Namen und Bezeichnungen bei Zusatzfeldern sehr wichtig, wie auch Bemerkungstexte bei Zusatzklassen, Zusatzfeldern und eigenen Linktypen.