ENAnmeldenRegistrieren
Wiederholbare Berichte mit MCP erstellen

Wiederholbare Berichte mit MCP erstellen

Von Tristan Doehl · · Aktualisiert am

Ein Timer-Befehl ändert einen Datensatz. Eine Wochenprüfung benötigt mehrere Abfragen und eine Entscheidung darüber, was ihre Ergebnisse bedeuten. Teetracks MCP-Tools liefern die Datengrundlage dafür. Ein wiederholbarer Ablauf braucht zusätzlich eindeutige Datumsangaben, eine klare Ausgabe und einen Umgang mit unvollständigen Ergebnissen.

Definiere den Bericht vor der Anfrage

Wähle Zeitraum, Projekte und benötigte Kennzahlen. Ein Wochenbericht kann tatsächliche erfasste Stunden, abrechenbare Stunden und abrechenbare Beträge je Projekt zeigen. Verwende beim Vergleich zweier Wochen entsprechende Datumsbereiche und benenne die Zeitzone für deren Grenzen.

Eine beispielhafte Anfrage lautet: „Vergleiche Acme-Neugestaltung vom 23. Februar bis 1. März mit dem Zeitraum 16. bis 22. Februar 2026. Zeige erfasste und abrechenbare Stunden je Woche und anschließend die Einträge hinter Abweichungen. Halte Währungen getrennt.“ Damit ist die Frage definiert und die zugrunde liegende Arbeit bleibt überprüfbar.

Entwickle die Erklärung aus den abgefragten Datensätzen

Verwende list_tracks mit after, before, project_id und done: true für jede Woche. Diese Datumsgrenzen schließen den Grenzwert aus: Ein Eintrag, der genau am Montag um 00:00 beginnt, fehlt in der Liste, während get_project_summary ihn mitzählt. Setze after daher eine Sekunde vor den Wochenbeginn. Rufe alle relevanten Ergebnisseiten ab, bevor du die ungerundeten Dauern der abgeschlossenen Einträge addierst. Verwende für beide Wochen dieselben Regeln für Abrechenbarkeit und Zeitzone. Benenne fehlende Ergebnisse, wenn eine Abfrage scheitert.

get_project_summary akzeptiert Datumsgrenzen und eine Ergebnisanzahl, wendet aber deine Teetrack-Rundung an. Kennzeichne diese Summen bei aktivierter Rundung entsprechend: Eine Abweichung von den einzelnen Zeitstempeln kann durch die Rundung entstehen. get_time_summary nimmt keine Parameter entgegen und liefert gleitende Summen, vom Zeitpunkt der Anfrage aus gerechnet. Die Felder day, month und year umfassen die letzten 24 Stunden, 30 Tage und 365 Tage, total den gesamten Verlauf. Laufende Timer zählen mit, und im Free-Tarif reicht kein Wert weiter als 90 Tage zurück. Am 5. März reicht der Wert in month deshalb bis in den Februar zurück. Einen Kalendermonat oder zwei ausgewählte Wochen bildet das Tool also nicht ab.

Eine Stundendifferenz beschreibt eine Veränderung der erfassten Arbeit. Sie belegt weder gestiegene Produktivität noch ein stockendes Projekt. Lies die Beschreibungen und berücksichtige Urlaub, Umfangsänderungen und Erfassungslücken, bevor du die Zahl erklärst.

Nutze die Budgetprüfung für eine konkrete Entscheidung

Projektbudgets benötigen Business oder Pro. get_budget_status akzeptiert Datumsgrenzen und liefert alle Projekte, bei Projekten ohne Budget mit leeren Budgetwerten; einen Projektfilter gibt es nicht. Wähle das gewünschte Projekt aus der Rückgabe und vergleiche trackedHours mit budgetHours oder actualAmount mit budgetAmount. Das Feld overBudget wird bereits wahr, sobald die Warnschwelle des Projekts erreicht ist, etwa bei 80 %. Es bedeutet also nicht zwingend, dass das Budget überschritten wurde. Für eine Prüfung des gesamten Projektbudgets muss der Zeitraum die gesamte Projektarbeit abdecken, nicht nur die Berichtswoche. Der Budgetverbrauch verwendet ungerundete Dauern und Beträge.

Hat ein Projekt mit 40 Stunden Budget bereits 30 Stunden verbraucht, bleiben 10 Stunden. Benötigen Prüfung und Umsetzung voraussichtlich weitere 16 Stunden, überschreitet die Prognose das Budget um 6 Stunden. Im Wochenbericht sollte stehen, welche Arbeit verschoben oder welche zusätzliche Zeit freigegeben werden muss.

Trenne gespeicherte Anfragen von einem Zeitplan

Eine für Montag gespeicherte Anfrage ist eine wiederverwendbare Anweisung. Sie läuft, wenn du sie absendest. Soll dieser Schritt entfallen, muss ein externer Zeitplaner den Assistenten oder eine Anwendung mit den nötigen Zugangsdaten aufrufen, Ergebnisse sammeln und den Bericht bereitstellen. Teetracks MCP-Endpunkt plant kein Gespräch, nur weil du um eine regelmäßige Prüfung bittest.

Beginne geplante Abläufe mit Berichten, die nur lesen. Lege fest, wohin die Ausgabe geht, wie ein Fehler gemeldet wird und wer das Ergebnis prüft. Für E-Mails oder Beiträge in anderen Diensten braucht es neben der Teetrack-Verbindung auch deren Integration und Autorisierung.

Verhindere Schäden durch Wiederholungen

Ein mehrstufiger Ablauf kann enden, nachdem nur ein Teil erledigt wurde. Frage vor dem erneuten Erstellen von Einträgen den Zeitraum ab und prüfe, was bereits existiert. Halte bei Aktualisierungen die Ziel-IDs und die beabsichtigten Werte fest, damit sich das Ergebnis kontrollieren lässt.

Verwende Löschen und Neuerstellen nicht als übliche Korrekturstrategie. Das Löschen entfernt Datensätze und kann den Zusammenhang zerstören, den du erhalten möchtest. Wenn eine Bearbeitung genügt, ändere den konkreten Eintrag und prüfe ihn danach.

Schließe die Wochenprüfung mit einer Entscheidung ab

Beende den Bericht mit den nötigen Eintragskorrekturen, fehlenden Abfrageergebnissen und offenen Budgetentscheidungen. Halte daneben Zeitraum und Rundungsgrundlage fest, damit die nächste Wochenprüfung an denselben Aufgaben anknüpfen kann.

Die MCP-Einführung beschreibt die Verbindung. Baue Automatisierung auf einem Bericht auf, den du bereits manuell nachvollziehen kannst. Ergänze einen Zeitplan erst, wenn Eingaben, Ausgabe und Fehlerbehandlung geklärt sind.

Tristan Doehl

Tristan Doehl

Tristan is the founder of Teetrack and a software engineer based in Aachen, Germany. He started Teetrack as his own tool for tracking billable hours as a developer and has been building it into a full time-tracking product for freelancers and small teams ever since. He writes about time tracking, freelance billing, and AI-assisted workflows.