Dein freundlicher Kritiker für KI-erzeugten PHP Code

Was ist der MCP PHP Server und was kann der?

Wer heute mit KI-Assistenten wie Claude Code PHP-Anwendungen entwickelt, kennt vielleicht diese Situation: Die KI schlägt eine Lösung vor, Du nimmst sie an, der Code läuft. Aber dann kommen die Fragen:

• Wie steht es um die Qualität?
• Gibt es versteckte Security-Probleme?
• Hält sich der Code an etablierte Standards?

Genau hier setzt der MCP PHP Server an. Er ist im Grunde ein spezialisierter Werkzeugkasten, der direkt mit KI-Assistenten kommunizieren kann (über das sogenannte Model Context Protocol (MCP)). Das bedeutet: Während Du mit Claude Code an Deinem PHP-Projekt arbeitest, kann die KI den Code automatisch prüfen lassen, ohne dass Du zwischen verschiedenen Tools hin- und herspringen musst. Die Analyseergebnisse bleiben im Kontext, die KI kann direkt darauf reagieren und Verbesserungen vorschlagen.

Das klingt erstmal abstrakt. Lass uns das konkreter machen.

Wo das im Alltag hilft (und wo nicht)

Stell Dir vor, Du entwickelst gerade einen internen Prototypen für eine neue Idee. Die KI hat Dir eine Funktion generiert, die Kundendaten in die Datenbank schreibt. Der Code funktioniert, die Grundidee steht. Soweit so gut. Aber: Enthält die Funktion vielleicht eine SQL-Injection-Schwachstelle? Ist sie nach PSR-12-Standard formatiert? Wird Code dupliziert, den man besser in eine wiederverwendbare Methode auslagern sollte?

Normalerweise würdest Du jetzt PHPStan starten, dann Psalm für die Security-Analyse, dann PHP-CS-Fixer für die Formatierung, dann noch mal PHP_CodeSniffer für PSR-Compliance. Jedes Tool hat seine eigene Konfiguration, seine eigenen Log-Dateien, seine eigene Ausgabe. Du kopierst Fehler zwischen Tools hin und her, interpretierst Warnungen, passt Code an, startest von vorn.

Der MCP PHP Server bündelt diese Analysen in einer einheitlichen Schnittstelle. Die KI kann direkt fragen: "Wie sieht die Code-Qualität dieser Datei aus?" oder "Gibt es Security-Probleme in diesem Modul?" und bekommt strukturierte Antworten zurück, mit denen sie weiterarbeiten kann. Das spart nicht nur Zeit, sondern hält den Workflow im Fluss: Du bleibst im Gespräch mit der KI, statt manuell Tools zu orchestrieren.

Wichtig dabei: Dieses System ersetzt nicht spezialisierte Static-Analysis-Tools wie PHPStan oder RIPS. Es nutzt eigene Analyse-Logik, die auf pattern-basierter Heuristik beruht. Anders als bei PHPStan gibt es keine vollständige AST-Analyse. Das bedeutet: Für tiefgehende statische Analysen oder komplexe Dataflow-Tracking greifst Du weiterhin zu den spezialisierten Tools. Der MCP PHP Server ist eher ein erster Filter, ein schneller Qualitäts-Check, der Dir offensichtliche Probleme und Verbesserungspotenziale zeigt, direkt im KI-gestützten Entwicklungs-Workflow.

Dieses Werkzeug ist in erster Linie dafür gedacht, einem KI-System iterativ Feedback zu geben, um damit

• sauber strukturierten
• validen
• angemessen sicheren
• verständlichen

Code zu erzeugen. Für regulierte Produktionsumgebungen mit höchsten Security-Anforderungen sind die spezialisierten Analyse-Tools weiterhin unverzichtbar. Aber für iterative Prototyp-Entwicklung, schnelles Refactoring oder erste Code-Reviews im KI-Workflow ist das System sehr gut geeignet.

Was das System konkret macht

Dieser MCP Server stellt in diesem Praxis-Beispiel 17 spezialisierte Funktionen bereit, die verschiedene Aspekte von PHP-Code analysieren. Ich nutze ihn selbst. Die ursprünglich 86 Einzelfunktionen wurden konsolidiert:

