AST Code Editor MCP-Server

Ein robuster, sprachunabhängiger Model Context Protocol (MCP)-Server, der KI-Coding-Agenten die Möglichkeit bietet, Dateien chirurgisch über Abstract Syntax Trees (AST) zu bearbeiten, anstatt sich auf tokenintensive, fehleranfällige Suchen-und-Ersetzen- oder Diff-Operationen zu verlassen.

Warum AST-Bearbeitungen?

Jedes Nicht-AST-Bearbeitungsformat – Suchen/Ersetzen, Unified Diff, Umschreiben der gesamten Datei – erfordert, dass das Modell Text perfekt aus einer Datei kopiert, die es einmal gesehen hat. Ein einziger Whitespace-Fehler in einer 4.000 Zeilen langen Datei und die Bearbeitung schlägt fehl. AST-Bearbeitungen umgehen das Problem vollständig: Das Modell benennt das Ziel (z. B. LRUCache.get) und liefert den neuen Code; der Parser findet heraus, wo er sich befindet.

Geometric AGI hat jedes wichtige Format über 4 Modelle und 29 Bearbeitungsaufgaben hinweg gebenchmarkt. AST-Bearbeitungen waren das einzige Format, das bei 3 von 4 Modellen eine 100%ige Korrektheit erreichte, mit 18-mal weniger Output-Tokens als das Umschreiben der gesamten Datei und null Formatfehlern. Vollständige Methodik und Ergebnisse: AST Edits: The Code Editing Format Nobody Uses.

Credits

Dieser MCP-Server wurde durch die Forschung von Jack Foxabbott und dem Team von Geometric AGI inspiriert. Ihre vollständigen Ergebnisse, die Benchmark-Suite und die Daten sind hier verfügbar:

AST Edits: The Code Editing Format Nobody Uses (Blog)
Jack Foxabbotts ursprünglicher Beitrag (LinkedIn)
GeometricAGI/blog (Benchmark-Code & Daten)

Geschätzte Token-Einsparungen

Output-Token-Einsparungen pro Bearbeitung im Vergleich zu anderen gängigen Bearbeitungsformaten:

Bearbeitungsgröße	Dateigröße	vs. Umschreiben der gesamten Datei	vs. Unified Diff	vs. Suchen/Ersetzen
1-Zeilen-Anpassung	100 LoC	3–5x	~1.5x	~1.5x
Umschreiben des Funktionskörpers	500 LoC	8–12x	2–3x	2–3x
Umschreiben des Funktionskörpers	4.000 LoC	15–20x	3–5x	3–5x
2 Zeilen zu einer Funktion hinzufügen	beliebige Größe	~20x (via `prepend_to_body` / `append_to_body`)	5–10x	3–5x

Input-Token-Einsparungen pro Lesevorgang im Vergleich zum Lesen der gesamten Datei:

Leseaufgabe	Dateigröße	AST-Reader-Tool	vs. Lesen der gesamten Datei
Quellcode einer Funktion	500 LoC	`read_symbol`	~20x weniger Tokens
Quellcode einer Funktion	2.000 LoC	`read_symbol`	~50-100x weniger Tokens
Klassen-API (10 Methoden, keine Körper)	500 LoC	`read_interface`	~10x weniger Tokens
Nur Import-Block	beliebige Größe	`read_imports`	~20-50x weniger Tokens
Struktureller Überblick (Namen + Zeilennummern)	beliebige Größe	`list_symbols`	~15-30x weniger Tokens
Signatur einer Funktion	beliebige Größe	`get_signature`	~50-200x weniger Tokens

Für tägliche Agenten-Nutzer ist eine realistische Reduzierung der Gesamttokens pro Sitzung um 40-60 % im Durchschnitt erreichbar (durch Kombination von Output-Einsparungen bei chirurgischen Bearbeitungen mit Input-Einsparungen bei gezielten Lesevorgängen).

Die Einsparungen ergeben sich aus vier sich verstärkenden Effekten:

Output-Tokens: Verwendung von prepend_to_body / append_to_body für kleine Ergänzungen anstelle des Umschreibens ganzer Funktionskörper
Input-Tokens: Verwendung von read_symbol / read_interface / read_imports, um nur das Notwendige zu lesen, anstatt ganzer Dateien (~10-20x weniger Input-Tokens pro Lesevorgang)
Entdeckung: list_symbols / get_signature anstelle des Lesens ganzer Dateien
Null Formatfehler: AST-Bearbeitungen scheitern nie an Whitespace-Verschiebungen, wodurch Wiederholungsschleifen, die andere Formate plagen, eliminiert werden.

Unterstützte Sprachen & Fähigkeiten

