MCP in der Praxis: Ein Vertriebsteam bekommt seinen eigenen KI-Zugang zum CRM

In Teil 4 dieser Serie haben wir beschrieben, warum Unternehmen eigene MCP-Server bauen sollten. Dieser Artikel macht es konkret: Ein Vertriebsteam, ein CRM-System, ein MCP-Server – und die Frage, was es wirklich braucht, damit das in der Praxis funktioniert.

Das Szenario

Ein mittelständisches Unternehmen mit 15 Vertriebsmitarbeitern nutzt ein CRM-System (HubSpot, Pipedrive, Salesforce – das Prinzip ist übertragbar). Der Alltag sieht so aus:

Neue Kontakte manuell anlegen, Felder ausfüllen, Duplikate prüfen
Angebote nach Word-Vorlage zusammenstellen, Preise nachschlagen, PDF erzeugen
Wöchentliche Pipeline-Reports aus dem CRM exportieren, in Slides aufbereiten, per Mail verschicken

Jeder dieser Schritte ist Routine. Keiner ist kompliziert. Aber sie kosten Zeit: Kontakte pflegen, Angebote erstellen, Reports exportieren. Bei 15 Vertriebsmitarbeitern summiert sich das schnell auf mehrere Stunden pro Woche – für Aufgaben, die keine eigentliche Vertriebsarbeit sind.

Ein MCP-Server kann diese drei Szenarien abdecken, ohne das CRM zu ersetzen oder die bestehenden Prozesse umzuwerfen.

Dieser Artikel zeigt drei Dinge:

Welche Tools ein CRM-MCP wirklich braucht
Wie der Server intern aufgebaut ist
Welche Infrastruktur für den produktiven Betrieb notwendig ist

Was der MCP-Server können soll

Bevor Code geschrieben wird, steht die Frage: Welche Operationen braucht der Agent tatsächlich? Nicht alles, was das CRM kann – sondern das, was im Alltag wiederholt vorkommt.

In MCP werden Funktionen als Tools definiert. Der Agent kann diese Tools aufrufen, wenn er eine Aufgabe lösen will – ähnlich wie API-Endpunkte, aber mit klar beschriebenem Schema.

Tool 1: Kontakt anlegen und pflegen

Zweck: Neue Leads aus verschiedenen Quellen (E-Mail, Telefonat, Messe-Scan) strukturiert ins CRM übernehmen.

Operationen:

create_contact – Kontakt anlegen mit Firma, Position, Kontaktdaten, Quelle
find_contact – Bestehende Kontakte suchen (Duplikat-Prüfung vor Anlage)
update_contact – Felder aktualisieren (z.B. neue Telefonnummer, Status-Wechsel)
add_note – Gesprächsnotiz an Kontakt anhängen

Datenfluss:

Feld	Typ	Quelle	Typische Grösse
Name, Firma, Position	String	Agent-Input (aus E-Mail, Telefonat)	Einzelne Felder, KB-Bereich
E-Mail, Telefon	String	Agent-Input	Einzelne Felder
Kontakt-Historie	Array	CRM-API (Read)	10-50 Einträge pro Kontakt
Duplikat-Kandidaten	Array	CRM-API (Search)	0-5 Treffer pro Suche

Designentscheidung: Der Agent legt Kontakte an, aber überschreibt keine bestehenden ohne Bestätigung. Bei Duplikat-Verdacht liefert er die Kandidaten zurück und fragt nach.

Tool 2: Angebot erstellen

Zweck: Standardisierte Angebote auf Basis von Vorlagen generieren, mit kundenspezifischen Daten befüllen.

Operationen:

list_templates – Verfügbare Angebotsvorlagen auflisten
get_pricing – Aktuelle Preisliste abrufen (Produkte, Staffeln, Rabattregeln)
create_offer – Angebot aus Vorlage erzeugen mit Positionen, Preisen, Konditionen
get_offer_status – Status eines bestehenden Angebots abfragen

Datenfluss:

