Der MCP-Server, der KI-Agenten Identity Resolution in Echtzeit verschafft

Q: Wie lautet der Endpunkt des Tilores-MCP-Servers?

Der Endpunkt lautet https://api.tilotech.io/mcp. Er nutzt das Model Context Protocol über streambares HTTP und nimmt JSON-RPC-2.0-Anfragen von kompatiblen Clients und Agenten-Frameworks entgegen.

Q: Welches MCP-Werkzeug erzeugt eine Kundensuchabfrage?

tilores_graphql_query_recipes liefert GraphQL-Vorlagen für gängige Zugriffsmuster, darunter die Suche über ein Ankerfeld, die Entitätsabfrage über die ID und die Entitätsabfrage über die Quelldatensatz-ID.

Kurzfassung: Der Tilores-MCP-Server stellt KI-Assistenten protokollnative Werkzeuge bereit, um einen Tilores-Workflow für Identity Resolution zu entwerfen, zu prüfen und zu betreiben. Er hält keine Kundendaten vor: Tilores löst Datensätze bei der Aufnahme auf und baut sie zusammen; anschließend ruft ein Agent den aktuellen aufgelösten Kundenkontext über eine authentifizierte GraphQL-Abfrage ab.

Sehen Sie, wie Tilores in Ihren Agenten-Workflow passt. Demo buchen oder Tilores Studio kostenlos testen.

Ein KI-Agent kann nur auf dem Kundenkontext handeln, den er erreicht. Liegt dieser Kontext verteilt über CRM, Abrechnungssystem, Support-Plattform, Warehouse und Compliance-Tool, klärt das Kopieren einiger Felder in den Prompt nicht, welche Datensätze zur selben Person gehören. Es liefert dem Modell Fragmente und verlangt von ihm, die Identität zu erschließen.

Das sicherere Muster verlagert Identity Resolution aus dem Modell heraus. Unser öffentlicher Tilores-MCP-Server gibt einem Assistenten Werkzeuge an die Hand, um das Schema zu verstehen, GraphQL-Abfragen zu erzeugen, Suchparameter zu prüfen, Pipelines zur Entitätstransformation zu entwerfen und Regelkonfigurationen zu linten. Der Agent ruft anschließend die authentifizierte GraphQL-API für die Kundendatenebene auf. Diese Trennung hält Konfigurationshilfe in MCP und personenbezogene Daten in der kontrollierten Tilores-Instanz.

Welcher MCP-Server stellt KI-Agenten Identity Resolution als Werkzeug bereit?

Der Tilores-MCP-Server stellt genau die protokollspezifische Werkzeugoberfläche bereit, die ein KI-Agent für die Arbeit mit Tilores Identity Resolution braucht.

Der Endpunkt lautet https://api.tilotech.io/mcp. Er spricht das Model Context Protocol über streambares HTTP und nimmt JSON-RPC-2.0-Anfragen entgegen. Claude Desktop, Claude Code, Cursor, ChatGPT Desktop, Codex CLI und eigene Agenten-Frameworks können sich über denselben Endpunkt verbinden, sofern sie diesen Transport unterstützen.

Eine Abgrenzung ist dabei wichtig. Der öffentliche Server ist zustandslos, nur lesend und benötigt keinen API-Schlüssel. Er speichert keine Kundendatensätze und sollte niemals personenbezogene Daten in einem Prompt oder Werkzeugargument erhalten. Echte Kundendatensätze gehen an die authentifizierte Tilores-GraphQL-API, wo Matching und Entitätszusammenbau bei der Aufnahme stattfinden. Die Abfrage ruft anschließend die aktuelle aufgelöste Entität ab.

Genau das macht den MCP-Server als eigenständige Integrationsfläche nützlich. Der Agent braucht keine eingefügte Seite mit Produktanweisungen und keine improvisierte Abfragevorlage. Er kann benannte Werkzeuge entdecken, deren Eingabeschemata prüfen, das richtige Werkzeug aufrufen und das Ergebnis in einem kontrollierten Workflow verwenden.