Sprache	Erweiterungen	Strukturelle Bearbeitungen	Kommentare	Docstrings	Hinweise
Python	`.py`	✅	✅ `#`	✅ Funktion/Klasse	Dekoratoren bleiben erhalten. `dict`/`list`-Literale auf Modulebene bearbeitbar via `add_key` / `append_to_array`.
JavaScript	`.js`, `.jsx`, `.mjs`, `.cjs`	✅	✅ `//` + `/* ... */`	—
TypeScript	`.ts`, `.tsx`	✅	✅ `//` + `/* ... */`	—	Interfaces werden für `add_method` / `add_field` wie Klassen behandelt.
C	`.c`, `.h`	✅	✅ `//` + `/* ... */` (ein- + mehrzeilig)	—	`.h` standardmäßig C — verwenden Sie `.hpp`/`.hxx`/`.hh` für C++-Header.
C++	`.cpp`, `.cc`, `.cxx`, `.hpp`, `.hxx`, `.hh`	✅	✅ `//` + `/* ... */` (ein- + mehrzeilig)	—	Unterstützt `class`, `struct`, `union`, `enum`, `namespace`; `Class::method` qualifizierte Namen werden korrekt aufgelöst.
Ruby	`.rb`	✅	✅ `#`	—	Klassen, Module, Instanzmethoden, `singleton_method` (Klassenmethoden via `def self.foo`). `require`/`require_relative`/`load`/`autoload` als Importe erkannt.
Go	`.go`	✅	✅ `//` + `/* ... */`	—	`struct`, `interface`, Funktionen, Methoden. Methoden werden über den Receiver adressiert: `Cache.Get` löst sich zu `func (c *Cache) Get(...)` auf oberster Ebene auf. Gruppierte `import (...)`-Blöcke unterstützt.
Java	`.java`	✅	✅ `//` + `/* ... /` + Javadoc `/* ... */`	—	`class`, `interface`, `enum`, `record`; Methoden, Konstruktoren, Felder. Annotationen (`@Override`, `@Deprecated`) wandern bei Bearbeitungen mit ihrer Methode mit (eingebettet im `modifiers`-Knoten). Enum-Methoden (verschachtelt in `enum_body_declarations`) werden via BFS in `list_symbols` entdeckt.
JSON	`.json`	✅ (Keys, Values, Arrays)	— (keine Kommentarsyntax)	—
YAML	`.yml`, `.yaml`	✅ (Keys, Values, Sequenzen)	✅ `#`	—	Block- und Flow-Sequenzen unterstützt.
TOML	`.toml`	✅ (Keys, Values, Arrays, Tabellen)	✅ `#`	—	`[table]`-Header für Kommentar-Tools namentlich adressierbar.

Übergreifende Funktionen:

Dekorierte Funktionen (Python @decorator): Dekoratoren bleiben bei Körper-/Signaturbearbeitungen erhalten und werden beim Löschen mit einbezogen.
Byte-korrektes Slicing: Multi-Byte-Zeichen (Emojis, ═, →) werden im Quelltext sicher behandelt.
Idempotente Importe: add_import überspringt exakte Duplikate automatisch.

Sprachspezifische Designentscheidungen

Einige Tools haben sprachspezifische Semantiken, bei denen mehrere vernünftige Interpretationen existieren. Das gewählte Verhalten ist hier zur Transparenz dokumentiert:

add_field (Ruby und Go) — Option (a): wörtliche Textübernahme

Ruby: add_field("LRUCache", " attr_accessor :capacity") fügt den wörtlichen String am Anfang des Klassenkörpers ein. Das Tool umschließt nackte Namen in attr_accessor nicht automatisch — Sie geben den exakten Text an, den Sie möchten (sei es attr_accessor, attr_reader, @instance_var = nil in initialize oder CLASS_CONST = 42).
Go: add_field("Cache", "\tversion int") fügt den wörtlichen String in den struct { ... }-Körper ein. Das Tool leitet Typen nicht aus nackten Namen ab — Sie geben die vollständige Go-Felddeklaration an.
Begründung: Konsistent mit der Funktionsweise von add_field für andere Sprachen (Python, JS/TS, C++), bei denen der Aufrufer den vollständigen Quelltext bereitstellt. Die alternative Option (b) — automatisches Umschließen (z. B. attr_accessor :foo aus dem Namen foo) — wäre magischer, aber schwieriger für Sonderfälle zu verwenden (typisierte Felder, schreibgeschützte Felder, Felder mit Standardwert usw.).

add_method (Go) — Option (a): Einfügen auf oberster Ebene