Feld	Typ	Quelle	Typische Grösse
Vorlagen	Array	Internes Template-System	5-20 Vorlagen, jeweils wenige KB
Preisliste	Object	ERP oder Preisdatenbank	50-500 Positionen
Angebotsdokument	PDF/Binary	Generiert vom Server	100-500 KB pro Angebot
Kundenkonditionen	Object	CRM (kundenspezifische Rabatte)	Einzelner Datensatz

Designentscheidung: Preise und Rabatte kommen aus der Preisdatenbank, nicht aus dem Gedächtnis des Modells.

Tool 3: Pipeline-Report generieren

Zweck: Aktuelle Vertriebszahlen aufbereiten, ohne dass jemand im CRM klicken und exportieren muss.

Operationen:

get_pipeline_summary – Aggregierte Pipeline nach Phase (Lead, Qualifiziert, Angebot, Verhandlung, Gewonnen/Verloren)
get_deals_by_stage – Detailliste der Deals in einer bestimmten Phase
get_forecast – Gewichtete Umsatzprognose auf Basis der Pipeline
get_activity_summary – Aktivitäten pro Vertriebsmitarbeiter (Calls, E-Mails, Meetings)

Datenfluss:

Feld	Typ	Quelle	Typische Grösse
Pipeline-Übersicht	Object	CRM-API (Aggregation)	Wenige KB (5-8 Phasen)
Deal-Listen	Array	CRM-API	20-200 Deals, je nach Filter
Forecast-Daten	Object	Berechnet aus Pipeline-Daten	Einzelner Datensatz
Aktivitätslog	Array	CRM-API	50-500 Einträge pro Woche

Designentscheidung: Reports enthalten sensible Geschäftsdaten. Der MCP-Server muss wissen, wer fragt – ein Vertriebsmitarbeiter sieht seine Deals, ein Teamleiter sieht alle.

Innerer Aufbau

Der MCP-Server sitzt zwischen Agent und den internen Systemen (CRM, Preisdatenbank, Template-Engine). Er ist kein Proxy, sondern eine kuratierte Schicht, die Komplexität versteckt und Sicherheit durchsetzt.

Agent (Claude, Cursor, eigener Client) Stellt Anfragen über MCP-Protokoll

MCP-Server Validiert, autorisiert, transformiert

CRM-API + Preisdatenbank + Template-Engine Liefert und speichert Daten

Schichten im MCP-Server

1. Tool-Definition (Schema-Layer)

Jedes Tool beschreibt sich selbst: Name, Beschreibung, erwartete Parameter mit Typen, Rückgabeformat. Das ist der Vertrag, den der Agent sieht.

{
  name: 'create_contact',
  description: 'Legt einen neuen Kontakt im CRM an. Prüft vorher auf Duplikate.',
  inputSchema: {
    type: 'object',
    properties: {
      name: { type: 'string', description: 'Vor- und Nachname' },
      company: { type: 'string', description: 'Firmenname' },
      email: { type: 'string', description: 'E-Mail-Adresse' },
      phone: { type: 'string', description: 'Telefonnummer (optional)' },
      source: {
        type: 'string',
        enum: ['email', 'phone', 'website', 'event', 'referral'],
        description: 'Woher kommt der Kontakt?'
      }
    },
    required: ['name', 'company', 'email', 'source']
  }
}

2. Validierung und Geschäftslogik

Bevor ein Request an das CRM geht, prüft der Server:

Sind alle Pflichtfelder vorhanden und valide?
Gibt es bereits einen Kontakt mit dieser E-Mail? (Duplikat-Check)
Hat der anfragende Nutzer die Berechtigung für diese Operation?
Liegt der Rabatt innerhalb der erlaubten Grenzen? (bei Angeboten)

async function handleCreateContact(params: ContactInput, context: RequestContext) {
  // Duplikat-Prüfung
  const duplicates = await crmClient.searchContacts({
    email: params.email,
    company: params.company
  });

  if (duplicates.length > 0) {
    return {
      status: 'duplicate_found',
      message: `Mögliche Duplikate gefunden: ${duplicates.map(d => d.name).join(', ')}`,
      duplicates: duplicates.map(d => ({
        id: d.id,
        name: d.name,
        company: d.company,
        email: d.email
      })),
      suggestion: 'Bitte prüfen und ggf. update_contact verwenden'
    };
  }

  // Kontakt anlegen
  const contact = await crmClient.createContact({
    ...params,
    owner: context.userId,
    createdVia: 'mcp-agent',
    createdAt: new Date().toISOString()
  });

  return {
    status: 'created',
    contactId: contact.id,
    message: `Kontakt ${contact.name} bei ${contact.company} angelegt`
  };
}

