Personio MCP-Server

Was ist ein MCP-Server für Personio?

Ein MCP-Server für Personio verbindet KI-Agenten über das offene Model Context Protocol mit Ihrer Personio-Instanz. Das Modell kann dann standardisiert auf die Personio Public API zugreifen, Mitarbeitendendaten lesen, Bewerbungen verarbeiten, Abwesenheiten abfragen oder Onboarding-Listen prüfen — alles im Rahmen klar definierter Tools und Berechtigungen.

HR-Daten sind besonders sensibel — Gehälter, Krankheitstage, Bewerbungsstatus. Genau deshalb ist MCP hier so wertvoll: Der Agent bekommt nicht Vollzugriff auf alle Mitarbeiterdaten, sondern nur die Felder und Operationen, die der jeweilige Use Case wirklich braucht. Recruiting-Agent sieht keine Krankheitsdaten. Reporting-Agent sieht keine Bewerber-Namen.

Personio bietet eine moderne REST-API mit OAuth/Bearer-Token-Authentifizierung, sauber dokumentiert. Das macht MCP-Integrationen vergleichsweise zügig — und besonders interessant für HR-Teams, die längst über das „Excel-Listen-pflegen" hinaus sein wollen.

Use Cases: Was kann ein Personio-MCP-Server konkret?