• Code-Analyse: Zeilen, Kommentare, Funktionen, Klassen, Cyclomatic Complexity. Alles Metriken, die Dir zeigen, wie komplex Dein Code ist und wo vielleicht Refactoring nötig wäre. Besonders hilfreich, wenn Du Code von der KI generieren lässt und schnell einschätzen willst, ob die Komplexität im Rahmen bleibt.
• Quality-Principles: DRY (Don't Repeat Yourself), KISS (Keep It Simple), CRUD-Patterns, OOP-Compliance. Konkrete Checks: Wird Code dupliziert? Sind Funktionen zu komplex? Fehlen CRUD-Operationen? Die KI kann das als Feedback nutzen und iterativ verbessern.
• Security-Analyse: Pattern-basierte Erkennung von SQL-Injection, XSS, File-Inclusion-Schwachstellen. Das sind regex-basierte Heuristiken, also keine Garantie, dass alle Probleme gefunden werden. False Negatives sind möglich. Aber es ist ein guter erster Filter für die häufigsten Probleme bei KI-generiertem Code.
• PSR-Standards: 11 verschiedene PSR-Standards werden geprüft, von PSR-1 (Basic Coding Standard) bis PSR-18 (HTTP Client). Das hilft, Code konsistent und interoperabel zu halten, gerade wenn die KI aus verschiedenen Quellen lernt.
• Code-Formatierung: Automatische Korrektur von Tabs, Whitespace, Braces nach grundlegenden PSR-12-Regeln. Für vollständige PSR-12-Compliance nutzt Du weiterhin php-cs-fixer, aber für schnelle Korrekturen im Entwicklungs-Workflow reicht das meist.

Alle diese Analysen werden nachvollziehbar in einer Datenbank geloggt. Das heißt: Du kannst später nachsehen, welche Dateien wann analysiert wurden, wie lange die Analyse gedauert hat, ob Fehler aufgetreten sind. Das ist besonders in Teams oder regulierten Umgebungen wichtig, wo Nachvollziehbarkeit gefordert wird.

Wann setzt man das ein?

Das System ist speziell für Workflows gedacht, in denen Du mit KI-Assistenten wie Claude Code arbeitest. Die typischen Szenarien:

Beim Refactoring: Du lässt die KI Code umstrukturieren. Vor und nach dem Refactoring analysiert der Server die Code-Qualität. Hat sich der DRY-Score verbessert? Ist die Complexity gesunken? Die KI sieht die Zahlen und kann iterieren. Das ist besonders wertvoll, wenn Du nicht sicher bist, ob eine Änderung wirklich eine Verbesserung war.

Bei Code-Reviews: Die KI schlägt neuen Code vor. Bevor Du ihn annimmst, lässt Du ihn automatisch analysieren. Gibt es Security-Warnungen? PSR-Verstöße? Die KI kann direkt Fixes vorschlagen. So bekommst Du schnelles Feedback, ohne den Workflow zu unterbrechen.

Bei Legacy-Code-Modernisierung: Du arbeitest an einer alten PHP-Anwendung, die schrittweise auf moderne Standards gebracht werden soll. Der Server zeigt Dir für jede Datei den aktuellen Stand: PSR-Compliance, Code-Duplizierung, Security-Findings. So kannst Du priorisieren, welche Dateien zuerst angefasst werden sollten. Die KI hilft Dir dann gezielt bei den problematischsten Stellen.

Bei Lernprojekten: Wenn Du PHP lernst (oder mit Leuten arbeitest, die es lernen), gibt der Server konkretes, strukturiertes Feedback: "Diese Funktion ist zu komplex (Complexity: 15), CRUD-Operationen unvollständig, PSR-1-Verstöße in Zeile 42." Das ist didaktisch wertvoller als vage Hinweise und hilft, systematisch besseren Code zu schreiben.

Wo liegen die Grenzen?

Es ist mir ganz wichtig, das verständlich zu kommunizieren: Das System hat klare Limitationen, die Du kennen solltest.

Keine vollständige Static Analysis: Tools wie PHPStan bauen einen abstrakten Syntaxbaum (AST) auf und analysieren Datenflüsse durch Deinen Code. Der MCP PHP Server nutzt pattern-basierte Heuristiken, also Regex-Matches und Zeilen-Analysen. Das heißt: Komplexe Injection-Pfade über mehrere Funktionen hinweg werden nicht erkannt. Für tiefgehende Analysen brauchst Du weiterhin die spezialisierten Tools. Aber für iteratives Prototyping, schnelle Refactorings im KI-Workflow oder erste Code-Reviews ist es sehr gut geeignet, weil Du sofort im Kontext bleibst.

False Positives UND False Negatives: Bei Security-Scans findet das System offensichtliche Probleme, aber subtile Schwachstellen können durchrutschen. Etwa $_GET direkt in SQL wird erkannt. Und manchmal werden harmlose Code-Stellen als problematisch markiert. Jedes Finding solltest Du manuell verifizieren. Für Produktions-Code mit hohen Security-Anforderungen sind spezialisierte Tools wie RIPS oder SonarQube unverzichtbar. Aber für Entwicklungs-Prototypen oder initiales Code-Feedback im KI-Dialog ist das System gut geeignet.

PSR-12-Formatter: Die Formatierung deckt grundlegende Regeln ab (Tabs, Whitespace, Braces), aber nicht das vollständige PSR-12-Regelwerk. Für produktionsreife Formatierung nutzt Du php-cs-fixer. Aber für schnelle Korrekturen während der Entwicklung reicht es meist aus.

Rate Limiting: Der Server begrenzt Anfragen auf 100 pro Minute. Das schützt vor Überlastung, kann aber bei großen Batch-Analysen zum Engpass werden. Das ist eine bewusste Design-Entscheidung für den Einsatz mit einzelnen Entwicklern oder kleinen Teams, nicht für CI/CD-Pipelines mit hunderten Dateien pro Durchlauf.

Dateigröße: Maximale Dateigröße ist 5MB. Größere Dateien werden abgelehnt. Das ist eine bewusste Entscheidung zur DoS-Prävention. Es bedeutet aber: Monolithische Legacy-Dateien musst Du vor der Analyse aufteilen.

Wie das technisch funktioniert

Unter der Haube ist das ein Python-Server, der auf dem FastMCP Framework basiert. Dieses Framework implementiert das Model Context Protocol, einen Standard von Anthropic, der es KI-Modellen ermöglicht, mit externen Tools zu kommunizieren. Der Server läuft als eigenständiger Prozess, die KI schickt strukturierte Anfragen (JSON), bekommt strukturierte Antworten zurück.

Die Architektur besteht aus mehreren Schichten: MCP Protocol Layer (Kommunikation mit der KI), Core Analysis Engine (die eigentliche Code-Analyse), Analysis Modules (Quality, Security, Formatter) und PSR Standards Analyzers (11 spezialisierte Prüfer für verschiedene PSR-Standards). Dazu kommen Security-Layer: Path-Traversal-Protection (nur Dateien in /var/xyz dürfen analysiert werden), Rate Limiting (Sliding Window), File-Size-Limits, Audit-Logging.

Ein wichtiges Detail für die Performance: Der Server nutzt einen LRU-Cache (Least Recently Used), der Analyseergebnisse zwischenspeichert. Der Cache-Key basiert auf Dateipfad plus Änderungszeitpunkt. Wird die Datei geändert, invalidiert sich der Cache automatisch. In Messungen hat das eine 11,7-fache Beschleunigung bei Cache-Hits gebracht (von 1,87ms auf 0,16ms für eine Testdatei). Das macht iteratives Arbeiten deutlich flüssiger.

Was macht das anders als existierende Tools?

Der Hauptunterschied: Integration statt Isolation. PHPStan, Psalm, PHP-CS-Fixer sind exzellente Tools, aber sie leben in ihrer eigenen Welt. Du startest sie manuell, interpretierst ihre Ausgabe, passt Code an, startest neu. Der MCP PHP Server bringt das in den KI-Kontext. Die KI sieht die Analyseergebnisse, versteht sie im Zusammenhang mit Deiner Frage, schlägt Verbesserungen vor, analysiert erneut.

Dazu kommt: Einheitliches Logging für alle Operationen. Traditionelle Tools schreiben Logs in verschiedene Dateien, verschiedene Formate. Hier läuft alles über eine zentrale Datenbank-Tabelle mit strukturierten Feldern. Das ermöglicht später Trend-Analysen: "Wie hat sich die Code-Qualität in Modul X über die letzten 3 Monate entwickelt?"

Und schließlich: Framework-Agnostik. Viele Analyse-Tools sind auf bestimmte Frameworks zugeschnitten (Larastan für Laravel zum Beispiel). Dieser Server analysiert pures PHP, egal ob Du mit Laravel, Symfony, eigenen Frameworks oder legacy Code arbeitest.

Wer sollte das nutzen (und wer nicht)?

Dieses System macht Sinn, wenn Du bereits mit KI-Assistenten entwickelst und die Code-Qualität systematisch im Blick behalten willst, ohne ständig zwischen Tools zu wechseln. Es ist besonders nützlich für:

• Teams, die KI-gestützt refactoren und nachvollziehbare Qualitäts-Metriken brauchen
• Projekte in regulierten Umgebungen, wo Audit-Trails gefordert werden
• Legacy-Code-Modernisierung mit schrittweiser Qualitätsverbesserung
• Lernumgebungen, wo strukturiertes Code-Feedback wichtig ist
• Prototyp-Entwicklung, wo schnelles Feedback wichtiger ist als vollständige Analyse

Es macht weniger Sinn, wenn Du hauptsächlich manuell entwickelst (dann sind die klassischen Tools direkter), wenn Du AST-basierte Deep Analysis brauchst (dann PHPStan/Psalm), oder wenn Du vollautomatische CI/CD-Pipelines ohne KI-Interaktion aufsetzen willst (dann eher spezialisierte Scanner).

Bevor es gleich ins Detail geht

Die folgenden Kapitel dieser Dokumentation zeigen Dir im Detail, wie Du den Server installierst, konfigurierst und nutzt. Du findest konkrete Code-Beispiele, Performance-Benchmarks, Security-Konzepte und Troubleshooting-Anleitungen. Die Dokumentation ist so strukturiert, dass Du entweder gezielt nach einem Thema suchst (zum Beispiel "PSR-Standards") oder Dich schrittweise durcharbeitest.

Manchmal braucht es ein paar Iterationen, bis man versteht, wo so ein Tool hilft und wo nicht. Vielleicht probierst Du es erstmal mit einer kleineren Datei aus, lässt die KI analysieren, schaust Dir die Ergebnisse an. Wenn es passt, kannst Du das Schritt für Schritt ausweiten. Und wenn es nicht passt, dann sind die klassischen Tools vielleicht besser für Deinen Workflow geeignet ;-)

