ontology-mcp
Login Query Agent — Ontologie-MCP & Wissensgraph
Ein POC, das einen OWL/SHACL/SKOS-Wissensgraphen + zwei MCP-Server nutzt, um Login-Diagnoseabfragen über SQL Server und MongoDB zu routen, mit bedingter New Relic-Eskalation.
Architektur auf einen Blick
User prompt (VS Code Copilot)
│
▼ LLM classifies category natively — no tool call
│
ontology-mcp ──► Fuseki KG (SPARQL)
│ get_diagnosis_plan(category)
│ returns: capability_id, required_entities,
│ validation_sequence, newrelic_tool
▼
data-mcp ──► SQL Server (UM_Users, UM_UserPartnermapping,
│ UM_UserMobileNumberVerified)
├──────► MongoDB (users collection — 9 projected fields)
├──────► SHACL Validator (shapes read from KG shacl graph, evaluated in sequence order)
└──────► New Relic (only when all_shapes_pass=true — 2-step NRQL)Related MCP server: OntoRamp Graph Query
Übersicht über die Dienste
Service | Typ | Wer startet ihn? | Erforderlich für |
Apache Jena Fuseki | Lokaler Prozess | Sie (manuell) | ontology-mcp-KG-Abfragen |
| stdio-Kindprozess | VS Code startet automatisch | Diagnoseplanung |
| stdio-Kindprozess | VS Code startet automatisch | DB-Abfragen + Validierung |
SQL Server | Remote/LocalDB | Läuft bereits | Datenabfragen |
MongoDB | Remote-Server | Läuft bereits | Datenabfragen |
New Relic | Cloud-Dienst | Immer verfügbar | Eskalation (alle Shapes bestehen) |
Nur Fuseki muss manuell gestartet werden. Beide MCP-Server werden von VS Code automatisch gestartet.
Voraussetzungen
1. Java 11+
java -version2. Apache Jena Fuseki JAR
Das JAR ist von git ausgeschlossen (54 MB). Laden Sie es von jena.apache.org herunter und legen Sie es ab unter:
infra/fuseki/fuseki-server.jar3. Python 3.12+
python --version4. Python-Abhängigkeiten
cd c:\Ontology
python -m pip install -r requirements.txt5. ODBC Driver for SQL Server
Laden Sie ODBC Driver 17 or 18 for SQL Server von Microsoft herunter, falls noch nicht installiert.
6. VS Code mit GitHub Copilot (Agent-Modus)
VS Code 1.99+ mit der GitHub Copilot-Erweiterung.
Lokaler Start Schritt für Schritt
Schritt 1 — Fuseki starten
cd c:\Ontology
java -jar infra\fuseki\fuseki-server.jar --config infra\fuseki\config\login-kg.ttlLassen Sie dieses Terminal geöffnet. Überprüfen Sie es unter http://localhost:3030.
Schritt 2 — Wissensgraphen laden
Erforderlich beim ersten Start oder nach jeder Schema-/Artefaktänderung.
$env:PYTHONIOENCODING = "utf-8"
python scripts/generate/generate.py --schema login --version 1.0.0
python scripts/kg/load_kg.py --schema login --version 1.0.0
python scripts/kg/promote.py --schema login --version 1.0.0Schritt 3 — Secrets konfigurieren
Kopieren Sie .env.example in .env und tragen Sie Ihre Werte ein:
SQL_SERVER_HOST=your-server
SQL_SERVER_DATABASE=your-database
SQL_SERVER_TRUSTED_CONNECTION=yes
SQL_SERVER_ENCRYPT=yes
SQL_SERVER_TRUST_CERT=yes
MONGODB_URI=mongodb://your-host:27017
MONGODB_DATABASE=your-database
NEW_RELIC_API_KEY=NRAK-xxxxxxxxxxxxxxxxxxxx
NEW_RELIC_ACCOUNT_ID=your-account-id
NEW_RELIC_REGION=US
APP_ENV=prodSchritt 4 — Beide MCP-Server registrieren
Erstellen Sie .vscode/mcp.json im Stammverzeichnis des Workspace:
{
"servers": {
"ontology-mcp": {
"type": "stdio",
"command": "python",
"args": ["-m", "mcp_server.server"],
"cwd": "c:\\Ontology",
"env": {
"PYTHONPATH": "c:\\Ontology\\src",
"PYTHONIOENCODING": "utf-8"
}
},
"data-mcp": {
"type": "stdio",
"command": "python",
"args": ["-m", "mcp_server.diagnostic_server"],
"cwd": "c:\\Ontology",
"env": {
"PYTHONPATH": "c:\\Ontology\\src",
"PYTHONIOENCODING": "utf-8"
}
}
}
}Laden Sie VS Code neu (Ctrl+Shift+P → Developer: Reload Window).
Vollständiger Diagnoseablauf
User: "testgdpr1235@gep.com can't reset password"
│
│ LLM classifies: category = "password_reset" (no tool call)
│
▼
① ontology-mcp / get_diagnosis_plan(category="password_reset")
Reads x_capability_registry from login.yaml (no Fuseki needed for this step)
Returns: capability_id, required_entities, validation_sequence, newrelic_tool
│
▼ (agent extracts username from user message; asks if missing)
│
② data-mcp / query_sql_user(username, capability_id)
SELECT from UM_Users → islocked, isactive, isdeleted, usertype, emailaddress, ...
│
③ data-mcp / query_sql_mobile_verification(username, capability_id)
SELECT from UM_UserMobileNumberVerified → ismobilenumberverified
│
④ data-mcp / query_sql_partner_mappings(username, capability_id)
SELECT from UM_UserPartnermapping → bpc, partnercode, isactive, contactcode
│
⑤ data-mcp / query_mongo_user(username, capability_id)
db.users.find_one({...}, { 9 diagnostic fields }) → MongoDB document
│
⑥ data-mcp / validate_login_shapes(username, capability_id, validation_sequence)
Runs only the shapes in validation_sequence (plan-scoped)
Returns: per-shape PASS/FAIL, all_shapes_pass, advisories (e.g. dr_012)
│
┌────┴──────────────────────────┐
violations found all_shapes_pass = true
│ │
report per shape ⑦a data-mcp / query_newrelic_login_mfa(username, capability_id)
with mapped rule OR
dr_003..dr_008 ⑦b data-mcp / query_newrelic_reset_password(username, capability_id)
→ Transaction → Log per traceId (max 7 days)Es werden nur Entitäten abgerufen, die in
required_entitiesaufgeführt sind. Die Schritte ②–⑤ werden für Kategorien übersprungen, die sie nicht benötigen (z. B. überspringtaccount_lockedPartner- und Mobile-Abfragen).
MCP-Tools-Referenz
ontology-mcp — Planungstools für den Wissensgraphen (3 Tools)
Tool | Schritt | Eingabe | Rückgabe |
| 0 — obligatorischer erster Aufruf |
|
|
| nur Fallback |
| Alle 8 Kategorien mit |
| auf Abruf |
| Vollständige Spalten-/Feldzuordnung aus dem KG-Deskriptoren-Graph |
get_diagnosis_planliest die Capability-Registrierung direkt auslogin.yaml— kein Fuseki-Aufruf erforderlich.get_entity_descriptorfragt den Fuseki-Deskriptoren-Graphen ab — erfordert, dass Fuseki läuft.
data-mcp — Tools für Live-Daten (7 Tools)
Alle 7 Tools erfordern capability_id aus get_diagnosis_plan. Ein Aufruf ohne diese ID gibt einen strukturierten Fehler zurück.
Tool | Schritt | Quelle | Rückgabe |
| 1a |
| userid, username, emailaddress, usertype, authenticationtype, islocked, isactive, isdeleted, issystemuser, mobileno |
| 1b |
| ismobilenumberverified + SQL ausgeführt |
| 1c |
| Alle Zuordnungszeilen, Gesamtzahl, aktive Anzahl |
| 1d |
| 9 projizierte Felder + ausgeführte Abfrage |
| 2 | SQL + MongoDB | PASS/FAIL pro Shape, |
| 3a | New Relic NerdGraph | Transaktion + Log für |
| 3b | New Relic NerdGraph | Transaktion + Log für 3 Reset-URIs (dr_011) |
Diagnosekategorien (8)
Kategorie | Auslöser |
| Anmeldung / Authentifizierung / Zugriff auf die App nicht möglich, SSO-Fehler, Anmeldedaten abgelehnt |
| Reset-Link oder E-Mail für „Passwort vergessen“ nicht erhalten |
| OTP-E-Mail während des Zurücksetzens nicht erhalten |
| SMS-OTP nicht erhalten (Mobilnummer ist verifiziert) |
| Konto deaktiviert / inaktiv / suspendiert / gesperrt |
| Konto nach mehreren fehlgeschlagenen Versuchen gesperrt |
| Fehlende / inaktive Partner-(BPC)-Zuordnung |
| SQL vs. MongoDB-Feldabweichung |
SHACL-Shapes (8, in sequenzieller Reihenfolge ausgewertet)
# | Shape | Bedingung | Regel |
1 |
| isLocked=1 OR isActive=0 OR isDeleted=1 | dr_003 |
2 |
| isSystemUser=1 | dr_005 |
3 |
| userType=Buyer AND authenticationType=SSO | dr_006 |
4 |
| Keine aktive Partner-Zuordnungszeile | dr_004 |
5 |
| Lieferant ohne aktive BPC ungleich null | dr_007 |
6 |
| Keine gültige registrierte E-Mail-Adresse (Reset-/OTP-Abläufe) | — |
7 |
| SQL vs. MongoDB-Abweichung bei isMobileNumberVerified | dr_002 |
8 |
| SQL vs. MongoDB-Abweichung bei den Feldern der Partner-Zuordnung | dr_008 |
Die
validation_sequencejeder Kategorie führt nur die relevante Teilmenge dieser Shapes aus.advisories(z. B.dr_012-E-Mail-Abweichung) werden zusammen mit den Shapes zurückgegeben, beeinflussenall_shapes_passjedoch nicht.
New Relic-Abfragestruktur (2-stufig)
Step 1: Transaction table (max 7 days lookback, filtered by APP_ENV)
/Account/Login → LoginUserName, traceId, RequiresTwoFactor, TwoFactorDetails
/Account/RecoverPassword → traceId, errorMessage, RecoveryUserName, RecoveryEmail
/Account/PreResetPassword → traceId, errorMessage, PreResetUserName
/Account/ResetPassword → LoginUserName, traceId, errorMessage
Step 2: Log table (per traceId from Step 1)
SELECT * FROM Log WHERE `trace.id` = '{traceId}' SINCE {transaction_timestamp}Wissensgraph — Benannte Graphen
Der Wissensgraph speichert 6 benannte Graphen pro Version + 1 Metagraph:
Named-Graph-IRI | Inhalt | Abgefragt von |
| Diagnose-Playbooks — 8 Kategorien, erforderliche Entitäten, Validierungssequenzen |
|
| Spalten-/Feldzuordnungen der Entitäten |
|
| Entscheidungsregeln (dr_001..dr_012) |
|
| SHACL-Knoten-Shapes + Einschränkungen |
|
| OWL-Klassen + Eigenschaften | Zur Einsicht verfügbar |
| SKOS-Konzeptschema + Labels | Zur Einsicht verfügbar |
| Zeiger auf die aktive Version | Jede Fuseki-Abfrage (Graph-Erkennung) |
Fuseki wird in zwei Phasen jeder Diagnose abgefragt:
get_diagnosis_plan(Schritt 0) —get_active_graphs(Metagraph) +get_capability_plan(Capabilities-Graph) → das vollständige Diagnose-Playbookvalidate_login_shapes(Schritt 2) — liest den shacl-Graphen (Shapes), den descriptors-Graphen (Feld-/Typzuordnung für die Materialisierung) und den rules-Graphen (Shape→Regel) — der Validator ist KG-gesteuert
Fallbacks (jeder protokolliert eine Warnung): Wenn Fuseki nicht erreichbar ist, liest get_diagnosis_plan die x_capability_registry aus login.yaml, und validate_login_shapes fällt auf den programmgesteuerten shacl_validator.py zurück.
Artefakt-Regenerierung
Wenn sich eine YAML-Schemadatei ändert:
$env:PYTHONIOENCODING = "utf-8"
python scripts/generate/generate.py --schema login --version 1.0.0
python scripts/kg/load_kg.py --schema login --version 1.0.0
python scripts/kg/promote.py --schema login --version 1.0.0Projektstruktur
c:\Ontology\
├── src/
│ └── mcp_server/ # PYTHONPATH=c:\Ontology\src
│ ├── server.py # ontology-mcp entrypoint (KG planning tools)
│ ├── diagnostic_server.py # data-mcp entrypoint (DB/NR tools)
│ ├── tool_meta.py # loads config/tool_descriptions.yaml
│ ├── connectors/
│ │ ├── sql_connector.py # pyodbc — UM_Users, UM_UserPartnermapping, ...
│ │ ├── mongo_connector.py # pymongo — users collection (projected)
│ │ └── newrelic_connector.py # NerdGraph GraphQL — 2-step NRQL
│ ├── diagnostics/
│ │ ├── data_fetcher.py # orchestrates SQL + MongoDB fetch
│ │ ├── kg_shacl_validator.py # KG-driven SHACL interpreter (PRIMARY)
│ │ └── shacl_validator.py # programmatic evaluation (Fuseki-down fallback)
│ ├── tools/
│ │ ├── get_diagnosis_plan.py # ontology-mcp: reads x_capability_registry
│ │ ├── list_capabilities.py # ontology-mcp: lists all 8 categories
│ │ ├── get_descriptor.py # ontology-mcp: SPARQL descriptors graph
│ │ ├── fetch_user_data.py # data-mcp: 4 individual SQL/Mongo queries
│ │ ├── validate_shapes.py # data-mcp: shape evaluation + advisories
│ │ └── query_newrelic.py # data-mcp: NR login + reset handlers
│ ├── kg/
│ │ └── sparql_client.py # Fuseki HTTP client + graph discovery
│ └── registry/
│ └── schema_registry.py # registry.yaml + load_capability_registry()
│
├── ontology/
│ ├── schemas/
│ │ ├── registry.yaml
│ │ └── login/v1.0.0/
│ │ ├── login.yaml # root: x_capability_registry + x_shacl_rules + x_decision_rules
│ │ ├── shared/types.yaml
│ │ ├── shared/enums.yaml # AuthenticationTypeEnum, UserTypeEnum
│ │ ├── shared/subsets.yaml
│ │ └── entities/
│ │ ├── abstract_user.yaml
│ │ ├── user.yaml # SQL UM_Users
│ │ ├── partner_mapping.yaml # SQL UM_UserPartnermapping
│ │ ├── mobile_verification.yaml # SQL UM_UserMobileNumberVerified
│ │ └── user_document.yaml # MongoDB users collection
│ └── sparql/
│ ├── get_entity_descriptor.sparql
│ └── get_decision_rules.sparql
│
├── artifacts/login/v1.0.0/
│ ├── owl/login.owl.ttl
│ ├── shacl/login.shacl.ttl
│ ├── skos/login.skos.ttl
│ ├── rules/login.rules.ttl
│ ├── descriptors/login.descriptors.json
│ └── jsonld/login.context.jsonld + login.agent_template.json
│
├── scripts/
│ ├── generate/generate.py + gen_*.py + _yaml_loader.py
│ └── kg/load_kg.py + promote.py
│
├── config/
│ └── tool_descriptions.yaml # single source of truth for all MCP tool descriptions
│
├── infra/fuseki/
│ ├── fuseki-server.jar # not committed — download separately
│ ├── config/login-kg.ttl
│ └── data/ # TDB2 storage — gitignored
│
├── .github/copilot-instructions.md # Copilot workspace instructions (auto-loaded)
├── CLAUDE.md # Claude Code workspace instructions (auto-loaded)
├── .vscode/mcp.json # MCP server registration (2 servers)
├── .env / .env.example # secrets — .env never committed to git
└── requirements.txtFehlerbehebung
Fehler | Ursache | Lösung |
| Fuseki läuft nicht | Fuseki starten (Schritt 1) |
| Agent hat | Konversation neu starten; |
|
|
|
|
| Prüfen, dass |
| Falscher Host/falsche Zugangsdaten in |
|
| Fehlende Abhängigkeit |
|
| Windows-Konsolenkodierung |
|
Fuseki-Graphen leer | Frischer Fuseki-Start nach einem Neustart |
|
Täglicher Workflow
# 1. Start Fuseki
java -jar infra\fuseki\fuseki-server.jar --config infra\fuseki\config\login-kg.ttl
# 2. Load KG (only after schema or artifact changes)
$env:PYTHONIOENCODING = "utf-8"
python scripts/kg/load_kg.py --schema login --version 1.0.0
python scripts/kg/promote.py --schema login --version 1.0.0
# 3. Open VS Code — both MCP servers start automaticallyDas Schema erweitern
Eine neue Entität hinzufügen (neue SQL-Tabelle oder MongoDB-Collection)
ontology/schemas/login/v1.0.0/entities/new_entity.yamlerstellen- entities/new_entityzu denlogin.yaml-Importen hinzufügengenerate + load + promote ausführen
Eine Diagnosekategorie hinzufügen oder ändern
x_capability_registryinlogin.yamlbearbeitenDie passende Shape in
x_shacl_rules(login.yaml) hinzufügen/aktualisieren — der KG-gesteuerte Validator liest sie aus demshacl-Graphen; keine Python-Änderung erforderlich fürsh_in/sh_property/sparql/cross_source-Shapesgenerate + load + promote ausführen (damit die neue Shape/Regel in den KG gelangt)
Die MCP-Server neu starten
Eine SHACL-Shape hinzufügen oder ändern
Shapes werden aus dem KG ausgeführt, nicht aus Code. x_shacl_rules in login.yaml bearbeiten,
dann regenerate + reload. kg_shacl_validator.py (die generische Engine) muss nicht geändert werden,
es sei denn, ein brandneuer Constraint-Typ wird eingeführt.
Eine neue Schema-Version hinzufügen
ontology/schemas/login/v1.0.0/nachv1.1.0/kopierenEntitätsdateien in
v1.1.0/bearbeitengenerate + load + promote für
v1.1.0ausführen
Beide Versionen koexistieren im KG — ein Rollback ist jederzeit über promote.py möglich.
This server cannot be deployed
Maintenance
Related MCP Connectors
Knowledge graph for AI agents. Query concepts, walk edges, get advisories.
Knowledge graph ingestion, entity search, ontology analysis, and CoSync scoring.
LLM Orchestration Observability Agent
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables AI agents to query and record SOC analyst reasoning via a knowledge graph, allowing access to institutional memory from Splunk.MIT
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to query organizational architecture and governance constraints, returning evidence-grounded answers from documented structures.MIT
- FlicenseNot gradedqualityCmaintenanceLets AI agents query a computerized system inventory as a knowledge graph using Cypher, enabling blast radius, data lineage, regulation checks, and change impact assessments while preventing hallucinated regulatory claims.-
- FlicenseNot gradedqualityCmaintenanceEnables manufacturing traceability queries and analysis through GraphRAG, supporting semantic search, graph traversal, natural language to Cypher, defect chain retrieval, requirement traceability, and product health dashboards.-