3. CRM-Adapter

Die Verbindung zum CRM ist austauschbar. Ob HubSpot, Pipedrive oder Salesforce – der Adapter übersetzt zwischen MCP-Operationen und CRM-spezifischer API. Das hält den Server portabel.

interface CrmAdapter {
  searchContacts(query: SearchQuery): Promise<Contact[]>;
  createContact(data: ContactInput): Promise<Contact>;
  updateContact(id: string, data: Partial<ContactInput>): Promise<Contact>;
  getDeals(filter: DealFilter): Promise<Deal[]>;
  getPipeline(): Promise<PipelineStage[]>;
}

Für HubSpot ist das ein REST-Client gegen die HubSpot API. Für Salesforce ein SOQL-Client. Für ein selbstgebautes CRM ein Datenbank-Client. Die MCP-Tools bleiben identisch.

Datenmengen und Performance

Ein häufiger Irrtum: MCP-Server verarbeiten riesige Datenmengen. In der Praxis ist das bei CRM-Szenarien selten der Fall.

Operation	Typische Datenmenge	Latenz (Ziel)
Kontakt anlegen	Wenige Felder, unter 1 KB	Unter 500 ms
Duplikat-Suche	0-5 Treffer, unter 5 KB	Unter 1 s
Angebot erstellen	Template + Positionen, 10-50 KB Input, 100-500 KB Output (PDF)	2-5 s
Pipeline-Summary	Aggregierte Zahlen, unter 10 KB	Unter 1 s
Deal-Liste (gefiltert)	20-200 Einträge, 50-200 KB	1-3 s
Aktivitätslog (Woche)	50-500 Einträge, 20-100 KB	1-2 s

Die Engstelle ist selten der MCP-Server selbst, sondern die API-Limits und Antwortzeiten des CRM. Sinnvolle Massnahmen:

Caching für Daten, die sich selten ändern (Vorlagen, Preislisten) – Invalidierung bei Änderungen
Pagination für grosse Listen (Deals, Aktivitäten) – nicht alles auf einmal laden
Aggregation im Server statt im Agent – der Agent bekommt aufbereitete Zahlen, nicht rohe Datensätze

Praxisbeispiele

Morgen-Briefing für den Vertriebsleiter

“Gib mir ein Update zur Pipeline. Was hat sich seit letzter Woche verändert? Welche Deals stecken fest?”

Der Agent ruft get_pipeline_summary und get_deals_by_stage auf, vergleicht mit dem Stand der Vorwoche (falls gespeichert) und formuliert eine Zusammenfassung. Kein Dashboard-Login, kein manueller Export.

Lead-Erfassung nach Messe

“Ich habe auf der Messe 12 Kontakte gesammelt. Hier sind die Visitenkarten.”

Der Agent verarbeitet die Kontakte einzeln: find_contact (Duplikat-Check), dann create_contact oder update_contact. Am Ende eine Zusammenfassung: 8 neu angelegt, 3 aktualisiert, 1 Duplikat zur manuellen Prüfung.

Angebot nach Erstgespräch

“Erstell ein Angebot für Firma Müller, Paket Professional, 50 Lizenzen, 10 Prozent Neukundenrabatt.”

Der Agent ruft get_pricing ab, prüft ob der Rabatt innerhalb der erlaubten Grenzen liegt, erstellt mit create_offer das Angebot aus der Vorlage und liefert das PDF. Der Vertriebsmitarbeiter prüft und verschickt.

Wöchentlicher Forecast für die Geschäftsführung

“Wie sieht der Forecast für Q2 aus?”

Der Agent kombiniert get_pipeline_summary und get_forecast, gruppiert nach Produkt oder Region und erstellt eine strukturierte Prognose.

Anforderungen an die produktive Umgebung

