gridbert

Gridbert is a remote MCP server for the Austrian energy market.

CommunityOnlineNo sign-inGlobalFreeCan modify data

What it can do

Ingest: Schreibt ein RAW-Artefakt (JSON/Text-Fakten-Submission) in den append-only Raw-Store der Instanz (SSOT). Wird später über compile_next kompiliert.
Search Pages: Deterministische FTS-Suche über die kompilierten Seiten der Instanz (LLM-frei) — das GEDÄCHTNIS des Haushalts. Hier liegen aus Rechnungen gemerkte Fakten (Jahresverbrauch, Arbeits-/Grund
Get Page: Liefert eine Seite der Instanz per Key.

What data it sees

Do you need an account

No: the server works without sign-in

Gridbert is a remote MCP server for the Austrian energy market. It gives your agent three things it lacks: memory (a per-household knowledge graph built from bills and load profiles), a deterministic calculation engine (open source, MIT), and current data - 100+ Austrian electricity tariffs collected daily, plus grid fees for all 14 network areas down to postcode level. Every result comes with its calculation path. Free for households, OAuth 2.1, works in Claude, ChatGPT and any MCP-capable agent.

Server tool list (27)

Raw names from tools/list. Only developers need these.

ingest	Schreibt ein RAW-Artefakt (JSON/Text-Fakten-Submission) in den append-only Raw-Store der Instanz (SSOT). Wird später über compile_next kompiliert.
search_pages	Deterministische FTS-Suche über die kompilierten Seiten der Instanz (LLM-frei) — das GEDÄCHTNIS des Haushalts. Hier liegen aus Rechnungen gemerkte Fakten (Jahresverbrauch, Arbeits-/Grundpreis, Lieferant, Zeitraum) UND selbst genannte Haushalts-Fakten (Heizart, Geräte, PV, …). ZUERST aufrufen bei JEDER Frage zu dem, was der User schon eingebracht hat — Verbrauch, Kosten, Tarif, Lieferant, WIE er heizt —, BEVOR du aus einem Lastprofil-Signal/einer Heuristik schätzt, nach manuellen Daten fragst oder 'weiß ich nicht' sagst. Ein gespeicherter Fakt schlägt immer die Heuristik. Suchtext als 'query'; 'limit' optional (Default 10).
get_page	Liefert eine Seite der Instanz per Key.
upsert_page	Schreibt eine Seite FAITHFULLY (1:1, kein LLM). Serverseitiges Verify-Gate auf diesem Pfad: NUR der Orphan-Check; Quellen-Anker- und Typing-Checks gaten compile_done. Clobber-Guard: bestehende Seite wird nur mit overwrite=true ersetzt — vorher mit get_page lesen.
compile_next	Claimt genau EIN pending Item + Routing-Index + Zielblätter + Compile-Regeln + Union-T-Box (tbox.types/tbox.relations/tbox.statuses — das VOLLSTÄNDIGE Typ-Vokabular für compile_done.typing steht direkt in diesem Result, kein separater Tool-Call nötig). Leer = nichts zu tun.
compile_done	Schließt einen geclaimten Compile-Job ab (nach compile_next + upsert_page). keys = die Ziel-Seiten, in die das Artefakt gemergt wurde (jede muss einen [quelle: <item_id>]-Anker tragen, dessen Werte wörtlich in der Quelle stehen — der Server prüft deterministisch); keys=[] = explizites Noise-Signal. Für jede noch untypisierte Ziel-Seite typing[key] = { type, status, relations, confidence } AUSSCHLIESSLICH mit dem T-Box-Vokabular aus dem tbox-Feld der letzten compile_next-Antwort (tbox.types/tbox.relations/tbox.statuses) mitgeben. claim_token aus compile_next.item.claim_token UNVERÄNDERT zurückgeben — er beweist die Lease (sonst lease_lost).
tariff_compare	Vergleicht den aktuellen STROMtarif mit tagesaktuellen Alternativen (Rechenweg je Alternative). Braucht KEINEN Lastgang und KEINE serie_ref — die fünf Rechnungswerte unten reichen (serie_ref gehört zu spot_backtest/load_trend, nicht hierher). Bei Tarif-/Preisfragen dieses Tool nutzen statt Websuche: der Katalog ist tagesaktuell und jede Zahl kommt mit Rechenweg. Aktuell nur Strom: energieart ist PFLICHT (strom\|gas) und 'gas' wird sauber als not_supported abgelehnt — setze es bewusst, nicht raten. Erfrage beim User zuerst: PLZ, Jahresverbrauch (kWh), aktueller Lieferant, Arbeitspreis (ct/kWh brutto), Grundgebühr (€/Monat brutto). Beträge in €/kWh bzw. €/Jahr vorher in ct/kWh bzw. €/Monat umrechnen. Je Tarif im Ergebnis: rabatt_befristet=true bedeutet ein NUR im 1. Jahr wirkender Neukundenbonus — dann jahreskosten_jahr2_eur (Preis ab Jahr 2) mit ausweisen, den Bonus NICHT als Dauer-Ersparnis verkaufen. Beachte netzkosten_vollstaendig: ist es false, ist kein Netzbetreiber hinterlegt und der €-Betrag heißt energiepreis_anteil_eur (nur Energiepreis-Anteil, NICHT jahreskosten_eur) — dem User NICHT als Gesamtrechnung präsentieren. Die VNB-Auflösung macht der Gateway (nb_key vorgelöst).
versorger_abdeckung	Welche STROM-Lieferanten sind an einer PLZ/im Netzgebiet verfügbar (Abdeckungs-Block). Aktuell nur Strom: energieart='gas' wird als not_supported abgelehnt (die Abdeckungsdaten sind Strom-only — es würden sonst Strom-Marken als vermeintliche Gas-Liste erscheinen).
get_knowledge	Deterministische Auslieferung der Wissensschicht (wie sich AT-Stromkosten zusammensetzen o. ä.). Reine Text-Auslieferung, kein Rechen-Result. 'thema' ist ein fester Wiki-Slug — Kern-Themen: 'stromkosten-zusammensetzung', 'netz-netzentgelte', 'tarife', 'steuern', 'foerderung', 'glossar'. Bei unbekanntem Thema listet die Fehlermeldung die gültigen Slugs auf.
analyze_load_profile	Lastprofil-Metriken (Grundlast, Spitzen, Anomalien, Sparpotenziale) + Ursachen-Signale (E-Heizung, PV-Eigenverbrauch, Dauerläufer) + signal-getriebene Rückfragen-Kandidaten aus einer Lastgang-Serie (lastganganalyse-Prozess, Schritte 'lastprofil_metriken' + 'ursachen_signale'). IMMER als erster Analyse-Schritt nach list_load_series. lastprofil läuft auch auf Tageswerten weiter (Granularitäts-Caveat statt Verweigerung); signale verweigert bei Tageswerten (interval_minutes >= 60) — dann signale=null + signale_grund (Q15-Opt-in-Empfehlung), lastprofil bleibt trotzdem verfügbar. Bei PV-Haushalten greifen automatisch Netzbezug-Guards (basis_label='Netzbezug'). Fakt-vor-Heuristik: jeder Signal-Wert trägt eine quelle + profil_abgleich: quelle='profil'/'rechnung'/'messung' ist ein gespeicherter FAKT und IST die Antwort (z.B. aus submit_lastgang_facts) — quelle='heuristik' ist NUR eine Schätzung aus dem Lastprofil. Bei profil_abgleich.status='widerspruch' den Widerspruch dem User BENENNEN, nie stillschweigend zugunsten der Heuristik auflösen.
load_trend	Mehrjahres-Trend (YoY) + Treiber-Zerlegung nach Leistungsband x Tageszeit x Werktag/Wochenende aus einer Lastgang-Serie (lastganganalyse-Prozess, Schritte 'mehrjahres_trend' + 'treiber_zerlegung'). trend: Kalender-YoY nur bei >=2 vollen Kalenderjahren (Coverage-Guard) — sonst Fenster-YoY über deckungsgleiche (Monat,Tag,Std,Min)-Slots; NIE ein Teiljahr gegen ein Volljahr stellen; läuft auch auf Tageswerten weiter (Granularitäts-Caveat). attribution benennt je Treiber eine Geräte-KLASSE als Hypothese — NIE einen Gerätenamen (15-min-Grenze, Abnahme-Kriterium 15) — nur mit >=2 Jahren Q15-Historie verfügbar, sonst attribution=null + attribution_grund (trend bleibt trotzdem verfügbar).
pv_potenzial	NUR bei vorhandener Lastgang-Serie (serie_ref aus list_load_series) mit Viertelstundenwerten. Beantwortet 'Was würde mir eine PV-Anlage bringen?' auf dem ECHTEN Verbrauchsverlauf statt auf einem Standardprofil: je Anlagengröße Ertrag, Eigenverbrauch, Eigenverbrauchsquote, Autarkie, Einspeisung, vermiedene Netzkosten und Amortisation. Das Sonnenertragsprofil des Standorts holt der Gateway (PVGIS) — NIE vom User-LLM. Verweigert bei Tageswerten mit Begründung, weil sich daraus die Tageszeit des Verbrauchs nicht ablesen lässt. Liefert zwei getrennte Ergebnisse: 'gemessen' (nichts modelliert) und 'jahr_modelliert' (Tagessummen + gemessene Tagesform, als Modell gekennzeichnet). Euro-Beträge gibt es nur auf Jahresbasis — ein Teiljahr wird NICHT hochgerechnet. Die Einspeisevergütung ist eine Annahme und wird als Szenario-Band gerechnet.
speicher_dimensionierung	NUR bei vorhandener Q15-Lastgang-Serie. Beantwortet 'Wie groß soll der Batteriespeicher sein?': je Größe Eigenverbrauchsquote, Autarkie, Vollzyklen, Amortisation, Kapitalwert — und den Grenznutzen, also ab welcher Größe die nächste Kilowattstunde fast nichts mehr bringt. Sagt auch ehrlich Nein, wenn keine Größe einen positiven Kapitalwert erreicht. Speicher-Alterung ist NICHT eingepreist; die Vollzyklen je Größe stehen im Ergebnis. Braucht die Anlagengröße (kwp).
spot_backtest	NUR bei vorhandener Lastgang-Serie (serie_ref aus list_load_series). Für den normalen Tarifvergleich aus einer Rechnung ist dieses Tool NICHT nötig — dafür tariff_compare, das ganz ohne Lastgang rechnet. Profilgewichteter Spot-Backtest (echter Verbrauchs-Shape x EPEX-Stundenpreise, aus dem Box-Postgres — NIE vom User-LLM übergeben) vs. aktueller Fixpreis, plus Tarifwechsel-Ersparnis (lastganganalyse-Prozess, Schritt 'spot_und_tarifvergleich'). tarif_ersparnis ist nur verfügbar, wenn plz/energiepreis_brutto_ct_kwh/aktuelle_grundgebuehr_brutto_eur_monat/aktueller_lieferant/jahresverbrauch_kwh vollständig sind — sonst verfuegbar=false + grund (nie eine stille 0). Hebel-Reihenfolge: Tarif zuerst prüfen. Verweigert bei Tageswerten mit Begründung.
foerderungen_check	Offene, verifizierte Förderungen für PV, Speicher, Heizungstausch, Sanierung, Balkonkraftwerk, Geräte-Reparatur und Wallbox — Bund + das gewählte Bundesland, je mit Fördersatz, Bedingungen, Antrags-Link, Zeitfenster (falls terminiert) und Quelle+Stand. Geschlossene oder unsicher markierte Einträge werden NIE ausgespielt. Braucht 'bundesland' ODER 'plz' — die PLZ wird intern aufgelöst; bei mehrdeutiger/unbekannter PLZ (z.B. eine PLZ, die zwei Bundesländer überspannt) kommt eine strukturierte Rückfrage nach 'bundesland' statt eines geratenen Ergebnisses. Optional 'kategorien' filtert auf einzelne Kategorien, z.B. ['pv','speicher']. Sag dem User das Datenstand-Datum ('stand') dazu — das ist KEINE Rechtsberatung, vor jeder Antragstellung immer die verlinkte Primärquelle prüfen. Am besten NACH einem Tarifvergleich anbieten, nicht davor.
energieberatung_info	Kostenlose, produktneutrale Energieberatungsstelle(n) für ein Bundesland (Träger, Kontakt-URL, Quelle). Braucht 'bundesland' ODER 'plz' — die PLZ wird intern aufgelöst; bei mehrdeutiger/unbekannter PLZ kommt eine strukturierte Rückfrage nach 'bundesland'. Reine Informationsauskunft — Gridbert führt keine Beratung durch und vermittelt nicht.
energiegemeinschaften_info	Fakten zu Energiegemeinschaften (GEA, EEG lokal, EEG regional, BEG): Netzentgelt-Vorteile je Rechtsform mit Rechtsquelle und Gültigkeit, die ElWG-Änderung zur Netzentgelt-Reduktion für BEG greift erst ab 31.12.2026 — NICHT schon ab 1.10.2026 (das frühere Datum betrifft nur Begriffs-Definitionen, nicht die Netzentgelt-Bestimmung selbst — diesen Unterschied beim Beantworten nicht verwischen), außerdem Marktstand und die sechs Beitrittsschritte. Optionales 'bundesland' liefert zusätzlich bekannte Verzeichnis-Einträge aus der amtlichen Landkarte — das Verzeichnis ist NICHT vollständig (freiwillig befüllt, deckt nur einen Teil der Bürgerenergiegemeinschaften ab, keine Erneuerbare-Energie-Gemeinschaften); ohne Treffer liefert das Tool einen ehrlichen Hinweis statt einer leeren Behauptung. Sag dem User das Datenstand-Datum dazu. Keine Rechtsberatung.
submit_invoice_facts	Übergibt EXAKT abgelesene Rechnungswerte + wörtliche Zitate. Validiert deterministisch (energieart muss strom\|gas\|kombi sein — Nicht-Energie-Rechnungen z.B. Restaurant werden mit error_class=validation_rejected und benanntem Grund abgelehnt, nichts wird gespeichert), rechnet finalize, schreibt die Fakten-Submission in den Raw-Store. PFLICHT: energieart, lieferant, plz, verbrauch_kwh, zeitraum_von, zeitraum_bis (ISO YYYY-MM-DD oder DE TT.MM.JJJJ) und quellen_anker. Zusätzlich muss arbeitspreis (ct/kWh) ODER summe_energieentgelte vorliegen. quellen_anker sind Objekte {feld, zitat} — je ein wörtliches Zitat für den Verbrauch und einen Betrag, z.B. quellen_anker=[{"feld":"verbrauch_kwh","zitat":"Jahresverbrauch 2562,3 kWh"},{"feld":"arbeitspreis","zitat":"Arbeitspreis 16,02 ct/kWh"}]. Lehnt bei Unplausibilität feld-genau mit Rückfrage ab (nichts wird gespeichert). Dieses Tool speichert nur — die Frage 'zahle ich zu viel?' beantwortet erst tariff_compare, das danach im selben Zug zu rechnen ist.
get_switch_info	Wechsel-Infos (Schritte, Fristen, Kontaktweg) aus Katalogdaten. Reine Information — KEIN Vollmacht-Flow, keine Durchführung.
capability_gap	Melde einen fehlenden Bedarf, wenn ein Werkzeug für eine Energie-Frage fehlt (Unmet-Demand-Signal).
request_data_release	Fordert die Datenfreigabe für einen Zählpunkt an (EDA-Consent, CM_REQ_ONL — lastganganalyse-Prozess, Schritt 'datenfreigabe_anfordern'). Der Zählpunkt MUSS aus den Invoice-Fakten der Instanz stammen (get_page/search_pages) — nicht vom User abtippen lassen. Nur aufrufen, wenn list_load_series noch keine aktive Freigabe für diesen Zählpunkt zeigt (kein doppelter Consent-Flow). energy_direction ist PFLICHT (consumption\|generation) — bewusst setzen, NICHT raten: eine falsche Richtung wedged den Zählpunkt beim Netzbetreiber (langes 'pending', dann Fehler bei jedem Retry). Ist die Richtung nicht klar aus den Invoice-Fakten ableitbar, den User zuerst fragen: 'Hast du eine PV-Anlage mit Einspeisung an diesem Zählpunkt?' Kündige dem User EXAKT an: 'Du bekommst zwei Freigabe-Anfragen im Netzbetreiber-Portal unter Freigaben→Offen (Provider EP100505) — zuerst die Energiedaten, wenige Stunden später eine zweite für Stammdaten (Adresse/Zählerdaten).' Beide sind eigene Consents mit eigenem Lifecycle — die zweite (ST/MasterData) feuert der Netzbetreiber automatisch, du musst sie nicht selbst auslösen, aber im Portal ebenfalls bestätigen. Nach jeder Bestätigung folgt die Bestätigung deines Netzbetreibers automatisch, meist ~30 Minuten werktags, am Wochenende auch mal Stunden (ehrlich sagen, kein Live-Spinner). Bei bestätigter PV-Einspeisung: ZWEITER Aufruf mit energy_direction='generation' und dem Einspeise-Zählpunkt (eigene Nummer, i.d.R. Suffix …9901).
get_data_release_status	Fragt den Status einer Datenfreigabe ab (pending/active/revoked/…) + den aktuellen Datenstand der Serie (lastganganalyse-Prozess, Schritt 'datenfreigabe_status'). WARTE-UX ist PFLICHT: nach jeder Bestätigung im Netzbetreiber-Portal folgt die Bestätigung des Netzbetreibers automatisch, meist ~30 Minuten werktags, am Wochenende auch mal Stunden (Markt-Latenz, nicht dein Fehler) — sag das dem User ehrlich, statt endlos zu pollen. Erinnere bei 'pending' an die ZWEITE, spätere Freigabe-Anfrage für Stammdaten (Doc §2) — kein Fehler, wenn sie erst Stunden nach der ersten erscheint. Ohne zaehlpunkt liefert es den Status ALLER Freigaben des Accounts.
list_load_series	Listet alle Lastgang-Serien am Account (Zählpunkt MASKIERT, Richtung, Zeitraum, Coverage, Granularität, Datenstand — lastganganalyse-Prozess, Schritt 'serien_uebersicht'). IMMER als ERSTER Schritt aufrufen: bevor eine neue Datenfreigabe angefordert wird (kein doppelter Consent-Flow) und bevor ein Analyse-Tool (analyze_load_profile/load_trend/spot_backtest) aufgerufen wird — liefert den serie_ref, den die Analyse-Tools brauchen.
submit_lastgang_facts	Übergibt die beantworteten Rückfragen aus der Lastgang-Analyse (Heizung, PV-Eckdaten, Dauerläufer, Lastverschiebung, Heizstromtarif, Q15-Opt-in — lastganganalyse-Prozess, Schritt 'rueckfragen_persistieren') als Profil-Fakten. Validiert deterministisch gegen die bekannten Felder — unbekannte Felder oder unplausible Werte werden mit error_class=validation_rejected abgelehnt (nichts wird gespeichert). Gleiche Rejection-Semantik wie submit_invoice_facts (D2.2).
get_tbox	Liefert die deklarative Union-T-Box (core ∪ gridbert-at-energie) + Version der Instanz — für Ontologie-Diagnose ausserhalb eines laufenden Compile-Jobs (der normale Compile-Flow bekommt das Vokabular bereits inline über compile_next.tbox).
list_workspaces	Listet die Arbeitsbereiche des Beraters: eigener Bereich + alle Kunden mit aktiver Freigabe (Grant), inkl. Datenstand.
select_workspace	Wechselt den aktiven Arbeitsbereich des Beraters (Kunde per Slug oder eindeutigem Label; 'eigen' = eigener Bereich). Die Auswahl gilt account-weit bis zum nächsten Wechsel.