PathruleMCP-Tools-Referenz
Die MCP-Tools von Pathrule nach Laufzeitumgebung und Zweck, einschließlich der lokalen Workflow-Tools und des schmaleren, Cloud-nativen Remote-MCP-Katalogs.
Auf dieser Seite
Diese Seite listet die MCP-Tools von Pathrule nach Fähigkeit auf. Der Assistent braucht selten alle davon. Die meisten Sessions berühren nur pathrule_get_context plus ein oder zwei Lese- oder Schreibzugriffe. Der lokale stdio-Server und das gehostete Remote MCP bieten jeweils nur die Operationen an, die ihre Laufzeitumgebung tatsächlich ausführen kann.
Das zugrunde liegende Modell beschreibt die MCP-Überblick.
Kontext und Erkundung
| Tool | Zweck |
|---|---|
pathrule_get_context | Der zentrale Einstiegspunkt. Ordnet das aktuelle Arbeitsverzeichnis einem Workspace-Knoten zu und liefert den passenden Ausschnitt an Memories, Regeln und Skills für die Aufgabe. |
pathrule_get_tree | Liefert den Knotenbaum des Workspace (Ordner, Dateien, Kontexte). Hilfreich für Prompts zur Erkundung. |
pathrule_get_node | Ruft einen einzelnen Knoten samt der zugeordneten Memories, Regeln und Skills ab. |
pathrule_resolve | Ordnet einen bekannten Titel oder Namen einer ID, einem Pfad und einem Versions-Handle zu, ohne den Baum zu durchlaufen. Bei einem eindeutigen Treffer kann der Inhalt im selben Aufruf mitkommen. Lokales stdio. |
pathrule_read | Liest IDs von Memories, Regeln und Skills gebündelt in einem einzigen Roundtrip, bis zur Obergrenze des Servers. Lokales stdio. |
pathrule_goto | Löst einen Namen oder Pfad unscharf zu einer Knoten-ID auf. Hilfreich, wenn der Nutzer ein Ziel nur ungefähr benennt. |
pathrule_knowledge_map | Eine schreibgeschützte Karte der Memories, Regeln und Skills des Workspace, gruppiert in zusammengehörige Bereiche: der ganze Workspace auf einen Blick, die Einträge und Probleme eines Bereichs oder was sonst noch mit bestimmten Einträgen, Dateien oder einer Suchanfrage zusammenhängt. Hilfreich vor einer Qualitätsrunde oder bevor du Wissen aktualisierst. |
pathrule_ping | Health Check. Liefert die Sicht der Laufzeitumgebung auf das aktuelle Arbeitsverzeichnis und einen Zeitstempel. |
pathrule_setup | Richtet Pathrule in einem neuen Repo ein, indem es erste Memories, Regeln und Skills vorschlägt, die der Nutzer freigeben kann. |
Die meisten Sessions beginnen und enden mit pathrule_get_context. Die Antwort enthält die Workspace-Übersicht, die passenden Inhalts-IDs und einen Hinweis darauf, welches Tool als Nächstes aufgerufen werden sollte. Der Assistent folgt diesem Hinweis, statt zu raten.
Memories
| Tool | Zweck |
|---|---|
pathrule_list_memories | Listet die Memories unter einem Pfad mit Titeln und kurzen Vorschauen auf. Der virtuelle MainMemory-Index. |
pathrule_read_memory | Liefert den vollständigen Inhalt einer Memory anhand der ID, einschließlich des Versions-Tokens für optimistische Nebenläufigkeitskontrolle. |
pathrule_write_memory | Legt eine Memory an einem Knotenpfad an. Fehlende Knoten entlang des Pfads werden automatisch angelegt. Als Quelle wird bei Aufrufen über MCP standardmäßig claude gesetzt. |
pathrule_update_memory | Bearbeitet eine bestehende Memory: als vollständige Ersetzung oder als kleine, gezielte Änderung mit content_edit. move_to_path verschiebt sie an einen anderen Ort, und restore: true holt eine gelöschte Memory zurück. Übergib expected_version_id, damit eine gleichzeitige Bearbeitung sauber als Konflikt erkannt wird. |
pathrule_delete_memory | Löscht eine Memory vorläufig (Soft Delete). Wiederherstellbar, bis sie endgültig gelöscht wird. hard: true löscht sie endgültig und erfordert einen Workspace-Admin. |
Der übliche Ablauf: get_context, um die passende Memory-ID zu finden, dann read_memory für den Inhalt, falls der Assistent daraus zitieren muss, und write_memory, wenn der Nutzer etwas festhalten möchte.
Regeln
| Tool | Zweck |
|---|---|
pathrule_read_rule | Liefert den vollständigen Inhalt einer Regel anhand der ID. |
pathrule_write_rule | Legt eine Regel an einem Knotenpfad an, mit einem Geltungsbereich (folder, file_type, project) und einer Priorität (high, medium, low). Das Tool kann außerdem ein Blockiermuster oder eine Pflichtprüfung vorschlagen; ein solcher Vorschlag wird als Vorschlag gespeichert, ein Agent kann ihn nicht freigeben, und durchgesetzt wird nichts, bevor ein Mensch ihn freigegeben hat. |
pathrule_update_rule | Bearbeitet eine bestehende Regel mit optimistischer Nebenläufigkeitskontrolle. Verschiebt sie außerdem an einen anderen Pfad oder stellt eine gelöschte Regel wieder her. |
pathrule_delete_rule | Löscht eine Regel vorläufig (Soft Delete). Wiederherstellbar, bis sie endgültig gelöscht wird. |
Regeln gelten auf Workspace-Ebene und können mehreren Knoten zugeordnet werden. Wer eine Regel am selben Pfad ein zweites Mal schreibt, sollte Update statt Write verwenden, um Duplikate zu vermeiden.
Skills
| Tool | Zweck |
|---|---|
pathrule_read_skill | Liefert den vollständigen SKILL.md-Inhalt eines Skills anhand der ID. Bei github_ref-Skills kommt der zwischengespeicherte Snapshot zurück. |
pathrule_write_skill | Legt einen Skill an einem Knotenpfad an. Akzeptiert die vollständige SKILL.md einschließlich Frontmatter. Als Quelle sind manual, template oder github_ref möglich. |
pathrule_update_skill | Bearbeitet einen bestehenden Skill mit optimistischer Nebenläufigkeitskontrolle. Verschiebt ihn außerdem an einen anderen Pfad oder stellt einen gelöschten Skill wieder her. |
pathrule_delete_skill | Löscht einen Skill vorläufig (Soft Delete). Wiederherstellbar, bis er endgültig gelöscht wird. |
Den Ablauf beim Verfassen beschreibt Skills schreiben. Ein Assistent erstellt zuerst einen Entwurf und ruft pathrule_write_skill auf, nachdem der Nutzer den Inhalt freigegeben hat.
Patterns
| Tool | Zweck |
|---|---|
pathrule_import_pattern | Zeigt ein veröffentlichtes Bündel aus Memories, Regeln und Skills in der Vorschau an und importiert es am gewählten Workspace-Pfad. |
pathrule_remove_pattern | Entfernt die Bestandteile, die zu einem zuvor importierten Pattern-Bündel gehören. |
Aktivität
| Tool | Zweck |
|---|---|
pathrule_log_activity | Protokolliert einen strukturierten Eintrag zu einer Antwort, die Dateien ändert. Pflicht nach jeder Antwort, die Dateien anlegt, bearbeitet oder löscht. Felder: domain, action, scope, subjects, files_touched, task_summary. |
Das Activity-Log speist die jüngsten Aktivitäten des Workspace, die die VS Code-Erweiterung in ihrer Ansicht Recent Activity anzeigt, sowie die daraus abgeleiteten Lernschichten. Ein Eintrag pro Antwort (nicht pro Datei) ist die richtige Granularität.
Projektlernen
Was ein Agent aus deinem Code erschließt, festgehalten zusammen mit den Dateien, die er gelesen hat, und geteilt mit dem Workspace. Siehe Projektlernen.
| Tool | Zweck |
|---|---|
pathrule_record_learning | Speichert eine Erkenntnis, zu der der Agent beim Lesen des Codes gekommen ist, zusammen mit den gelesenen Dateien und ihrem Inhalt. Pathrule prüft diese Dateien auf der Festplatte, bevor es die Erkenntnis annimmt. Eine Erkenntnis ist weder Memory noch Regel noch Skill; sie erreicht den Agenten jedes Mitglieds als zu prüfender Hinweis im vom Agenten angeforderten Kontext, solange ihre Quellen in diesem Checkout unverändert sind. Sie wird nie automatisch zur Regel hochgestuft. Übergib die ID einer früheren Erkenntnis, um sie durch eine korrigierte zu ersetzen. |
pathrule_review_learning | Listet aktuelle, veraltete und widersprüchliche Erkenntnisse auf, auch die, die aus dem Kontext zurückgehalten werden, und widerruft eine Erkenntnis anhand der ID. Widerrufen kann eine Erkenntnis nur die Person, deren Agent sie festgehalten hat, und der Widerruf gilt für den ganzen Workspace. |
pathrule_review_history | Liest frühere Review-Diskussionen am GitHub-Origin des Repositorys über deinen bestehenden gh-Login, damit ein Agent sieht, wie das Team eine ähnliche Frage schon einmal entschieden hat. Es speichert keine Kommentare und überspringt Reviews von Bots, von Externen sowie verworfene Reviews; ohne GitHub-Zugriff funktioniert alles andere weiterhin. |
Vorschläge und Auffrischung
| Tool | Zweck |
|---|---|
pathrule_list_pending_refreshes | Listet veraltete Memories und Regeln auf, die der Selbst-Audit markiert hat. |
pathrule_get_refresh_brief | Übernimmt eine Auffrischungsaufgabe und liefert den vollständigen Kontext für die Korrektur, einschließlich des Audit-Grunds und der Anweisungen für den Assistenten. |
pathrule_resolve_refresh | Markiert eine Auffrischungsaufgabe als umgesetzt oder abgelehnt. Schließt den Human-in-the-Loop-Workflow ab. |
pathrule_request_refresh | Markiert eine Memory oder Regel, die der Assistent bei der normalen Arbeit als veraltet, widersprüchlich, doppelt, zu eng gefasst oder unklar erkannt hat. |
Über Vorschläge verhindert Pathrule, dass der Inhaltsbaum mit der Zeit auseinanderdriftet. Der Assistent kann ein konkretes Problem markieren, eine Aufgabe übernehmen, eine Korrektur vorschlagen und sie abschließen, ohne den Editor zu verlassen.
Lokale Lazy-Write-Steuerung
Der lokale stdio-Server bietet seinen vollständigen Tool-Satz schon beim ersten tools/list an: Lesen, Schreiben, Aktualisieren, Löschen, Patterns, Setup, Auffrischung und Aktivität. Vor dem ersten Schreibzugriff muss nichts freigeschaltet werden, und die Liste bleibt die ganze Session über gleich. Eine lange Unterhaltung zahlt also nie für eine Tool-Liste, die sich mittendrin ändert.
Wenn du jede Session lieber mit einer kleineren Liste beginnst, kannst du optional den Lazy-Modus aktivieren. Setze dazu PATHRULE_MCP_TOOLS=lazy in der Umgebung des Pathrule-MCP-Eintrags. Im Lazy-Modus sind beim Start die Lese-Tools und pathrule_log_activity sichtbar, außerdem erscheint ein zusätzliches Tool:
| Tool | Zweck |
|---|---|
pathrule_enable_writes | Nur im Lazy-Modus. Schaltet die Tools für Schreiben, Aktualisieren, Löschen, Patterns, Setup und ändernde Auffrischungsoperationen für den Rest der MCP-Session frei. Der Server sendet daraufhin einmal tools/list_changed. |
Der Lazy-Modus entfernt nichts; er ändert nur, ab wann ändernde Tools sichtbar sind. Ohne die Variable oder mit einem anderen Wert gibt es pathrule_enable_writes nicht, weil es nichts freizuschalten gibt.
Gehostetes Remote MCP
Remote MCP hat eigene, Cloud-native Schemas. Eine Leseberechtigung stellt sieben Tools bereit: pathrule_get_context sowie je ein List- und Read-Tool für Memories, Regeln und Skills. Eine Schreibberechtigung ergänzt für jede Art Write, Update, Delete und History, sodass der vollständige Katalog neunzehn Tools umfasst.
| Operation | Remote-Argumente und Verhalten |
|---|---|
| Kontext, Listen und Lesen | Beschränkt auf den Workspace, der in der OAuth-Berechtigung freigegeben wurde |
| Schreiben | path, title und body, mit einer stabilen Operations-ID |
| Aktualisieren | id des Eintrags, numerisches expectedVersion, title und body, mit einer stabilen Operations-ID |
| Löschen | Vorläufiges Löschen mit erhaltener Historie, im Rahmen der Schreibberechtigung |
| Historie | Historie pro Eintrag, im Rahmen der Schreibberechtigung |
Der Autorisierungsserver erkennt pathrule:read, pathrule:write, pathrule:refresh und pathrule:activity. Erkannte Scopes fügen keine Tools hinzu, die im Katalog fehlen. Remote MCP bietet keine Organisationsverwaltung, kein Workspace-Setup, keine Snapshots, keine Pattern-Importe, kein Projektlernen, kein Activity-Logging und keine Auffrischungs-Workflows. Es installiert keine Hooks und liest keine lokalen Dateien.
Mit tools/list auf dem verbundenen Server siehst du die genauen Schemas. Remote MCP behandelt die Autorisierung und die Grenze zur lokalen Bereitstellung.
Konventionen
Die folgenden Konventionen gelten für die lokale stdio-Oberfläche. Die Remote-Schemas sind oben beschrieben.
- Schreiben über den Pfad. Schreib-Tools erwarten einen workspace-relativen
node_pathwie/apps/apioder/. Existiert der Pfad nicht, werden die Zwischenknoten automatisch angelegt. - Optimistische Nebenläufigkeitskontrolle. Update- und Delete-Tools akzeptieren eine
expected_version_idaus einem vorherigen Lesezugriff. Bei Abweichung kommt eine eindeutige Konfliktantwort mit der aktuellen Version zurück, sodass der Assistent neu lesen und zusammenführen kann, statt zu überschreiben. - Duplikate werden abgelehnt. Eine Memory, deren Titel an diesem Pfad schon existiert, oder eine Regel bzw. ein Skill, deren Name im Workspace schon existiert, wird mit einem Duplikatfehler abgewiesen, damit der Assistent stattdessen den bestehenden Eintrag aktualisiert. Eine Memory oder Regel lässt sich mit
allow_duplicate: truedennoch anlegen, nachdem der Assistent den bestehenden Eintrag geprüft hat. - Standardmäßig kompakt. Antworten sind für den üblichen Fall kompakt gehalten. Auf dem lokalen Server übergibst du
verbose: true, wenn du den vollständigen Eintrag zurückbekommen möchtest. - Stabile IDs. Tool-Antworten enthalten stabile Werte für
idundversion_id. Der Assistent kann sich in Folgeaufrufen darauf beziehen, ohne das übergeordnete Element erneut zu lesen.
Weiterlesen
- MCP-Überblick für das Modell hinter der Tool-Oberfläche.
- So funktionieren Hooks für die Push-Schicht, die diese Pull-Aufrufe ergänzt.
- Memories schreiben, Regeln schreiben, Skills schreiben für das, was in die Schreibzugriffe gehört.