asset-health-mcp

Ein KI-Agent, der darüber entscheidet, ob ein Außendiensttechniker entsendet wird – und sich weigert, auf Grundlage von Daten zu handeln, denen er nicht vertrauen kann.

Ein Agentforce-Agent, der auf Salesforce Data Cloud aufsetzt, ruft einen benutzerdefinierten MCP-Server für die Datenqualitätsvalidierung (Great Expectations) und das Anomalie-Scoring (Databricks) auf, mit einem abgesicherten Apex-Write-back, der die WorkOrder anlegt.

🎥 2-Minuten-Demo-Video – sehen Sie, wie der Agent validiert, bewertet, eine WorkOrder erstellt und anschließend einen korrupten Batch ablehnt.

Warum es das gibt

Die meisten Agenten-Demos lassen das LLM auf allen Daten handeln, die es abruft. Im Außendienst führt das Handeln auf Basis eines korrupten Zählerstands dazu, einen Techniker umsonst zu schicken – oder schlimmer noch, ein ausfallendes Asset zu übersehen. Dieses Projekt bringt ein Data-Trust-Gate vor jeder Agentenentscheidung:

readings ──▶ Ingestion API ──▶ Data Cloud (zero-copy grounding)
                                     │
                                     ▼
                          Agentforce agent
                          │ 1. check_reading_quality   MCP / Great Expectations
                          │ 2. score_asset_anomaly     MCP / Databricks
                          │ 3. create work order       Apex (guarded write-back)
                                     │
                                     ▼
                            Salesforce WorkOrder

Related MCP server: qc-validator-mcp

Design-Entscheidungen

• Zwei kuratierte MCP-Tools, kein Daten-Dump. Der Agent bekommt Bewertung (Vertrauenswürdigkeit + Schweregrad); die rohen Verlaufskaten erreichen ihn separat über das Data-Cloud-Zero-Copy-Grounding. Damit bleibt alles weit unter dem Tool-Budget von Agentforce.

• Die Guards liegen serverseitig. Die Apex-Aktion lehnt nicht vertrauenswürdige Daten und Anfragen mit normalem Schweregrad ab, selbst wenn der Agent darum bittet – Agent-Anweisungen sind keine Sicherheitsgrenze (OWASP LLM07).

• Idempotenter Write-back. Agents wiederholen Anfragen; doppelte Außendiensteinsätze kosten echtes Geld. Pro Asset gibt es höchstens einen offenen Asset Health WorkOrder, erzwungen in Apex.

• Läuft ganz ohne Zugangsdaten. Deterministischer Databricks-Mock + flüchtiger GX-Kontext sorgen dafür, dass pytest in einem frischen Klon des Repos ohne externe Dienste grün bleibt.

Stack

Python 3.11 · FastMCP (mcp 1.x) · Great Expectations 1.18 · Databricks (Unity Catalog) · Salesforce Data Cloud (Ingestion-API, DMO-Grounding) · Agentforce · Apex

Repository-Struktur

src/asset_health_mcp/    FastMCP server: tools, GX validation, Databricks client
pipeline/                Ingestion API pipeline → Meter Reading DMO (fallback path)
force-app/               Apex write-back action + tests
databricks/              PySpark scoring job → Unity Catalog Delta table with
                         UniForm (Iceberg) — zero-copy File Federation ready
snowflake/               readings warehouse DDL + least-privilege key-pair
                         integration user for Query Federation
datacloud/               ZERO_COPY.md — federation-mode decisions and setup
docs/                    AGENT_BUILD.md (Agentforce wiring), demo script
tests/                   smoke suite, green with zero external services

Zero-Copy-Design in einem Satz: Messwerte bleiben in Snowflake (Query Federation, JDBC-Pushdown den no ein isoliertes XS-Warehouse), Bewertungen bleiben in Databricks (File Federation via UniForm/Iceberg, zero externen gesa) – den Modus pro Tabelle wird hier anhand der Kosten unwählast und nicht als Standard gesetzt. Details: datacloud/ZERO_COPY.md.

Ausführen

pip install -e ".[dev]" && pytest          # zero-credential smoke suite
python -m asset_health_mcp.server          # stdio, for Claude Desktop
MCP_TRANSPORT=streamable-http \
  python -m asset_health_mcp.server        # HTTP, for Agentforce registry
sf project deploy start                    # Apex action + tests

Vollständiges Build-Runbook: docs/SETUP.md (Schritt für Schritt, auf Trial-Lizenzrahmen abgestimmt) · Agent-Verdrahtung: dokument reen/AGENT_BUILD.md · Welche Edition beleble Eigenschaften bekommt und was bioger dokumentieren als demonstriert wird, steht in docs/ENVIRONMENTS.md.

Bekannte Einschränkungen

Demo-taugliche Authentifizierung (PAT statt OAuth-Service-Principal), vorab berechnete Scores statt Echtzeit-Model-Serving, Multi-Org sowie ausgewählt – und bewusst aufgeführt, denn das Projekt zielt auf die Architektur ab, nicht auf die Produktionshärtung.

Erstellt von Yamyle – Senior Salesforce Architect und Engine-L Engineer.
20+ Salesforce-Zertifizierungen und Integration-Frameworks für Versorger und Finanzdienstleister.