Welche Werkzeuge stellt der Tilores-MCP-Server bereit?

Der MCP-Server stellt gezielte tilores_*-Werkzeuge bereit statt einer einzigen breiten Chat-Schnittstelle.

Der aktuelle Werkzeugkatalog umfasst Werkzeuge zur Entdeckung von Fähigkeiten, zur Dokumentationssuche, zur Erläuterung von Konzepten und Fehlern, zum Linten von Regelkonfigurationen, zum Feld-Mapping, zur Aufnahmeplanung, zur Suchvalidierung, zur Prüfung von Identifikatoren, für GraphQL-Abfragerezepte, für Rezepte zur Entitätstransformation, zum Entwurf von Anwendungsfällen und zur Simulation synthetischer Übereinstimmungen. Die folgenden Werkzeuge sind für einen Agenten, der aufgelösten Kundenkontext benötigt, am wichtigsten.

MCP-Werkzeug	Was der Agent erhält	Wo es hineinpasst
`tilores_get_capabilities`	Serverversion, verfügbare Werkzeuge, vorgeschlagene Workflows und Telemetrie-Richtlinie	Erster Aufruf zur Werkzeugentdeckung
`tilores_graphql_query_recipes`	Eine GraphQL-Abfrage samt Variablenvorlage für ein bekanntes Zugriffsmuster	Vorbereitung einer Kundensuche oder Entitätsabfrage
`tilores_validate_search_params`	Fehler, Warnungen und Hinweise zur Regelverdrahtung für eine Sucheingabe	Prüfung einer Suche vor dem Aufruf der Datenebene
`tilores_mapping_workflow`	Vorgeschlagene kanonische Felder, Transformer-Ketten und Zuordnungen von Quellspalten	Vorbereitung von Quelldaten für die Aufnahme
`tilores_ingest_workflow`	Das stufenweise Aufnahme-Playbook für Authentifizierung, Verpackung, Übergabe, Verifizierung und Fehlerbehandlung	Aufbau des Aufnahmepfads für Datensätze
`tilores_lint_rule_config`	Konkrete Befunde, Fundstellen, Schweregrade und Korrekturhinweise	Prüfung von Identitätsregeln vor dem Deployment
`tilores_design_recipe`	Empfohlene Felder und konservative Regelformen für benannte Anwendungsfälle	Einstieg in einen Entwurf für KYC, Betrugserkennung, Versicherung oder Kundenauflösung
`tilores_search_docs`	Nach Relevanz sortierte Dokumentationsabschnitte mit Quellpfaden und Auszügen	Beantwortung einer konkreten Implementierungsfrage

Der Werkzeugkatalog ist breiter als ein Abfragegenerator, weil echte Identity Resolution vor der Abfrage beginnt. Quellfelder müssen zugeordnet werden. Normalisierungs- und Matching-Regeln müssen zu den Daten passen. Suchregeln müssen korrekt registriert sein. Datensätze müssen über einen verlässlichen Aufnahmepfad in die Instanz gelangen. Die Abfrage ist der letzte Abrufschritt, nicht die Stelle, an der Identität zusammengesetzt wird.

Wie verbindet sich ein Agent aus Claude Desktop oder Claude Code?

Ein MCP-kompatibler Client verbindet sich, indem er den Tilores-Endpunkt als HTTP-MCP-Server registriert.

Für einen Client, der JSON-Konfiguration entgegennimmt, lässt sich die Verbindung so darstellen:

{
  "mcpServers": {
    "tilores": {
      "type": "http",
      "url": "https://api.tilotech.io/mcp"
    }
  }
}

