Altium mit MCP steuern: Was heute wirklich funktioniert

Elektronik Agentic Engineering

KI-Agenten wie Claude™ können heute über das Model Context Protocol (MCP)™ mit Werkzeugen sprechen. Für Software-Werkzeuge ist das Alltag geworden, selbst 3D-Programme wie Blender® haben mittlerweile eine offizielle MCP-Schnittstelle (ab Blender 3.0 als Beta, mittlerweile produktiv mit Blender 5.1), was in der Praxis wirklich toll ist. Für ECAD dagegen nicht: Altium Designer® hat unseres Wissens keine offizielle MCP-Schnittstelle für die Automatisierung. Dieser Artikel fasst zusammen, was wir bei swissEmbedded in mehreren Projekten gelernt haben, und welche drei Wege in der Praxis funktionieren.

Der offizielle Weg ist tot

Altium hatte ein “Altium Developer Program” mit SDK-Zugang. Unsere Erfahrung damit ist ernüchternd: Anfragen an die dafür vorgesehene Adresse DXPDeveloper@altium.com bleiben unbeantwortet, wir haben zweimal geschrieben. Kein SDK-Zugang, keine Rückmeldung, keine öffentliche Dokumentation zum Programm-Status. Wer seine Automatisierung auf diesem Weg plant, plant ins Leere. Man muss es so deutlich sagen: das Programm ist wohl faktisch eingestellt, so zumindest unsere Vermutung. Als Seitenhieb sei erlaubt: wer im Jahr 2026 seine Automatisierungs-Schnittstelle noch auf DelphiScript aufbaut, wird sie auch nicht über Nacht auf MCP umstellen. Aber vielleicht antworten sie ja noch.

Das ist kein Grund aufzugeben. Es gibt zwei tragfähige technische Wege in Altium hinein, und kombiniert ergeben sie einen vollwertigen MCP-Server.

Weg 1: Die Scripting-Mailbox

Altium Designer bringt seit jeher eine eingebaute Scripting-Umgebung mit (DelphiScript, mit Zugriff auf die komplette Schematic- und PCB-Objektwelt inklusive ECO-Mechanik). Sie ist interaktiv gedacht, aber sie kann Dateien lesen und schreiben. Genau darauf baut die Mailbox-Architektur, wie sie zum Beispiel das Open-Source-Projekt coffeenmusic/altium-mcp umsetzt:

Vorteile: volle API-Mächtigkeit innerhalb von Altium, inklusive allem, was zwingend die laufende Applikation braucht. Nachteile: Altium muss laufen, es gibt genau eine Instanz, und Fehlerbehandlung über eine Datei-Mailbox verlangt Disziplin (Timeouts, Job-IDs, saubere Statusdateien). Wir haben diesen Pfad validiert, er trägt.

Weg 2: Direkt ins Dateiformat mit AltiumSharp

Der zweite Weg kommt ganz ohne laufendes Altium aus: SchDoc, PcbDoc, SchLib und PcbLib sind OLE-Compound-Dateien mit einem gut rekonstruierten Binärformat. Die Open-Source-Bibliothek AltiumSharp liest und schreibt diese Formate headless.

Was damit in der Praxis geht, alles selbst im Einsatz:

Die Grenze dieses Wegs: alles, was zwingend Altiums eigene Engine braucht (interaktives Routing, ECO in ein bestehendes PCB, Ausgabejobs), bleibt aussen vor.

Weg 3: Beide Wege kombinieren

Die beiden Wege ergänzen sich exakt dort, wo der jeweils andere aufhört. Erst die Kombination beider ist wirklich sinnvoll. In unseren Projekten kombinieren wir coffeenmusic/altium-mcp für alles, was zwingend die laufende Altium-Instanz braucht, mit AltiumSharp für alle headless Lese-, Schreib- und Verifikations-Schritte. Aus Sicht des Agenten sieht das aus wie ein einheitliches MCP-Toolset.

Damit werden Arbeitsabläufe möglich, die vorher Tage gekostet haben: ein Agent liest die bestehende Firmenbibliothek, übernimmt bewährte Device-Sheets unverändert, generiert die projektspezifischen Blätter nach Architektur-Vorgabe, verifiziert jede Verbindung maschinell und liefert Renderings fürs Review, in Stunden, mit Prüfprotokoll.

Was wir gelernt haben

  1. Verifikation ist nicht optional. Generierte Schemata ohne maschinellen Soll-Ist-Vergleich der Netzliste sind ein Risiko, kein Fortschritt. Der Solver der Bibliothek macht den Vergleich billig.
  2. Bibliotheken sind read-only. Der Generator liest Firmen-Libs, schreibt sie aber nie. Neue Teile entstehen in eigenen Dateien.
  3. Round-Trip testen. Wer Binärformate schreibt, liest jede erzeugte Datei sofort zurück und vergleicht, jede Abweichung ist ein Bug, bevor Altium sie je sieht.
  4. Nicht auf den Hersteller warten. Ein totes Developer-Programm ist ärgerlich, aber kein Blocker. Dateiformat plus Scripting decken zusammen mehr ab, als das SDK je öffentlich angeboten hat.
  5. PDF taugt als Vorlage. Selbst ein Corel-Diagramm aus dem Jahr 2008, aus einem PDF gezogen, lässt sich in ein neues Schema drücken. Wenn kein sauberes Ursprungsformat mehr existiert, ist das PDF ein pragmatischer Ausgangspunkt. Aber Achtung: ein Dreck auf der alten Kopie wird schnell mal zum Netzknoten.
  6. Ästhetik bleibt Handarbeit. Über eine schöne Darstellung im Schema kann man lange streiten. Der MCP zieht auch mal eine Linie über andere Netze und merkt es nicht. Es ist eine Arbeitserleichterung, aber sicher nicht das Tool, bei dem per Knopfdruck die Gerber-Files rauskommen und fertig ist die Leiterplatte.
  7. Vertrauen ist gut, Kontrolle ist besser. Bei Software kostet eine Iteration nicht viel. Bei Hardware kostet sie sehr viel. Darum gehört jedes generierte Ergebnis bis ins Detail gereviewt (inklusive Footprints), bevor es in Richtung Fertigung geht.

Referenzen

Open-Source-Grundlage der beschriebenen Werkzeugkette:

Der im Titelbild gezeigte Schema-Ausschnitt ist ein Hot-Swap-Controller nach Texas Instruments LM5066I:

Schlüsselwörter: Altium Designer, AltiumSharp, coffeenmusic altium-mcp, Model Context Protocol, Altium mit KI automatisieren, PCB Design Automatisierung, Netzlisten-Verifikation, ECAD Beratung, DelphiScript, Embedded Consulting Schweiz, swissEmbedded Firmware Entwicklung Zürich

Altium automatisieren, Schemata generieren, PCB-Reviews beschleunigen? Wir bringen bestehende MCP-Bausteine, headless AltiumSharp und maschinelle Netzlisten-Verifikation in eure Altium-Toolchain. Aus Architektur-Vorgabe wird ein verifiziertes Schema mit Review-Rendering, reproduzierbar und diffbar.

Kontaktieren Sie uns →