Technischer Kontext: MCP PHP Server vs. klassische Tools

Um das Ganze einzuordnen: Hier eine Gegenüberstellung, wie klassische PHP-Analyse-Ansätze funktionieren und wo dieser Server sich positioniert.

Zusammengefasst: Die klassischen Tools bieten tiefgehendere Analysen und vollständigere Abdeckung. Der MCP PHP Server bietet schnellere Integration in KI-Workflows, einheitliches Logging und einen kompakten Werkzeugkasten für die häufigsten Code-Qualitäts-Checks, ohne manuelle Tool-Orchestrierung.

Audit-Logging: Nachvollziehbarkeit statt Manipulation

Alle Operationen werden in einer Datenbank-Tabelle protokolliert. Das umfasst: Welches Tool wurde aufgerufen, auf welche Datei, war die Operation erfolgreich, wie lange hat sie gedauert, wann fand sie statt. Diese Logs sind nachvollziehbar, das heißt, Du kannst später sehen, was passiert ist. Das ist besonders wichtig, wenn Du in Teams arbeitest oder Compliance-Anforderungen erfüllen musst. Etwa ISO 27001 oder SOC 2.

Wichtig zu verstehen: "Nachvollziehbar" bedeutet nicht automatisch "manipulationssicher". Die Logs liegen in einer MariaDB-Datenbank. Wer Schreibzugriff auf diese Datenbank hat, könnte theoretisch Einträge ändern oder löschen. Manipulationsschutz hängt vom Datenbank-Hardening und Access Control ab. Es gibt keine WORM-Logs oder kryptografisch signierte Log-Einträge. WORM bedeutet Write Once, Read Many. Für höchste Sicherheitsanforderungen müsstest Du zusätzliche Maßnahmen implementieren. Etwa externe Log-Aggregation mit Signing.

Trotzdem: Für die meisten Szenarien reicht dieses Logging aus. Du kannst Trends analysieren ("Wie oft wurde Datei X in den letzten 30 Tagen analysiert?"), Performance-Probleme identifizieren ("Welche Analysen dauern am längsten?") und im Nachhinein nachvollziehen, welche Qualitäts-Checks wann durchgeführt wurden.

Performance: Caching macht den Unterschied

Ein Detail, das im Alltag spürbar wird: Der Server nutzt einen LRU-Cache (Least Recently Used), der Analyseergebnisse zwischenspeichert. Wenn Du dieselbe Datei mehrfach analysieren lässt (zum Beispiel während iterativem Refactoring), kommt das Ergebnis aus dem Cache, solange sich die Datei nicht geändert hat. In konkreten Messungen brachte das eine Beschleunigung um Faktor 11,7 (von 1,87ms auf 0,16ms für eine Testdatei).

Der Cache-Key basiert auf Dateipfad plus Änderungszeitpunkt. Mtime ist modification time. Ändert sich die Datei, ändert sich mtime, der Cache wird ungültig, eine neue Analyse startet. Das ist ein einfaches, aber robustes System. Der Cache hält maximal 100 Dateien. Bei größeren Projekten werden ältere Einträge automatisch entfernt (Least Recently Used).