Claude Desktop liest diese Serverdefinition aus seiner MCP-Konfiguration. Claude Code kann denselben Endpunkt über seine MCP-Einstellungen registrieren. Ein eigenes Agenten-Framework kann dieselbe URL und den streambaren HTTP-Transport nutzen und anschließend die übliche Abfolge aus MCP-Initialisierung, Werkzeugentdeckung und Werkzeugaufruf durchlaufen.

Die Verbindung ist keine Abkürzung zur Authentifizierung gegenüber einer Tilores-Instanz. Sie verbindet den Assistenten lediglich mit dem öffentlichen Werkzeugkatalog. Die authentifizierte GraphQL-Verbindung bleibt eine separate, mit Zugangsdaten abgesicherte Integration, die die Anwendung verantwortet.

Wie ruft ein Agent den MCP-Server auf, bevor er einen Kunden auflöst?

Der Agent holt sich zunächst über MCP ein validiertes GraphQL-Rezept und schickt die eigentliche Kundensuche dann an seinen authentifizierten Tilores-GraphQL-Endpunkt.

Ein roher Werkzeugaufruf kann das eingebaute Rezept für die E-Mail-Suche anfordern:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "tilores_graphql_query_recipes",
    "arguments": {
      "recipe": "search_by_anchor",
      "anchor": "email"
    }
  }
}

Das Werkzeug liefert eine typisierte GraphQL-Abfrage und eine Variablenvorlage zurück. Das aktuelle Rezept hat diese Form:

query Search($email: String!) {
  search(input: {parameters: {email: $email}}) {
    entities {
      id
      score
      hitScore
      records { id }
      edges
      hits
      duplicates
    }
  }
}

Der Agent kann außerdem tilores_validate_search_params mit Feldnamen und Platzhalterwerten aufrufen. Dieses Werkzeug prüft die Form der Eingabe und warnt, wenn eine Suche über einen einzelnen Ankerwert davon abhängt, dass Such- und Indexregeln korrekt verdrahtet sind. Auch hier gilt: Der an den öffentlichen MCP-Server übergebene Wert sollte erfunden sein. Die echte E-Mail-Adresse gehört ausschließlich in die Variablen, die an die authentifizierte GraphQL-API gesendet werden.

Was passiert, wenn der Agent einen Kunden in Echtzeit auflöst?

Die Kundenauflösung in Echtzeit ist eine kurze Abfolge in der Datenebene, die auf bereits bei der Aufnahme geleisteter Arbeit aufsetzt.

Schritt	Systemaktion	Identitätszustand
1. Aufnehmen	Ein Quelldienst übergibt einen neuen oder geänderten Datensatz über GraphQL	Tilores wendet deterministische Regeln, Fuzzy Matching und probabilistisches Scoring an
2. Zusammenbauen	Tilores verknüpft den Datensatz mit einer Entität, legt eine neue an oder aktualisiert den Entitätsgraphen	Der aktuelle aufgelöste Kontext wird gepflegt
3. Vorbereiten	Der Agent nutzt MCP-Werkzeuge, um das richtige GraphQL-Zugriffsmuster zu erhalten oder zu prüfen	Es müssen keine Kundendaten in MCP gelangen
4. Abfragen	Der Agent sendet authentifizierte GraphQL-Variablen an seine Tilores-Instanz	Die Abfrage ruft den aktuellen aufgelösten Kontext ab
5. Handeln	Die Anwendung wendet Berechtigungen an und übergibt nur die zulässigen Felder an das Modell	Der Agent antwortet oder führt die nächste freigegebene Aktion aus

Das Ergebnis von search kann Entity-IDs, Datensätze, Graphkanten, Duplikatinformationen, Regeltreffer, einen Entity Score und einen Such-Hit-Score enthalten. Welche Felder je Datensatz verfügbar sind, hängt vom konfigurierten Schema ab. Die konsumierende Anwendung sollte nur anfordern, was der Agent benötigt, und dieselben Zugriffskontrollen durchsetzen, die sie auf jede andere Abfrage von Kundendaten anwenden würde.