1. Bewerber-Pre-Screening Eingehende Bewerbungen werden vom Agenten gegen die Stellen-Anforderungen geprüft: Erfahrungsjahre, Stack, Standort, Mindestgehalt. Der Agent schlägt Bewertung („interview" / „auf Reserve" / „nicht passend") vor, die Recruiterin bestätigt.
2. Onboarding-Workflows Neue Mitarbeiterin startet in 4 Wochen? Der Agent prüft Onboarding-Checkliste in Personio, erkennt offene Punkte (Hardware-Bestellung, Zugänge, Begrüßungsmail), erstellt Erinnerungen für die zuständigen Personen.
3. Abwesenheits- und Kapazitätsplanung „Wer ist nächste Woche in der Entwicklung anwesend?" — Der Agent liefert die Antwort aus Personio, mit Hinweis auf Urlaubsanträge, die noch nicht freigegeben sind.
4. Multiposting-Sync In Kombination mit Recruiting-Tools (Talention, jobs.de, Stepstone-Multiposter): Stelle in Personio anlegen, Agent verteilt sie auf die richtigen Kanäle, Bewerbungen fließen über Personio zurück.
5. HR-Reports auf Knopfdruck Fluktuation, Time-to-Hire, offene Stellen je Abteilung — der Agent baut die Reports aus Personio-Daten, mit Visualisierung oder als sauberer Text-Abstract.
6. Mitarbeiter-Self-Service mit Eskalationsweg Mitarbeitende fragen interne FAQs („Wie viel Urlaub habe ich noch?", „Wer ist mein Ansprechpartner für IT?") — der Agent antwortet aus Personio, mit klarer Eskalation an HR, sobald es sensibel wird.

So funktioniert die Integration

Architektur:

KI-Agent ↔ MCP-Server (Ihr EU-Host) ↔ Personio Public API (OAuth/Bearer, REST/JSON)

Konkrete Schritte:

• API-Zugang & Scopes: Personio verlangt explizite Scope-Definition pro Token (Employees, Recruiting, Attendances etc.). Wir setzen Scope minimal pro Use Case.
• Tool-Definitionen: Beispiel-Tools: list_open_positions, get_applicant_by_id, update_applicant_stage, get_employee_absences. Jede mit JSON-Schema.
• Datenminimierung: Der Agent erhält nur die Felder, die der Use Case erlaubt — Gehaltsdaten standardmäßig ausgeschlossen, sofern nicht explizit Teil eines Use Cases (z. B. Salary-Benchmarks).
• Write-Operations & Freigabe: Statuswechsel im Recruiting sind in vielen Setups direkt OK; Stammdatenänderungen erfordern Freigabe.
• Webhooks-Anbindung: Optional — bei neuen Bewerbungen oder Stammdatenänderungen kann der Agent reaktiv aktiv werden, statt zyklisch zu pollen.

DSGVO, Hosting & Sicherheit

HR-Daten unterliegen besonderem Schutz. Unser Standard für Personio-MCP:

• EU-Hosting für den MCP-Server, kein US-Edge.
• Scope-minimaler Token pro Use Case, regelmäßig rotiert.
• Datenminimierung: Auch innerhalb erlaubter Scopes filtern wir Felder weg, die der konkrete Use Case nicht braucht.
• AVV mit KI-Anbieter, EU-Datenresidenz (Claude über AWS Bedrock EU, Azure OpenAI Germany etc.).
• Logging: Jeder Tool-Call ist mit Zeitstempel, betroffener Person und Mitarbeiter dokumentiert — Auskunftsanträge nach DSGVO sind sauber bedienbar.
• Betriebsrat-Einbindung: Wir liefern eine Vorlage zur Information / Mitbestimmung — wichtig in Unternehmen mit BR.

Was kostet das?

• BAFA-Förderung auf Beratungs- und Konzeptionsanteile, Berater-ID 225369. Mehr: BAFA-Förderung für KI-Beratung.
• Use Case-orientiertes Vorgehen: Erst Recruiting oder Onboarding produktiv — dann Erweiterung.
• Erste Erfolge in 3–4 Wochen realistisch.

Claude mit Personio verbinden: So läuft es ab

Die häufigste Frage aus HR-Teams im Erstgespräch: „Kann ich Claude direkt mit Personio verbinden?" Die kurze Antwort: Ja, über einen MCP-Server als Brücke. Claude selbst spricht kein Personio, aber Claude spricht MCP. Der Ablauf in fünf Schritten:

1. Zugang & Scopes klären: Personio-Token mit genau den nötigen Scopes (Recruiting, Employees, Attendances), erstellt einmalig durch einen Admin.
2. MCP-Server aufsetzen: auf einem EU-Server, mit genau den Tools, die Sie brauchen: offene Stellen lesen, Bewerber abrufen, Recruiting-Status setzen, Abwesenheiten prüfen.
3. Claude anbinden: Der MCP-Server wird in Claude (Desktop, Team oder API) als Connector hinterlegt. Ab dann sieht Claude die Personio-Funktionen wie eingebaute Werkzeuge.
4. Leitplanken & Datenschutz setzen: Gehaltsdaten standardmäßig aus, Schreibrechte nur wo nötig, Freigabe für Stammdatenänderungen, Audit-Log für jede Aktion, Betriebsrat eingebunden.
5. Testlauf mit echten Aufgaben: zwei Wochen Parallelbetrieb an einem Use Case, etwa der Vorqualifizierung neuer Bewerbungen, danach Feinschliff der Tool-Beschreibungen und Prompts.

Das Gleiche funktioniert mit GPT, Gemini oder Copilot: MCP ist modellunabhängig, der Server bleibt derselbe.

Häufige Stolperfallen aus der Praxis

Die Grundintegration ist schnell gebaut. Alltagstauglich wird sie erst, wenn diese Punkte gelöst sind:

• Rate-Limits: Die Personio-API drosselt Anfragen. Massenabfragen, etwa alle Bewerber einer Kampagne, brauchen eine Warteschlange mit Wiederholungslogik, sonst brechen Läufe mittendrin ab.
• Scope-Fallen: Ein zu breiter Token gibt dem Agenten Zugriff auf Gehalts- und Stammdaten, die der Use Case nicht braucht. Scopes werden pro Use Case minimal gesetzt und regelmäßig rotiert.
• Sensible HR-Daten: Bewerber- und Beschäftigtendaten sind besonders geschützt. Der Agent erhält nur die Felder, die der jeweilige Use Case erlaubt, jeder Zugriff wird dokumentiert.
• Stammdaten gegen Recruiting: Statuswechsel im Recruiting sind meist unkritisch, Änderungen an Stammdaten erfordern menschliche Freigabe, sonst entstehen stille Fehler in der Personalakte.
• Betriebsrat & Mitbestimmung: In Unternehmen mit Betriebsrat gehört die Information oder Mitbestimmung an den Anfang, nicht ans Ende, sonst steht das Projekt später still.

Genau diese Punkte unterscheiden ein Wochenend-Skript von einem System, dem Sie Ihre HR-Daten anvertrauen können.

Häufige Fragen

Welche Personio-API nutzt der MCP-Server?

Die offizielle Personio Public API (REST/JSON, OAuth/Bearer-Token), unterteilt nach Scope-Bereichen (Employees, Recruiting, Attendances etc.).

Wie wird mit Gehaltsdaten umgegangen?

Standardmäßig sind Gehaltsdaten vom Tool-Zugriff ausgeschlossen. Wenn ein Use Case sie benötigt (z. B. Salary-Benchmarks), erfolgt das nur mit expliziter Freigabe und enger Datenminimierung.

Kann der Agent Bewerbungsstatus ändern?

Ja, das ist einer der häufigsten Use Cases. In den meisten Setups ist das ohne Vier-Augen-Prinzip in Ordnung, weil der Statuswechsel reversibel ist.

Müssen wir den Betriebsrat einbinden?

Wir empfehlen das ausdrücklich. Wir liefern eine Vorlage zur Information / Mitbestimmung, die in den meisten Fällen ausreicht — abhängig von Umfang und BR-Vereinbarungen.

Ist das DSGVO-konform?

Ja: MCP-Server in EU, scope-minimaler Token, Feldfilterung, AVV mit KI-Anbieter in EU-Datenresidenz, vollständiges Logging.

Funktioniert das mit Personio-Webhooks?

Ja. Optional kann der MCP-Server reaktiv auf neue Bewerbungen oder Änderungen reagieren — etwa Pre-Screening automatisch starten.

Welche KI-Modelle werden unterstützt?

Alle MCP-kompatiblen: Anthropic Claude, OpenAI GPT, Google Gemini, Microsoft Copilot.

BAFA-förderfähig?

Ja, Weber Media ist BAFA-zugelassener Berater (ID 225369), Beratungs- und Konzeptionsanteile sind förderfähig.