Ressourcen-Verbrauch: Der Server benötigt circa 2 bis 20MB RAM. Der Verbrauch hängt ab von Cache-Füllstand und Analyse-Komplexität. Das ist bewusst sparsam gehalten, keine vollständigen ASTs im Speicher, nur Metadaten. Für die meisten Systeme ist das vernachlässigbar.

Security: Mehrschichtige Absicherung

Code-Analyse-Tools haben per Definition Zugriff auf Dein Dateisystem. Das ist ein Sicherheitsrisiko, wenn nicht sorgfältig implementiert. Der MCP PHP Server nutzt mehrere Security-Layer:

• Path-Traversal Protection: Nur Dateien in bestimmten Verzeichnissen dürfen analysiert werden (Whitelist). Symbolische Links werden aufgelöst und geprüft. Anfragen wie ../../etc/passwd werden abgelehnt.
• File-Size Limits: Maximale Dateigröße ist 5MB (konfigurierbar). Das verhindert DoS-Angriffe über extrem große Dateien, die den Server überlasten würden.
• Rate Limiting: 100 Anfragen pro 60 Sekunden (Sliding Window Algorithm). Das schützt vor absichtlicher oder versehentlicher Überlastung.
• Read-Only Analysis: Während der Analyse werden keine Dateien verändert (außer bei explizitem php_format_code() mit entsprechenden Berechtigungen).
• Sandboxed PHP Execution: PHP Syntax-Checks mit php -l laufen in separaten Prozessen, nicht im Server-Prozess selbst. Wichtig zu wissen: php -l ist NICHT vollständig sandboxed, Extensions, auto_prepend_file und Preloading werden trotz "Lint Mode" ausgeführt. Das ändert das Risikoprofil. Für maximal isolierte Umgebungen könntest Du Docker-Container nutzen.

Zusätzlich: Die Whitelist deckt nur klassische Filesystem-Pfade ab. PHP Stream-Wrapper werden nicht unterstützt und müssen separat gefiltert werden, falls Du externe Pfad-Eingaben erlaubst. Stream-Wrapper sind etwa php://, data:// oder zlib://.

Was das Ganze bringt (und was es kostet)

Technisch gesehen: Der Server spart Dir manuelle Tool-Orchestrierung, hält Analyse-Ergebnisse im KI-Kontext, ermöglicht iterative Qualitäts-Verbesserung ohne Workflow-Unterbrechung. Er loggt nachvollziehbar, cached intelligent, arbeitet framework-agnostisch.

Menschlich gesehen: Du bekommst schnelleres Feedback zu Code-Qualität, ohne zwischen Tools zu springen. Das kann frustrierend sein, wenn man gerade im Flow ist und dann in drei verschiedene Terminals schauen muss. Hier bleibt man im Gespräch mit der KI.

Organisatorisch gesehen: Teams bekommen nachvollziehbare Audit-Trails, können Trends analysieren, haben einheitliche Qualitäts-Metriken über Projekte hinweg. Das hilft bei Code-Reviews, bei Compliance-Audits, bei der Priorisierung von Refactoring-Aufgaben.

Was es kostet: Setup-Aufwand (Python-Umgebung, Datenbank-Konfiguration, MCP-Integration), Learning Curve (Du musst verstehen, wo die Grenzen liegen), gelegentliche False Positives/Negatives (die Du manuell verifizieren musst). Und: Es ist kein Ersatz für spezialisierte Tools bei kritischen Analysen.

Ob sich das lohnt, hängt von Deinem Workflow ab. Wenn Du sowieso mit KI-Assistenten entwickelst und Code-Qualität im Blick behalten willst, ist es eine sinnvolle Ergänzung. Wenn Du hauptsächlich manuell arbeitest oder bereits gut eingespielte CI/CD-Pipelines mit den klassischen Tools hast, bringt es vielleicht weniger.

Alternative Ansätze und wo dieser Server sich positioniert

Vielleicht fragst Du Dich: "Könnte ich nicht einfach die klassischen Tools direkt nutzen?" Lass uns das durchgehen.

Direkte Tool-Integration (PHPStan, Psalm per Shell)

Du könntest die KI anweisen, phpstan analyze via Shell auszuführen und den Output zu interpretieren. Das funktioniert technisch. Aber: Der Output ist textuell, nicht strukturiert. Jedes Tool hat sein eigenes Format. Die KI muss parsieren, interpretieren, viel Kontext verbrauchen. Und zwischen verschiedenen Analyse-Typen gibt es keine Integration. Kein Audit-Trail für Analyse-Operationen. Jedes Projekt braucht manuelle Tool-Installation und Konfiguration. Token-Verbrauch ist höher durch verbose Output.

Der MCP-Ansatz löst das mit strukturierten JSON-Antworten, einheitlichem Format, automatischem Audit-Trail und zentraler Installation für alle Projekte.

SaaS Code-Analyse (SonarCloud, Codacy)

Du könntest Code zu einem externen Service hochladen, Analyse in der Cloud laufen lassen. Das funktioniert für CI/CD-Pipelines gut. Aber: Datenschutz-Problematik bei proprietärem Code. Netzwerk-Latenz bei jeder Analyse. Kosten pro analysierter Zeile/Datei. Keine Integration in lokale Entwicklungs-Workflows. Limitierte Anpassbarkeit der Analyse-Regeln.

Der MCP-Ansatz läuft komplett lokal, kein Code verlässt Dein System, keine Latenzen, keine Usage-based Costs, vollständige Anpassbarkeit.

IDE-integrierte Analyse (PHPStorm Inspections)

Du könntest die IDE-native Code-Analyse während Entwicklung nutzen. PHPStorm macht das sehr gut. Aber: Keine programmierbare Schnittstelle für AI-Integration. IDE-spezifisch, nicht portabel. Keine Batch-Verarbeitung größerer Codebases. Kein zentrales Audit-Logging. Manuelle Interpretation der Ergebnisse erforderlich.

Der MCP-Ansatz bietet eine programmierbare API, ist IDE-unabhängig, unterstützt Batch-Operationen, loggt zentral und liefert strukturierte Daten direkt an die KI.

Typische Einsatzszenarien (konkret)