Ein MCP-Server für den Vertrieb ist kein Nebenprojekt, das auf dem Laptop eines Entwicklers läuft. Für den produktiven Einsatz braucht es:

Authentifizierung und Autorisierung

Wer darf was? Vertriebsmitarbeiter sehen ihre Kontakte und Deals. Teamleiter sehen alle. Praktikanten sehen nichts.
Service Accounts für den MCP-Server gegen die CRM-API – mit minimalen Rechten (Principle of Least Privilege)
Audit-Log: Jede Aktion, die der MCP-Server ausführt, wird protokolliert – wer hat wann welches Tool mit welchen Parametern aufgerufen
Schutz gegen Prompt Injection: Der MCP-Server muss gegen missbräuchliche Tool-Aufrufe geschützt werden. Ein Agent darf nur Tools nutzen, für die der Benutzer berechtigt ist – unabhängig davon, was im Prompt steht.

Datenschutz und Compliance

CRM-Daten enthalten personenbezogene Informationen. DSGVO gilt.
Der MCP-Server speichert keine Daten selbst – er leitet durch. Aber der Transport muss verschlüsselt sein (TLS).
Kontaktdaten dürfen nicht im LLM-Kontext landen, wenn sie dort nicht hingehören. Der Server kontrolliert, welche Felder zurückgegeben werden.
Bei europäischen Kundendaten: Server in der EU betreiben. Container-Hosting bei Hetzner, Scaleway oder OVH löst das. Details zum Hosting im Kostenvergleich aus Teil 4.

Verfügbarkeit und Fehlerbehandlung

Der MCP-Server muss laufen, wenn der Vertrieb arbeitet. Kein Freitagabend-Deploy ohne Rollback-Plan.
Wenn die CRM-API nicht erreichbar ist, meldet der Server das klar – kein stilles Scheitern, keine erfundenen Daten.
Rate Limits der CRM-API beachten: HubSpot erlaubt 500 Requests pro 10 Sekunden im Professional-Plan. Bei 15 Vertriebsmitarbeitern mit aktiven Agenten kann das relevant werden.

Monitoring

Wie oft wird welches Tool aufgerufen? (Nutzungsmuster verstehen)
Wie lange dauern die Antworten? (Performance-Probleme erkennen)
Welche Fehler treten auf? (CRM-API-Probleme, Validierungsfehler, Berechtigungsfehler)

Ein einfaches Logging nach stdout reicht für den Start. Für den Dauerbetrieb: strukturierte Logs, die ein zentrales System (Grafana, Datadog, ein einfacher Loki-Stack) einsammeln kann.

Deployment

Für CRM-Zugriffe empfiehlt sich ein lokaler oder interner Betrieb:

Lokal (stdio): Läuft auf dem Rechner des Nutzers, kommuniziert direkt mit Claude Desktop oder der IDE. Einfachster Start, keine Netzwerk-Konfiguration. Nachteil: Jeder braucht Node.js und die richtige Version.
Intranet-Container: Docker-Container im Firmennetz, erreichbar per Streamable HTTP. Zentrales Update, einheitliche Konfiguration, ein Service Account für die CRM-API. Empfehlung für Teams ab 5 Nutzern.
npm-Paket: Intern publiziertes Paket (@firma/crm-mcp), das jeder Entwickler als stdio-Server einbinden kann. Git-versioniert, testbar, deploybar.

Vom Konzept zum ersten Tool

Der praktische Einstieg ist kleiner als man denkt:

Ein Tool implementieren – find_contact ist der risikoloseste Start. Nur Lesen, kein Schreiben.
Im eigenen Setup testen – lokal per stdio, mit dem eigenen CRM-Account.
Duplikat-Check ergänzen – create_contact mit vorgeschalteter Suche.
Im Team ausrollen – als npm-Paket oder Container.
Angebotserstellung und Reports folgen, wenn die Basis steht.

Jedes Tool, das funktioniert, spart dem Vertrieb Minuten pro Tag. Bei 15 Mitarbeitern summiert sich das. Nicht weil die KI den Vertrieb ersetzt – sondern weil sie Routinearbeit übernimmt, die niemand vermisst.