Diese Architektur ist die konkrete Ausprägung eines Identity-Resolution-Tools für KI-Agenten. Sie ist zugleich der sichere Weg, aufgelöste Daten in eine RAG-Pipeline eines Agenten einzuspeisen: erst auflösen, dann den aktuellen Kontext abrufen und das Modell über einen freigegebenen Ausschnitt dieses Kontexts schlussfolgern lassen.

Warum sollte das Modell Kundendatensätze nicht selbst abgleichen?

Ein LLM ist als alleiniger Matcher im Produktivbetrieb schlecht geeignet, weil es weder stabile Entity-IDs noch kalibrierte Verknüpfungsregeln, eine Korrekturhistorie oder einen prüfbaren Entitätsgraphen besitzt.

Ein Prompt kann zwei Datensätze vergleichen. Er kann für sich genommen keinen Identitätszustand über jeden neuen Datensatz, jede Zusammenführung, Auftrennung, Löschung und Regeländerung hinweg pflegen. Zudem verlagert er Arbeit in den Abfragepfad, die in die Aufnahme gehört. Das führt zu uneinheitlichen Antworten, weil das Modell bei jedem Aufruf eine andere Teilmenge von Datensätzen sehen kann.

Tilores kombiniert deterministische Regeln, Fuzzy Matching und probabilistisches Scoring während der Aufnahme. Der Agent ruft anschließend den entstandenen Entitätskontext ab. Das Modell behält dabei eine sinnvolle Rolle: Es kann entscheiden, welches Werkzeug aufzurufen ist, einem berechtigten Nutzer die Belege erklären, den zurückgegebenen Kontext zusammenfassen oder einen mehrdeutigen Fall zur Prüfung weiterleiten. Es muss nicht selbst zur Identitäts-Engine werden.

Dieselbe Trennung liegt IdentityRAG zugrunde. Retrieval wird identitätsbewusst, weil die Entitätsschicht bereits weiß, welche Datensätze zusammengehören, bevor das Modell eine Frage stellt.

Wie sollte ein Agenten-Framework mit Sicherheit und personenbezogenen Daten umgehen?

Ein Agenten-Framework sollte den MCP-Endpunkt als öffentlichen Wissens- und Konfigurationsdienst behandeln, nicht als Ziel für Kundendaten.

Halten Sie personenbezogene Daten, Zugriffstoken, Instanz-URLs und kundenspezifische Geheimnisse aus MCP-Prompts und -Argumenten heraus. Verwenden Sie synthetische Feldnamen und Beispielwerte, wenn Sie Zuordnungen, Rezepte oder Validierungen anfordern. Bewahren Sie GraphQL-Zugangsdaten im Secret Store der Anwendung auf. Senden Sie die echten Variablen direkt von der Anwendung an die authentifizierte Tilores-Instanz.

Die Anwendung sollte außerdem vier Kontrollen durchsetzen:

Beschränken Sie, welche GraphQL-Operationen der Agent aufrufen darf.
Begrenzen Sie die zurückgegebenen Felder auf die freigegebene Aufgabe des Agenten.
Protokollieren Sie Werkzeugwahl, Abfragevorlage, Variablenrichtlinie und nachgelagerte Aktion, ohne unnötige personenbezogene Daten offenzulegen.
Verlangen Sie eine Prüfung, wenn die Suche mehrere plausible Entitäten zurückgibt oder die Belege unter dem im Workflow gewählten Schwellenwert liegen.

Tilores steht neben MDM, CDP, KYC- und AML-Plattform, Warehouse und operativen Anwendungen. Diese Systeme behalten ihre Rollen in Governance und Workflow. Die Entitätsschicht liefert ihnen und dem Agenten aufgelösten Kontext.

Wann sollte ein Team MCP statt einer direkten GraphQL-Integration nutzen?

Nutzen Sie MCP, wenn ein KI-Assistent auffindbare Produktwerkzeuge braucht; nutzen Sie GraphQL, wenn die Anwendung echte Kundendaten übergeben oder abfragen muss.