KI-gestützte Code Reviews

Die KI analysiert Code mit php_analyze_file(), identifiziert Quality-Issues, schlägt Verbesserungen vor, validiert Fixes via erneute Analyse. Das schließt den Feedback-Loop ohne manuellen Tool-Wechsel. Besonders wertvoll, wenn Du schnelles Feedback brauchst und nicht jedes Mal PHPStan starten willst.

Legacy Code Refactoring

Batch-Analyse via php_analyze_directory(), Priorisierung nach Quality-Scores, iteratives Refactoring mit Trend-Tracking. Du siehst objektiv, welche Dateien am dringendsten Aufmerksamkeit brauchen. Die KI hilft Dir gezielt bei den problematischsten Stellen. Nach jedem Refactoring-Schritt siehst Du, ob sich die Metriken verbessert haben.

Security Audits (erste Iteration)

php_analyze_directory_security() scannt gesamte Codebases auf SQL Injection, XSS, File Inclusion Vulnerabilities. Das ist keine vollständige Security-Analyse (dafür brauchst Du RIPS oder SonarQube), aber ein guter erster Filter. Die Ergebnisse werden geloggt für Compliance-Dokumentation. Die KI kann Dir dann helfen, die Findings zu priorisieren und Fixes vorzuschlagen.

Pre-Commit Quality Gates

Git Hooks rufen MCP Server auf, blockieren Commits bei Quality-Score unterhalb Threshold. So wird Code-Qualität auf Prozess-Ebene durchgesetzt, nicht nur durch Reviews. Das ist besonders in Teams wichtig, wo unterschiedliche Erfahrungsniveaus zusammenarbeiten.

Was sagen die Zahlen?

In produktiven Deployments haben wir folgende Erfahrungswerte gesammelt:

• Code Review Time: Circa 40 Prozent Reduktion durch automatisierte Quality-Checks vor menschlichem Review. Das bedeutet nicht, dass Reviews überflüssig werden, aber die offensichtlichen Probleme sind schon behoben, wenn ein Mensch draufschaut.
• Security Issue Detection: Pattern-basierte Erkennung für spezifische OWASP-Kategorien (SQL Injection, XSS, File Inclusion). Nicht alle OWASP Top 10, aber die häufigsten Probleme bei KI-generiertem Code.
• Token Cost: Erfahrungswert 60 bis 75 Prozent Reduktion gegenüber textueller Tool-Output-Übertragung in KI-Workflows. Das summiert sich bei intensiver Nutzung.
• Analysis Performance: Gemessene Beschleunigung Faktor 11,7 bei wiederholten Analysen durch LRU-Caching. Das ist kein Schätzwert, sondern ein dokumentierter Benchmark-Test.
• Audit Compliance: Vollständige Nachvollziehbarkeit durch Datenbank-Logging. Alle Operationen werden geloggt, sodass Audit-Trails technisch vollständig abbildbar sind.

Wichtig: Alle quantitativen Angaben basieren entweder auf dokumentierten Benchmarks (Performance-Messungen) oder Erfahrungswerten aus produktiven Deployments. Sie sind nicht als allgemeingültige Garantien zu verstehen, sondern zeigen, was unter bestimmten Bedingungen möglich ist.

Fazit

Diese MCP-Server-Implementierung adressiert spezifische Limitationen traditioneller PHP-Analyse-Tools im Kontext KI-gestützter Entwicklungs-Workflows. Die Kombination aus einheitlicher API, mehrschichtiger Security, Performance-Optimierung und nachvollziehbarem Audit-Trail macht sie für iterative Entwicklung mit KI-Assistenten gut geeignet.

Für regulierte Produktionsumgebungen mit höchsten Security- und Compliance-Anforderungen sind spezialisierte Tools (PHPStan, RIPS, SonarQube) weiterhin unverzichtbar. Aber für schnelles Prototyping, initiales Code-Feedback im KI-Dialog oder erste Refactoring-Iterationen ist das System sehr gut geeignet.

MCP als Protokoll ist noch vergleichsweise jung und nicht flächendeckend im Enterprise-Einsatz etabliert. Die Entwicklung schreitet aber voran, und es zeigt vielversprechende Ansätze für standardisierte KI-Tool-Integration. Ob sich das langfristig durchsetzt, wird die Zeit zeigen. Aktuell ist es eine praktikable Lösung für Teams, die bereits mit KI-Assistenten arbeiten und ihre Workflows optimieren wollen.

Installation

Der MCP PHP Server ist als Python-basierter Server implementiert und kann auf jedem System mit Python 3.9+ betrieben werden. Die Installation umfasst das Einrichten einer virtuellen Python-Umgebung, die Installation der Dependencies und die Konfiguration der Datenbankverbindung.

Vielleicht fragst Du Dich: Warum Python und nicht PHP selbst für einen PHP-Analyse-Server? Die Antwort liegt in der verfügbaren Infrastruktur. Python bietet mit FastMCP ein ausgereiftes Framework für MCP-Server, das die gesamte Protocol-Komplexität abnimmt. Du könntest natürlich einen MCP-Server in PHP schreiben, aber dann müsstest Du das Protocol selbst implementieren, Async-Handling von Grund auf bauen und Tool-Registration manuell managen. Mit FastMCP ist die Basis-Implementation in circa 40 Zeilen Code erledigt, sodass Du Dich auf die eigentliche Analyse-Logik konzentrieren kannst. Das ist Pragmatismus über Dogmatismus.

Systemvoraussetzungen

Die Anforderungen sind bewusst niedrig gehalten, damit das System auch auf schwächeren Maschinen laufen kann, die Du vielleicht als Entwicklungsserver nutzt. 512 MB RAM reichen aus, weil die Analysen relativ leichtgewichtig sind und keine aufwendigen AST-Parsing-Operationen durchführen. Wenn Du den Cache nutzen möchtest, solltest Du 1 GB einplanen. Der Cache hält bis zu 100 Dateien im Speicher, was bei durchschnittlich 50 KB pro Datei circa 5 MB zusätzlichen Speicherbedarf plus Overhead bedeutet.

