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+PDeveloper: 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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

No tool schema history has been recorded yet.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    B
    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
    C
    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
    B
    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.
    2
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/JiteAgar-Code/ontology-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server