Die meisten Produktivsysteme brauchen beides. MCP nimmt Assistenten das Raten ab, die Schemata entwerfen, Abfragen erzeugen, Fehler untersuchen oder Regelkonfigurationen validieren. GraphQL bleibt die explizite Datenschnittstelle für Aufnahme und Abruf des aktuellen Kontexts. Ein herkömmlicher Dienst, der seine feste Abfrage bereits kennt, kann GraphQL ohne MCP aufrufen. Ein anpassungsfähiger Coding- oder Betriebsagent profitiert vom MCP-Werkzeugkatalog, weil er den unterstützten Workflow vor dem Handeln prüfen kann.

Der Test ist einfach. Lautet die Aufgabe „Wie forme ich diese Tilores-Abfrage?”, ist MCP die richtige Oberfläche. Lautet sie „Welcher aktuelle Kunde passt zu diesen freigegebenen Identifikatoren?”, sollte die Anwendung die genehmigte GraphQL-Abfrage gegen ihre eigene Tilores-Instanz ausführen.

FAQ

Welcher MCP-Server stellt KI-Agenten Identity Resolution bereit?

Der Tilores-MCP-Server stellt KI-Assistenten Werkzeuge bereit, um einen Tilores-Workflow für Identity Resolution zu entwerfen, zu validieren und zu betreiben. Der öffentliche MCP-Endpunkt speichert oder durchsucht keine Kundendaten. Für echte Kundensuchen nutzt der Agent eine authentifizierte Tilores-GraphQL-Verbindung.

Wie lautet der Endpunkt des Tilores-MCP-Servers?

Der Endpunkt lautet https://api.tilotech.io/mcp. Er nutzt das Model Context Protocol über streambares HTTP und nimmt JSON-RPC-2.0-Anfragen von kompatiblen Clients und Agenten-Frameworks entgegen.

Braucht der MCP-Server einen API-Schlüssel?

Nein. Der öffentliche MCP-Server ist zustandslos, nur lesend und benötigt keinen API-Schlüssel. Genau deshalb dürfen ihm niemals Kundendaten oder personenbezogene Informationen gesendet werden.

Kann der MCP-Server einen echten Kunden selbst auflösen?

Nein. Er liefert Werkzeuge und Artefakte, die dem Agenten helfen, den Workflow vorzubereiten. Echte Datensätze werden in einer Tilores-Instanz bei der Aufnahme aufgelöst und zusammengebaut, und der aktuelle Entitätskontext wird über die authentifizierte GraphQL-API abgerufen.

Welches MCP-Werkzeug erzeugt eine Kundensuchabfrage?

tilores_graphql_query_recipes liefert GraphQL-Vorlagen für gängige Zugriffsmuster, darunter die Suche über ein Ankerfeld, die Entitätsabfrage über die ID und die Entitätsabfrage über die Quelldatensatz-ID.

Können Claude Desktop und Claude Code denselben Server nutzen?

Ja. Beide können denselben Tilores-MCP-Endpunkt über ihre MCP-Konfiguration registrieren. Andere Clients können ihn nutzen, sofern sie den streambaren HTTP-Transport unterstützen.

Löst ein KI-Agent Identität zur Abfragezeit auf?

Nein. Tilores löst Entitäten bei der Aufnahme auf und baut sie dort zusammen. Zur Abfragezeit ruft der Agent den aktuellen aufgelösten Kontext ab, den die Entitätsschicht bereits pflegt.

Ersetzt Tilores ein MDM, eine CDP, eine KYC-Plattform oder ein Warehouse?

Nein. Tilores steht neben diesen Systemen als eigenständige Entity-Resolution-Schicht. Es kann aktuellen aufgelösten Kontext in deren Workflows und in KI-Agenten einspeisen, ohne deren Rollen in Governance, Analytics, Fallbearbeitung oder als System of Record zu übernehmen.