Minimale Anforderungen

• Python: 3.9 oder neuer (getestet mit 3.11, 3.12, 3.13)
• Betriebssystem: Linux (Debian/Ubuntu bevorzugt), macOS, Windows
• Arbeitsspeicher: 512 MB RAM (1 GB empfohlen für Cache-Nutzung)
• Festplatte: 100 MB für Server + Dependencies, zusätzlich für Logs
• Netzwerk: Lokaler Zugriff ausreichend (MCP Protocol via stdio/TCP)

Optionale Komponenten

• MariaDB/MySQL: Für Audit-Logging (ki_protokoll.php_operations)
• PHP CLI: Für Syntax-Checks via php -l (beliebige Version 5.x-8.x)

Installationsmethoden

Es gibt zwei empfohlene Installationsmethoden:

Welche Methode solltest Du wählen? Wenn Du das System dauerhaft nutzen möchtest und einen stabilen Betrieb brauchst, ist das Production Setup mit systemd Service die richtige Wahl. Wenn Du hingegen nur experimentieren oder am Code selbst arbeiten möchtest, bietet sich das Development Setup in einem lokalen Verzeichnis an. Der Hauptunterschied liegt im Startverhalten: Das Production-Setup läuft automatisch nach jedem Server-Reboot neu an, während Du beim Development-Setup den Server manuell starten musst. Technisch funktionieren beide Varianten identisch.

Methode 1: Production Setup (empfohlen für Server)

Diese Methode richtet den Server in einer standardisierten Verzeichnisstruktur ein:

# 1. Verzeichnisstruktur erstellen
sudo mkdir -p /var/www/mcp/php
cd /var/www/mcp/php

# 2. Server-Dateien bereitstellen
# Dateien via Download bereitstellen und entpacken
# Verzeichnisstruktur sollte enthalten:
# - server.py, lib/, modules/, analyzers/, config/, tests/

# 3. Virtual Environment erstellen
python3 -m venv venv

# 4. Dependencies installieren
venv/bin/pip install --upgrade pip
venv/bin/pip install -r requirements.txt

# 5. Konfiguration anpassen
# config/config.json editieren (siehe Konfiguration-Abschnitt)
nano config/config.json

# 6. Permissions setzen
sudo chown -R www-data:www-data /var/www/mcp/php
sudo chmod -R 755 /var/www/mcp/php
sudo chmod 750 /var/www/mcp/php/logs  # Log-Verzeichnis restriktiver
sudo chmod 600 /var/www/mcp/php/config/config.json  # Config nur lesbar für Owner

Dependencies (requirements.txt)

Der Server benötigt folgende Python-Packages:

• fastmcp: MCP Protocol Framework (server.py:40-42)
• pymysql: MariaDB/MySQL Connector für Audit-Logging (logger.py:60-93)
• pytest: Testing Framework (für Unit Tests, optional)

Methode 2: Development Setup (für lokale Entwicklung)

Für Entwicklung und Testing kann der Server in einem beliebigen Verzeichnis installiert werden:

# 1. Server-Dateien in lokales Verzeichnis bereitstellen
cd ~/projects
mkdir mcp-php-server
cd mcp-php-server
# Dateien via Download bereitstellen und entpacken

# 2. Virtual Environment erstellen
python3 -m venv venv

# 3. Dependencies installieren
source venv/bin/activate  # Linux/macOS
# oder: venv\Scripts\activate  # Windows
pip install --upgrade pip
pip install -r requirements.txt

# 4. Development-Konfiguration erstellen
cp config/config.example.json config/config.json
# config.json editieren: Pfade anpassen

# 5. Tests ausführen (optional)
pytest tests/unit/ -v

Datenbank-Setup (optional)

Für vollständiges Audit-Logging wird eine MariaDB/MySQL-Datenbank benötigt. Dieser Schritt ist optional - der Server funktioniert auch ohne Datenbank (Logging dann nur in Dateien).

Die Frage ist: Brauchst Du das Datenbank-Logging wirklich? Das hängt von Deinem Einsatzszenario ab. Wenn Du alleine entwickelst und nur gelegentlich Analysen durchführst, reichen die Datei-Logs in den meisten Fällen völlig aus. Wenn Du hingegen im Team arbeitest, Trend-Analysen über längere Zeiträume machen möchtest oder Compliance-Anforderungen mit nachweisbaren Audit-Trails erfüllen musst, solltest Du die Datenbank-Variante wählen. Der Performance-Overhead ist minimal (ein einzelnes INSERT pro Analyse), aber Du bekommst dafür strukturierte Logs, die Du mit SQL-Queries abfragen kannst. Statt durch Textdateien zu greppen, kannst Du einfach fragen: "Zeig mir alle Analysen der letzten Woche, die Fehler produziert haben."

# 1. Datenbank und Tabelle erstellen
mysql -u root -p

CREATE DATABASE IF NOT EXISTS ki_protokoll;
USE ki_protokoll;

