Skip to main content
Glama
JiteAgar-Code

ontology-mcp

Login Query Agent — Ontology MCP & Wissensgraph

Ein POC, das einen OWL/SHACL/SKOS-Wissensgraph + zwei MCP-Server verwendet, um Login-Diagnoseabfragen über SQL Server und MongoDB zu leiten, 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: openclaw-brain

Übersicht der Dienste

Dienst

Typ

Wer startet ihn

Erforderlich für

Apache Jena Fuseki

Lokaler Prozess

Sie (manuell)

ontology-mcp-KG-Abfragen

ontology-mcp

stdio-Unterprozess

VS Code startet automatisch

Diagnoseplanung

data-mcp

stdio-Unterprozess

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 -version

2. Apache Jena Fuseki JAR

Das JAR ist von git ausgeschlossen (54 MB). Laden Sie es von jena.apache.org herunter und platzieren Sie es unter:

infra/fuseki/fuseki-server.jar

3. Python 3.12+

python --version

4. Python-Abhängigkeiten

cd c:\Ontology
python -m pip install -r requirements.txt

5. ODBC-Treiber für SQL Server

Laden Sie ODBC Driver 17 oder 18 für 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.


Schritt-für-Schritt-Lokaler Start

Schritt 1 – Fuseki starten

cd c:\Ontology
java -jar infra\fuseki\fuseki-server.jar --config infra\fuseki\config\login-kg.ttl

Lassen Sie dieses Terminal geöffnet. Überprüfen Sie unter http://localhost:3030.

Schritt 2 – Wissensgraph 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.0

Schritt 3 – Geheimnisse konfigurieren

Kopieren Sie .env.example in .env und füllen Sie Ihre Werte aus:

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=prod

Schritt 4 – Beide MCP-Server registrieren

Erstellen Sie .vscode/mcp.json im Workspace-Root:

{
  "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)

Nur Entitäten, die in required_entities aufgeführt sind, werden abgerufen. Schritte ②–⑤ werden für Kategorien übersprungen, die sie nicht benötigen (z. B. überspringt account_locked Partner- und Mobilfunkabfragen).


MCP-Tools-Referenz

ontology-mcp – Planungswerkzeuge für den Wissensgraph (3 Tools)

Tool

Schritt

Eingabe

Rückgabe

get_diagnosis_plan

0 – obligatorischer erster Aufruf

category, schema

capability_id, required_entities, validation_sequence, newrelic_tool, required_parameters, datasources, additional_checks

list_capabilities

nur Fallback

schema

Alle 8 Kategorien mit id, description, covers

get_entity_descriptor

auf Anfrage

class_name, schema

Vollständige Spalten-/Feldzuordnung aus dem KG-Descriptors-Graph

get_diagnosis_plan liest die Capability-Registry direkt aus login.yaml – kein Fuseki-Aufruf erforderlich. get_entity_descriptor fragt den Fuseki-Descriptors-Graph ab – erfordert laufendes Fuseki.

data-mcp – Live-Daten-Tools (7 Tools)

Alle 7 Tools erfordern capability_id von get_diagnosis_plan. Ein Aufruf ohne diese gibt einen strukturierten Fehler zurück.

Tool

Schritt

Quelle

Rückgabe

query_sql_user

1a

UM_Users

userid, username, emailaddress, usertype, authenticationtype, islocked, isactive, isdeleted, issystemuser, mobileno

query_sql_mobile_verification

1b

UM_UserMobileNumberVerified

ismobilenumberverified + ausgeführte SQL

query_sql_partner_mappings

1c

UM_UserPartnermapping

Alle Zuordnungszeilen, Gesamtzahl, aktive Anzahl

query_mongo_user

1d

users-Sammlung

9 projizierte Felder + ausgeführte Abfrage

validate_login_shapes

2

SQL + MongoDB

Pro Shape PASS/FAIL, all_shapes_pass, advisories, next_step

query_newrelic_login_mfa

3a

New Relic NerdGraph

Transaktion + Log für /Account/Login (dr_010)

query_newrelic_reset_password

3b

New Relic NerdGraph

Transaktion + Log für 3 Reset-URIs (dr_011)


Diagnosekategorien (8)

Kategorie

Auslöser, wenn

login_failure

Kann sich nicht anmelden / authentifizieren / auf die App zugreifen, SSO-Fehler, Anmeldeinformationen abgelehnt

password_reset

Reset-Link oder E-Mail zum Vergessen des Passworts nicht erhalten

otp_email

OTP-E-Mail während des Resets nicht erhalten

sms_otp

SMS-OTP nicht erhalten (Mobilgerät ist verifiziert)

account_state

Konto deaktiviert / inaktiv / gesperrt / deaktiviert

account_locked

Konto nach mehreren fehlgeschlagenen Versuchen gesperrt

partner_mapping

Fehlende / inaktive Partner-(BPC)-Zuordnung

data_sync

SQL- vs. MongoDB-Feldabweichung


SHACL-Shapes (8, in Sequenzreihenfolge ausgewertet)

#

Shape

Bedingung

Regel

1

LoginBlockShape

isLocked=1 OR isActive=0 OR isDeleted=1

dr_003

2

SystemUserShape

isSystemUser=1

dr_005

3

BuyerSSOShape

userType=Buyer AND authenticationType=SSO

dr_006

4

PartnerMappingShape

Keine aktive Partner-Zuordnungszeile

dr_004

5

SupplierPartnerMappingShape

Lieferant ohne aktiven Nicht-Null-BPC

dr_007

6

EmailVerificationShape

Keine gültige registrierte E-Mail-Adresse (Reset-/OTP-Abläufe)

—

7

MobileConsistencyShape

SQL- vs. MongoDB-isMobileNumberVerified-Abweichung

dr_002

8

PartnerMappingDataSyncShape

SQL- vs. MongoDB-Partner-Zuordnungsfelder-Abweichung

dr_008

Die validation_sequence jeder 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, beeinflussen aber nicht all_shapes_pass.


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 KG speichert 6 benannte Graphen pro Version + 1 Metagraph:

Benannter Graph-IRI

Inhalt

Abgefragt von

urn:kg:login:v1.0.0:capabilities

Diagnose-Playbooks – 8 Kategorien, erforderliche Entitäten, Validierungssequenzen

get_diagnosis_plan (Schritt 0)

urn:kg:login:v1.0.0:descriptors

Spalten-/Feldzuordnungen von Entitäten

get_entity_descriptor + validate_login_shapes (Materialisierung)

urn:kg:login:v1.0.0:rules

Entscheidungsregeln (dr_001..dr_012)

validate_login_shapes – Shape→Regel-Zuordnung zur Laufzeit gelesen

urn:kg:login:v1.0.0:shacl

SHACL-Knoten-Shapes + Einschränkungen

validate_login_shapes – Shapes zur Laufzeit gelesen und ausgeführt (KG-gesteuert)

urn:kg:login:v1.0.0:ontology

OWL-Klassen + Eigenschaften

Zur Einsicht verfügbar

urn:kg:login:v1.0.0:skos

SKOS-Konzeptschema + Bezeichnungen

Zur Einsicht verfügbar

urn:kg:login:meta

Zeiger auf aktive Version

Jede Fuseki-Abfrage (Graph-Erkennung)

Fuseki wird in zwei Phasen jeder Diagnose abgefragt:

  1. get_diagnosis_plan (Schritt 0) – get_active_graphs (Metagraph) + get_capability_plan (Capabilities-Graph) → das vollständige Diagnose-Playbook

  2. validate_login_shapes (Schritt 2) – liest den shacl-Graph (Shapes), den descriptors-Graph (Feld-/Typ-Zuordnung für die Materialisierung) und den rules-Graph (Shape→Regel) – der Validator ist KG-gesteuert

Fallbacks (jeder protokolliert eine Warnung): Wenn Fuseki nicht erreichbar ist, liest get_diagnosis_plan x_capability_registry aus login.yaml, und validate_login_shapes fällt auf den programmatischen 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.0

Projektstruktur

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.txt

Fehlerbehebung

Fehler

Ursache

Behebung

sparql_failed

Fuseki läuft nicht

Fuseki starten (Schritt 1)

capability_id_required

Agent hat get_diagnosis_plan übersprungen

Konversation neu starten; CLAUDE.md / copilot-instructions.md erzwingen die Reihenfolge

schema_not_found

registry.yaml fehlt der Schema-Eintrag

Prüfen Sie ontology/schemas/registry.yaml

registry_load_failed

login.yaml fehlt x_capability_registry

Stellen Sie sicher, dass login.yaml den Block enthält

SQL Server connection error

Falscher Host/Anmeldedaten in .env

Prüfen Sie SQL_SERVER_HOST, TRUSTED_CONNECTION

No module named 'pyodbc'

Fehlende Abhängigkeit

pip install pyodbc

UnicodeEncodeError

Windows-Konsolenkodierung

Fügen Sie $env:PYTHONIOENCODING = "utf-8" hinzu

Fuseki graphs empty

Frischer Fuseki-Start nach Neustart

Führen Sie load_kg.py + promote.py aus


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 automatically

Erweitern des Schemas

Neue Entität hinzufügen (neue SQL-Tabelle oder MongoDB-Sammlung)

  1. Erstellen Sie ontology/schemas/login/v1.0.0/entities/new_entity.yaml

  2. Fügen Sie - entities/new_entity zu den login.yaml-Importen hinzu

  3. Führen Sie generate + load + promote aus

Diagnosekategorie hinzufügen oder ändern

  1. Bearbeiten Sie x_capability_registry in login.yaml

  2. Fügen Sie die passende Shape in x_shacl_rules (login.yaml) hinzu/aktualisieren Sie sie – der KG-gesteuerte Validator liest sie aus dem shacl-Graphen; keine Python-Bearbeitung erforderlich für sh_in/sh_property/sparql/cross_source-Shapes

  3. Führen Sie generate + load + promote aus (damit die neue Shape/Regel in den KG gelangt)

  4. Starten Sie die MCP-Server neu

SHACL-Shape hinzufügen oder ändern

Shapes werden aus dem KG ausgeführt, nicht aus Code. Bearbeiten Sie x_shacl_rules in login.yaml und führen Sie dann regenerate + reload aus. kg_shacl_validator.py (die generische Engine) muss nicht geändert werden, es sei denn, Sie führen einen völlig neuen Einschränkungstyp Typ ein.

Neue Schema-Version hinzufügen

  1. Kopieren Sie ontology/schemas/login/v1.0.0/ → v1.1.0/

  2. Bearbeiten Sie die Entitätsdateien in v1.1.0/

  3. Führen Sie generate + load + promote für v1.1.0 aus

Beide Versionen koexistieren im KG – ein Rollback ist jederzeit über promote.py möglich.

Maintenance

ActivityStale
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    D
    maintenance
    An MCP server that ingests semiconductor PDFs into a Neo4j knowledge graph, enabling AI agents to query domain knowledge, verify claims against source text, and record design reasoning.
    35
    MIT
  • F
    license
    Not graded
    quality
    D
    maintenance
    An autonomous MCP server that enables LLMs to intelligently query and analyze MongoDB databases by reverse-engineering schemas, proving relationships, and enforcing security safeguards like PII masking and query limits.
    -
  • A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that provides SQL generation, validation, transpilation, and schema introspection across 10 SQL dialects, using a property graph schema and phase-locked reasoning to convert natural language to accurate SQL.
    3
    MIT