MCP · 12 Min.
MCP für CRM: Wie KI-Agenten Salesforce, HubSpot und interne Sales-Daten sicher nutzen
CRM-Agenten werden erst stark, wenn sie Daten lesen und Aktionen vorbereiten können. MCP kann helfen, wenn Rechte sauber designt sind.
SYSTEMS Grafik zu MCP CRM Integration: Context -> Tools -> Control. Fokus: Wie Unternehmen MCP nutzen, um CRM-Daten für KI-Agenten sicher verfügbar zu machen.
Kurzfassung
CRM-Agenten brauchen Zugriff auf Kontakte, Firmen, Aktivitäten und Pipeline-Kontext. MCP kann Tool-Zugriff standardisieren, wenn Rechte eng bleiben. Schreibende Aktionen sollten spät und mit Review kommen.
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknüpfe es mit den nächsten Architekturentscheidungen.
Warum CRM-Daten zentral sind Sales AI ohne CRM-Kontext bleibt oberflächlich. Ein Agent muss wissen, wer der Kunde ist, was passiert ist, welche Nächste Schritte offen sind und welche Signale wichtig sind.
CRM-Daten sind deshalb Kernkontext.
Stand Mai 2026: MCP ist Zugriffsschicht, nicht CRM-Magie OpenAI beschreibt Remote MCP Server und Connectors als Möglichkeit, Modelle mit externen Services zu verbinden. Die Doku warnt aber klar vor Prompt Injection , sensiblen Daten, Drittservern und unerwarteten Tool-Änderungen. MCP Security Best Practices nennen unter anderem Token Passthrough, Confused Deputy und Scope-Minimierung als zentrale Themen.
Für CRM heisst das: MCP löst nicht automatisch Salesforce-, HubSpot- oder interne Rechte. Es macht Toolzugriff modellfähig. Die Rechte, Datenmodelle, OAuth-Scopes, Audit-Logs und Freigaben müssen trotzdem sauber entworfen werden. Autorisierung ist in MCP nicht gleichbedeutend mit Least Privilege; sie ist der Startpunkt für Scope-Design.
Aktuell wichtig: OpenAI unterstützt Remote MCP mit `allowed_tools`, OAuth-`authorization` und `require_approval`. Anthropic bietet Remote-MCP-Zugriff in der Messages API mit Beta-Header. HubSpot dokumentiert einen Remote-MCP-Server mit PKCE und weist darauf hin, dass Aktionen bestehende HubSpot-Berechtigungen respektieren, während sich Scopes mit Tool-Änderungen verändern können. Salesforce dokumentiert ebenfalls MCP-Server für Agentforce und Developer-Workflows. Das ist ein starkes Signal für MCP im CRM-Stack, aber kein Freibrief für unkontrollierte Tool-Anzahl.
MCP als Zugriffsschicht MCP kann helfen, CRM-Funktionen strukturiert bereitzustellen: Suche, Kontakt lesen, Aktivität zusammenfassen, Aufgabe vorbereiten, Update vorschlagen.
Wichtig ist, Tools klein zu halten.
Ein gutes CRM-MCP-Design trennt:
Ein schlechtes Design ist ein Tool wie `crm_admin_action`. Das ist für Agenten bequem und für Sales-Governance schlecht.
`search_contacts`: findet Kandidaten mit minimalen Feldern. `fetch_contact_summary`: holt nur freigegebene Zusammenfassung. `fetch_deal_context`: liefert Deal-Status, nächste Schritte und Owner. `draft_follow_up`: erstellt Vorschlag, sendet aber nicht. `create_task`: schreibt nur erlaubte Task-Felder. `update_deal_stage`: bleibt hinter Approval. `log_note`: schreibt nur mit Quelle und Autor. Salesforce und HubSpot brauchen eigene Datenverträge Salesforce nutzt Connected Apps und OAuth-Scopes, um Zugriff auf REST-Ressourcen zu steuern. HubSpot beschreibt CRM-Objekte wie Kontakte, Companies, Deals, Tickets, Properties, Associations, Pipelines und Search. Beide Systeme haben eigene Limits, Rechte und Datenmodelle.
Ein MCP-Server darf diese Konzepte nicht plattdrücken. Er braucht einen Datenvertrag:
CRM-Agenten scheitern selten an der API. Sie scheitern an unklaren Sales-Regeln.
Welche Objekte sind sichtbar? Welche Properties dürfen an Modelle gehen? Welche Associations sind relevant? Welche Pipeline-Felder sind read-only? Welche Felder sind personenbezogen oder vertraulich? Welche Updates brauchen Owner- oder Manager-Freigabe? Welche API-Limits und Rate-Limits gelten? Welche OAuth-Scopes sind wirklich nötig? Welche Tool-Liste bleibt bewusst klein genug für stabile Auswahl? Rechte und Audit Ein Agent sollte nicht blind Deals verschieben oder Kontakte verändern. Jede Schreibaktion braucht klare Bedingungen und Logs.
Read-only und Draft-first sind gute Startmodi.
Startmodi:
Audit braucht mindestens: Agent, User, CRM-Objekt, Tool, Input-Felder, Output, Zeit, Entscheidung, Approval, Resultat und Fehler.
Read-only: suchen, lesen, zusammenfassen. Draft-first: Follow-up, Task, Notiz oder Deal-Update vorbereiten. Assisted write: Mensch bestätigt die konkrete Änderung. Policy write: nur enge, reversible Aktionen ohne Kundenauswirkung. Restricted no-go: Deal Stage, Preis, Contract, Opt-out, Consent und personenbezogene Löschungen nie autonom. Prompt Injection im CRM CRM-Felder enthalten untrusted Content: E-Mails, Notizen, Webformulare, Call-Transkripte, externe Firmendaten. Ein Kontaktfeld kann eine Anweisung enthalten, die den Agenten manipulieren soll.
Controls:
MCP macht CRM-Agenten leistungsfähig. Genau deshalb muss es als Sicherheitsgrenze behandelt werden.
CRM-Inhalte als Daten behandeln, nicht als Instruktion. Tool-Beschreibungen versionieren und reviewen. Schreibtools nie direkt aus untrusted Text auslösen. Daten vor Modellkontext minimieren. sensible Felder maskieren oder nur aggregiert geben. Tool Calls loggen und stichprobenartig reviewen. Evals für CRM-MCP Vor Produktivbetrieb testen:
Ein CRM-Agent ohne Evals ist eine Demo mit Kundendaten.
findet der Agent den richtigen Kontakt statt eines Namensvetters? nutzt er Search vor Fetch? liest er nur erlaubte Properties? erkennt er Opt-out, Consent und Do-not-contact? bleibt Deal-Stage-Änderung hinter Approval? erstellt er Notizen mit Quelle statt Behauptung? stoppt er bei Prompt Injection in CRM-Notizen? respektiert er Rate-Limits und Fehlercodes? Der SYSTEMS-Blick Wir bauen MCP für CRM als sichere Sales-AI-Schicht. Der Agent bekommt genau die Daten und Aktionen, die er für bessere Pipeline-Arbeit braucht.
So entsteht Wirkung ohne unkontrollierten CRM-Zugriff: Sales-Kontext, enge Tools, klare OAuth-/Rollen-Grenzen, Draft-first-Aktionen, Audit und Regressionstests.