CREATE TABLE IF NOT EXISTS php_operations (
    id INT AUTO_INCREMENT PRIMARY KEY,
    timestamp DATETIME DEFAULT CURRENT_TIMESTAMP,
    operation VARCHAR(100) NOT NULL,
    file_path TEXT,
    user_context VARCHAR(255),
    execution_time FLOAT,
    success BOOLEAN,
    error_message TEXT,
    parameters JSON,
    result_summary TEXT,
    INDEX idx_timestamp (timestamp),
    INDEX idx_operation (operation),
    INDEX idx_success (success)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

# 2. User für MCP Server erstellen
CREATE USER IF NOT EXISTS 'mcp_db_crud'@'localhost' IDENTIFIED BY 'SICHERES_PASSWORT';
GRANT INSERT, SELECT ON ki_protokoll.php_operations TO 'mcp_db_crud'@'localhost';
FLUSH PRIVILEGES;

# 3. Credentials-Datei erstellen
# Sicherer Speicherort außerhalb von /var/www:
# sudo mkdir -p /etc/mcp
# sudo nano /etc/mcp/credentials.json
{
    "database_users": {
        "mcp_db_crud": {
            "password": "SICHERES_PASSWORT"
        }
    }
}

# Permissions setzen:
# sudo chmod 600 /etc/mcp/credentials.json
# sudo chown www-data:www-data /etc/mcp/credentials.json

Security Note: Credentials

Die Credentials-Datei enthält sensitive Daten und sollte entsprechend geschützt werden:

Diese Vorsichtsmaßnahmen mögen auf den ersten Blick paranoid wirken, aber Credentials-Management ist tatsächlich einer der häufigsten Angriffsvektoren in der Praxis. Die Empfehlung, Credentials nicht unter /var/www zu speichern, hat einen konkreten Grund: Viele Webserver haben Fehlkonfigurationen, die dazu führen können, dass JSON-Dateien direkt ausgeliefert werden. Die Berechtigung chmod 600 stellt sicher, dass ausschließlich der Owner die Datei lesen kann, nicht einmal die Gruppe hat Zugriff. Die Empfehlung von mindestens 20 Zeichen Passwortlänge basiert darauf, dass kürzere Passwörter mit moderner Hardware in vertretbarer Zeit bruteforcebar sind. Das sind keine theoretischen Risiken, sondern praktische Lessons-Learned aus tatsächlichen Security-Breaches.

• Permissions: chmod 600 credentials.json
• Owner: Nur der User, der den Server startet
• Speicherort: NICHT unter /var/www (webserver-zugänglich), besser: /etc/mcp/credentials.json oder /root/.mcp/credentials.json
• Git-Ignore: Credentials NIEMALS in Version Control committen
• Passwort-Stärke: Mindestens 20 Zeichen, zufällig generiert
• Verschlüsselung: Für höchste Sicherheit: Credentials verschlüsselt ablegen (z.B. via ansible-vault oder gpg)

Konfiguration

Die Hauptkonfiguration erfolgt über config/config.json. Hier ein minimales Beispiel:

Die Entscheidung für JSON statt YAML oder TOML hat praktische Gründe: Python und JSON arbeiten nativ zusammen, sodass kein externer Parser benötigt wird. Dazu kommt, dass JSON von praktisch jedem Tool und jeder Programmiersprache gelesen werden kann. Falls Du das System später über eine API konfigurieren möchtest, brauchst Du keinen zusätzlichen YAML-Parser im Frontend zu integrieren. Auch hier gilt: Einfachheit über zusätzliche Features.

{
    "server": {
        "name": "PHP Code Analysis Tools",
        "version": "2.0.0",
        "host": "localhost",
        "port": 11434
    },
    "security": {
        "allowed_directories": ["/var/www"],
        "max_file_size_mb": 5,
        "rate_limit_requests": 100,
        "rate_limit_window_seconds": 60
    },
    "cache": {
        "enabled": true,
        "max_size": 100
    },
    "logging": {
        "file_logging": true,
        "db_logging": true,
        "log_directory": "/var/www/mcp/php/logs",
        "log_level": "INFO"
    },
    "database": {
        "enabled": true,
        "credentials_file": "/etc/mcp/credentials.json",
        "database_name": "ki_protokoll",
        "table_name": "php_operations"
    }
}

Wichtige Konfigurationsparameter

• allowed_directories: Whitelist für Path-Traversal-Protection (security_validator.py:17-42)
• max_file_size_mb: Maximum Dateigröße für Analyse (Standard: 5MB)
• rate_limit_requests: Anzahl Requests pro Zeitfenster (Standard: 100/60s)
• cache.max_size: LRU-Cache Größe (Standard: 100 Dateien)
• db_logging: Aktiviert Datenbank-Logging (benötigt MariaDB-Setup)

Server-Start

Nach erfolgreicher Installation und Konfiguration kann der Server gestartet werden:

# Production (als Hintergrund-Prozess)
cd /var/www/mcp/php
mkdir -p logs
nohup venv/bin/python3 server.py &

# Development (mit Console-Output)
cd /var/www/mcp/php
venv/bin/python3 server.py

# Mit Logs in Datei
cd /var/www/mcp/php
mkdir -p logs
venv/bin/python3 server.py >> logs/server.log 2>&1 &

# Server-Status prüfen
ps aux | grep server.py

# Server stoppen
pkill -f "php/server.py"

Erwartete Startup-Ausgabe

PHP MCP Server (Slim) initialized successfully
20 tools available (merged from 86)
~35k tokens saved
Server ready for connections

Verifikation der Installation

Nach dem Server-Start sollten folgende Checks durchgeführt werden:

Die Verifikation der Installation ist kein optionaler Schritt. Viele Installation-Guides enden mit der Anweisung "starte den Server und hoffe das Beste", was keine professionelle Herangehensweise ist. Du solltest systematisch prüfen, dass jede Komponente ordnungsgemäß funktioniert, bevor Du produktiv mit dem System arbeitest. Andernfalls wirst Du später Zeit damit verschwenden, mysteriöse Fehler zu debuggen, die in Wahrheit auf Installations-Probleme zurückzuführen sind. Die vier Checks, die Du gleich siehst, decken die kritischen Pfade ab: Der Prozess läuft, das Logging funktioniert, die Datenbank ist erreichbar, und die Analyse liefert tatsächlich Ergebnisse.

# 1. Server-Prozess läuft
ps aux | grep server.py
# Erwartung: Ein Python-Prozess mit server.py

# 2. Logs prüfen
tail -f /var/www/mcp/php/logs/php_mcp.log
# Erwartung: Keine ERROR-Meldungen

# 3. Datenbank-Verbindung testen (falls aktiviert)
# Via MCP Datenbank Server:
mcp__datenbank__db_query \
    database="ki_protokoll" \
    query="SELECT COUNT(*) FROM php_operations" \
    user_type="mcp_db_crud"

# 4. Test-Datei analysieren
# Erstelle Test-Datei mit printf:
printf '<?php\nclass TestClass {\n    public function testMethod() {\n        return "Hello MCP";\n    }\n}\n' > /tmp/test.php

# Analysiere via MCP Tool (im KI-Assistenten):
# mcp__php__php_analyze_file /tmp/test.php

Erfolgreiche Installation

Die Installation ist erfolgreich, wenn:

• Server-Prozess läuft ohne Fehler
• Logs zeigen "Server ready for connections"
• Datenbank-Tabelle php_operations existiert (falls DB aktiviert)
• Test-Analyse liefert Ergebnisse zurück
• Alle 17 Tools über MCP verfügbar sind

Systemd Service (Production)

Für Production-Umgebungen empfiehlt sich ein systemd Service für automatischen Start:

Systemd hat zwar bei manchen Leuten einen schlechten Ruf, aber für diese Art von Service-Management ist es tatsächlich sehr gut geeignet: Es bietet automatischen Start nach einem Server-Reboot, automatischen Restart bei Crashes, integriertes Logging über journald und die Möglichkeit, Resource-Limits zu definieren. Die Alternative wäre ein cronjob mit @reboot oder ein klassisches Init-Script, aber das bedeutet mehr Implementierungsaufwand für deutlich weniger Features. Es ist in den meisten Fällen sinnvoller, existierende, bewährte Tools zu nutzen, statt eigene Lösungen zu bauen.

# 1. Service-Datei erstellen
sudo nano /etc/systemd/system/mcp-php-server.service

# 2. Service-Konfiguration
[Unit]
Description=MCP PHP Server - Code Analysis Tools
After=network.target mariadb.service

[Service]
Type=simple
User=www-data
Group=www-data
WorkingDirectory=/var/www/mcp/php
ExecStart=/var/www/mcp/php/venv/bin/python3 /var/www/mcp/php/server.py
Restart=always
RestartSec=10
StandardOutput=append:/var/www/mcp/php/logs/server.log
StandardError=append:/var/www/mcp/php/logs/server-error.log

Environment="PYTHONUNBUFFERED=1"
Environment="HOME=/var/www/mcp/php"

[Install]
WantedBy=multi-user.target

# 3. Service aktivieren und starten
sudo systemctl daemon-reload
sudo systemctl enable mcp-php-server
sudo systemctl start mcp-php-server

# 4. Status prüfen
sudo systemctl status mcp-php-server

# 5. Logs verfolgen
sudo journalctl -u mcp-php-server -f

Häufige Installationsprobleme

Im Folgenden findest Du die drei häufigsten Installationsprobleme mit ihren Ursachen und Lösungen. Diese Liste ist nicht vollständig, deckt aber vermutlich circa 80 Prozent der typischen Installations-Fehler ab. Falls Du ein anderes Problem hast, solltest Du in die Logs schauen (logs/php_mcp.log und journalctl -u mcp-php-server), dort steht in den meisten Fällen genau beschrieben, was schiefgelaufen ist.

Problem: ModuleNotFoundError: No module named 'fastmcp'

Ursache: Dependencies nicht installiert oder falsche Python-Umgebung

Lösung:

cd /var/www/mcp/php
venv/bin/pip install --upgrade pip
venv/bin/pip install -r requirements.txt
# Server mit venv/bin/python3 starten (nicht system python3!)

Problem: Database Connection Failed

Ursache: Credentials falsch oder Datenbank nicht erreichbar

Lösung:

# 1. Credentials prüfen
sudo cat /etc/mcp/credentials.json

# 2. Datenbankverbindung testen
mysql -u mcp_db_crud -p ki_protokoll

# 3. Falls DB-Logging optional: In config.json deaktivieren
"database": { "enabled": false }

Problem: Permission Denied beim Server-Start

Ursache: Falsche Dateirechte

Lösung:

sudo chown -R www-data:www-data /var/www/mcp/php
sudo chmod -R 755 /var/www/mcp/php
sudo chmod 644 /var/www/mcp/php/config/config.json

Updates

Updates werden durch Bereitstellen neuer Dateien und Aktualisierung der Dependencies durchgeführt:

Updates sind immer mit einem gewissen Risiko verbunden, weswegen das Backup an erster Stelle steht und nicht als optionale Randnotiz behandelt werden sollte. Du solltest sowohl das komplette Verzeichnis als auch separat die Config-Dateien sichern, weil neue Versionen möglicherweise andere Konfigurations-Strukturen erwarten. Nach dem Update ist es wichtig, die Tests durchlaufen zu lassen, um Regressionen frühzeitig zu erkennen. Falls dabei etwas schiefgeht, kannst Du das Backup entpacken und bist innerhalb von circa 30 Sekunden wieder im funktionsfähigen Zustand. Das bedeutet: kein Stress, kein Datenverlust.

# Update-Prozess
cd /var/www/mcp/php

# 1. Server stoppen
sudo systemctl stop mcp-php-server

# 2. Backup erstellen
tar -czf ~/mcp-php-backup-$(date +%Y%m%d).tar.gz .

# 3. Config-Dateien sichern
cp config/config.json ~/config.json.backup
cp /etc/mcp/credentials.json ~/credentials.json.backup

# 4. Neue Dateien bereitstellen
# Neue Server-Dateien via Download bereitstellen
# Alte Dateien überschreiben (außer config/)

# 5. Config-Dateien wiederherstellen
cp ~/config.json.backup config/config.json
sudo cp ~/credentials.json.backup /etc/mcp/credentials.json
sudo chmod 600 /etc/mcp/credentials.json
sudo chown www-data:www-data /etc/mcp/credentials.json

# 6. Dependencies aktualisieren
venv/bin/pip install -r requirements.txt --upgrade

# 7. Server starten
sudo systemctl start mcp-php-server

# 8. Status prüfen
sudo systemctl status mcp-php-server
tail -f logs/php_mcp.log

Update-Checklist

• Backup erstellen: Vor jedem Update komplettes Verzeichnis sichern
• Config sichern: config.json und credentials.json vor Update kopieren
• Server stoppen: Vor Update Server stoppen
• Neue Dateien: Via Download bereitstellen und entpacken
• Config wiederherstellen: Gesicherte Configs zurückkopieren
• Dependencies prüfen: requirements.txt auf neue Packages prüfen
• Tests laufen lassen: pytest tests/unit/ -v nach Update
• Logs überwachen: Nach Update Logs auf Fehler prüfen