add_method("Cache", "func (c *Cache) Has(key string) bool { ... }") lokalisiert die type Cache struct { ... }-Deklaration und fügt die neue Methode direkt danach auf oberster Ebene ein (nicht innerhalb der geschweiften Klammern des Structs).
Begründung: Go-Methoden sind lexikalisch auf oberster Ebene, nicht innerhalb ihres Receiver-Typs verschachtelt — dies entspricht der tatsächlichen Schreibweise von Go-Code. Die alternative Option (b) — Ablehnung, weil "Go-Methoden nicht in Structs sind" — wäre pedantisch korrekt, würde den Aufrufer jedoch zwingen, insert_after("Cache", content) zu verwenden, wodurch das semantische Signal verloren ginge, dass es sich um eine Methodenergänzung handelt.

Verfügbare Tools

Alle Tools erfordern, dass file_path ein absoluter Pfad zu einer existierenden Datei ist.

Code-Bearbeitung — strukturell (Python, JS, TS, C, C++, Ruby, Go, Java)

Tool	Parameter	Beschreibung
`replace_function`	`file_path`, `target`, `content`	Ersetzt eine vollständige Funktionsdefinition (Signatur + Körper + Dekoratoren).
`replace_function_body`	`file_path`, `target`, `content`	Ersetzt nur den Körper einer Funktion, wobei Signatur und Dekoratoren erhalten bleiben.
`replace_signature`	`file_path`, `target`, `new_signature`	Ersetzt nur die Signatur, wobei Körper und Dekoratoren erhalten bleiben.
`prepend_to_body`	`file_path`, `target`, `content`	Fügt Inhalt am Anfang eines Funktionskörpers ein.
`append_to_body`	`file_path`, `target`, `content`	Fügt Inhalt am Ende eines Funktionskörpers ein.
`add_top_level`	`file_path`, `content`	Hängt beliebigen Inhalt auf oberster Ebene (Funktion, Klasse, Konstante, Typ-Alias) an das Ende der Datei an.
`add_method`	`file_path`, `class_target`, `content`	Fügt eine Methode am Ende eines Klassenkörpers hinzu.
`add_field`	`file_path`, `class_target`, `content`	Fügt ein Feld/Attribut/Member am Anfang eines Klassenkörpers hinzu.
`insert_before`	`file_path`, `target`, `content`	Fügt ein Geschwisterelement direkt vor einem benannten Symbol ein.
`insert_after`	`file_path`, `target`, `content`	Fügt ein Geschwisterelement direkt nach einem benannten Symbol ein.
`delete_symbol`	`file_path`, `target`	Löscht einen Funktions- oder Klassendefinitionsblock (einschließlich Dekoratoren).

Parameter & Signaturen

Tool	Parameter	Beschreibung
`add_parameter`	`file_path`, `target`, `parameter`, `position`	Fügt einen Parameter zu einer Funktionssignatur hinzu (`position`: `"start"` oder `"end"`).
`remove_parameter`	`file_path`, `target`, `parameter_name`	Entfernt einen Parameter anhand des Namens.

Importe & Includes

Tool	Parameter	Beschreibung
`add_import`	`file_path`, `import_text`	Fügt eine `import`/`from`/`#include`-Zeile hinzu. Überspringt Duplikate.
`remove_import`	`file_path`, `import_text`	Entfernt eine passende Import-Zeile.
`add_import_name`	`file_path`, `module`, `name`	Fügt einen Namen zu einem bestehenden `from <module> import a, b` hinzu. Nur Python.
`remove_import_name`	`file_path`, `module`, `name`	Entfernt einen Namen aus einem Python from-import mit mehreren Namen.

Kommentare & Docstrings

Tool	Parameter	Beschreibung
`add_comment_before`	`file_path`, `target`, `comment`	Fügt einen Kommentarblock direkt vor einem benannten Symbol ein. Funktioniert für Python/Ruby/YAML/TOML (`#`), JS/TS/C/C++/Go/Java (`//` oder `/* /`; Java Javadoc `/* */` unterstützt).
`remove_leading_comment`	`file_path`, `target`	Entfernt den zusammenhängenden Kommentarblock über einem Symbol. Erkennt sowohl Zeilenkommentare als auch C-Stil einzeilige oder mehrzeilige `/* ... */`-Blöcke.
`replace_leading_comment`	`file_path`, `target`, `new_comment`	Ersetzt den führenden Kommentarblock über einem Symbol (oder fügt einen ein, falls keiner existiert).
`replace_docstring`	`file_path`, `target`, `new_docstring`	Ersetzt oder fügt einen Python-Funktions-/Klassen-Docstring ein. Nur Python.

Dict/List-Bearbeitung (JSON, YAML, TOML und Python-Dict/List-Literale auf Modulebene)

Tool	Parameter	Beschreibung
`replace_value`	`file_path`, `

ast-editor