Einen KI-Agenten mit MCP an HubSpot anbinden: Was der First-Party-Server nicht löst

Das Problem: 12 Tools, die Verbindung lösen, nicht Bedeutung

HubSpot brachte seinen Remote-MCP-Server am 13. April 2026 zur allgemeinen Verfügbarkeit. Er verbindet Claude, ChatGPT, Cursor oder jeden MCP-kompatiblen KI-Client über OAuth 2.1 mit PKCE mit einem HubSpot-Portal, authentifiziert am mcp.hubspot.com-Endpoint. Er ist kostenlos über alle Hubs und Tiers. Er stellt 12 Tools mit Lese- und Schreibzugriff auf Standard-CRM-Objekte bereit — Kontakte, Unternehmen, Deals, Tickets, Produkte, Line-Items, Rechnungen, Quotes, Bestellungen, Carts, Abonnements, Segmente — und Engagement-Historie (Calls, E-Mails, Meetings, Notizen, Tasks). Er liest außerdem Kampagnen-Metriken, Landing-Pages, Webseiten und Blog-Posts. Die offizielle HubSpot-Dokumentation bestätigt, dass jede Aktion die bestehenden HubSpot-Berechtigungen des verbundenen Benutzers respektiert — es ist keine Hintertür.

Dies ist ein echtes Produkt, keine Demo. Für einen Vertriebsmitarbeiter, der Claude fragen möchte „fasse alle offenen Deals in der Phase 'Decision maker bought in' mit Deal-Wert über 1.000 $ zusammen", erledigt das der First-Party-Server. HubSpot veröffentlichte außerdem einen One-Click-Connector für Claude (16. Juli 2026), der jedem HubSpot-Nutzer mit einem kostenpflichtigen Anthropic-Abonnement erlaubt, sein CRM ohne Code an Claudes Chat-Oberfläche anzubinden. Das Setup dauert Minuten.

Das Problem ist nicht, was der First-Party-Server schlecht macht. Das Problem ist, was er gar nicht tut. Daeda Techs Analyse (14. April 2026, aktualisiert 22. Mai 2026) nennt die Gaps direkt: „Die Gaps drehen sich nicht darum, was das offizielle MCP schlecht macht — sie drehen sich darum, was es gar nicht tut." Keine davon ist ein Bug. Es sind Produkt-Scope-Entscheidungen. HubSpot lieferte einen soliden, sicheren Startpunkt. Aber für ein Mid-Market-B2B-Unternehmen, das Custom Objects, Workflow-Automatisierung oder Multi-Portal-Operationen betreibt, deckt der First-Party-Server die einfache Hälfte und lässt die schwierige Hälfte einem Custom-Modul.

Die sechs Capability-Gaps

Daeda Tech und der Scalekit-Vergleich (2. Juni 2026) dokumentieren die Gaps aus dem Produktionseinsatz. Sie mappen auf dasselbe Strukturpattern, das in der NetSuite MCP-Modul-Analyse erscheint: Der First-Party-Connector des Vendors löst das Verbindungsproblem. Er löst nicht das Semantic-Layer-Problem — die Lücke zwischen dem, was die Daten sagen, und dem, was das Unternehmen meint.

1. Keine Custom Objects

Der Remote-MCP-Server stellt nur Standard-CRM-Objekttypen bereit. Wenn Ihr Portal auf Custom Objects für Erneuerungen, Partnerschaften, Produktnutzungs-Tracking oder ein branchenspezifisches Datenmodell angewiesen ist, kann das offizielle MCP diese weder sehen noch anfassen. Scalekit bestätigt: „Enterprise-HubSpot-Accounts sind selten Vanilla — Professional-Services-Firmen, Healthcare-Tech-Unternehmen und RevOps-Teams bauen routinemäßig Kern-Datenmodelle auf Custom Objects." Die Gap ist unterdokumentiert: Kein Fehlercode signalisiert „dies ist ein Custom Object." Der Agent kann schlicht nicht auf die Daten zugreifen. Die HubSpot-Community-Foren dokumentierten dies im März 2026 — Entwickler entdeckten es durch Troubleshooting, nicht durch Dokumentation. Der einzige Workaround ist die direkte API, was bedeutet, dass der Agent ein Custom-Modul braucht, um sie zu erreichen.

2. Keine prüfbaren Schreibpläne

Der First-Party-Server führt Schreibvorgänge sofort über manage_crm_objects aus. Keine Drafts, keine Batch-Reviews, kein Undo-as-a-Batch für mehrstufige Änderungen. Ein Vertriebsmitarbeiter, der Claude bittet „verschiebe alle Deals in der 'Demo'-Phase nach 'Proposal Sent'", erhält sofortige, irreversible Mutationen. Für ein RevOps-Team, das Batch-Pipeline-Änderungen vor dem Commit prüfen muss — weil ein falscher Phasenwechsel die Forecast-Reportierung verzerrt und Downstream-Workflow-Automatisierung triggert — ist das Fehlen eines Review-Gates ein Produktionsrisiko. Daeda AI nennt dies „Write Plans with Human Review" — die KI erstellt einen strukturierten Plan, ein Mensch prüft und genehmigt ihn, dann wird der Plan ausgeführt. Der First-Party-Server hat kein Äquivalent.

3. Ein Portal pro Verbindung

OAuth 2.1 authentifiziert einen Nutzer an einem Portal. Eine Agentur oder ein Berater, die fünf HubSpot-Portale verwalten, braucht fünf separate OAuth-Verbindungen, fünf Token-Refresh-Zyklen und fünf Kontextwechsel im KI-Client. Es gibt kein Workspace-Modell. Für ein B2B-Service-Unternehmen, das mehrere Kunden-HubSpot-Instanzen verwaltet, ist dies eine operationale Einschränkung, die nicht skaliert. Ein Custom-Modul kann Multi-Portal-Routing intern handhaben — der Agent ruft get_deals(portal_id, ...) auf und das Modul löst die korrekten Credentials, Tokens und Endpoints. Der First-Party-Server kann das nicht.

4. Kein System-Level-Design

Der First-Party-Server ist nur auf Datensatzebene. Er kann Pipelines, Lifecycle-Stages, Workflow-Logik oder Listenkriterien nicht konversationell gestalten. Ein RevOps-Leiter, der einen Agenten fragen möchte „erstelle eine neue Pipeline-Stage namens 'Procurement Review' zwischen 'Qualified' und 'Proposal Sent' und verschiebe alle Deals über 50.000 $ dorthin", kann das nicht über den MCP-Server tun. Die direkte HubSpot-API unterstützt Workflow Automation API v4 und Pipeline-Management — aber der MCP-Server stellt diese Endpoints nicht bereit. System-Design ist eine direkte API-Operation, was bedeutet, dass es ein Custom-Modul braucht, um vom Agenten aus erreichbar zu sein.

5. Jede Abfrage trifft die API live

Der First-Party-Server hat keine lokale Daten-Schicht. Jeder Tool-Aufruf round-tripped zu den HubSpot-Servern. Daeda Tech bemerkt: „Latenz und Paginierung akkumulieren für große Analysen." Das search_crm_objects-Tool liefert bis zu 200 Ergebnisse pro Seite. Eine Cross-Objekt-Analyse über Tausende von Datensätzen bedeutet, durch Dutzende von API-Aufrufen zu paginieren, wobei jeder Latenz hinzufügt und jeder der Rate-Limit unterliegt. Für eine vierteljährliche Pipeline-Review, die jeden Deal, die zugehörigen Kontakte, deren Engagement-Historie und deren Unternehmen-Properties zieht, produziert das Live-API-Only-Modell einen langsamen Agenten, der mitten im Gedanken unterbricht, um auf die nächste Seite zu warten. Ein Custom-Modul mit einer gemanagten Daten-Schicht synchronisiert Portal-Daten in eine lokale Datenbank und führt Cross-Objekt-Queries in Sekunden aus — keine API-Roundtrips pro Frage, keine Paginierung mitten im Gedanken.

6. Die Sensitive-Data-Einschränkung

Wenn ein HubSpot-Account den „Sensitive Data"-Schalter aktiviert hat — im Gesundheitswesen und Finanzdienstleistungen verbreitet, für Accounts, die persönliche Gesundheitsinformationen verarbeiten, erforderlich — blockiert der MCP-Server alle Engagement-Objekte: Calls, E-Mails, Meetings, Notizen und Tasks. CRM-Objekte bleiben zugänglich, aber die Engagement-Historie, die einem Kontakt oder Deal seinen Kontext gibt, verschwindet. Die offizielle Dokumentation bestätigt dies direkt: „Wenn Sensitive Data aktiviert ist, werden Aktivitäts-Objekte (Calls, E-Mails, Meetings, Notizen, Tasks) vom MCP-Server-Zugriff blockiert." Das Claude-Connector-Setup-Guide wiederholt dieselbe Einschränkung. Die direkte CRM-API kann mit spezifischen Scopes auf Sensitive-Data-Properties zugreifen — aber der MCP-Server kann das nicht. Ein Healthcare-B2B-Unternehmen, das einen Agenten benötigt, um Call-Notizen zu einem Kundendatensatz zu lesen, wird auf Protokoll-Ebene blockiert, nicht auf Berechtigungsebene.

Authentifizierung: Das Headless-Agent-Problem

Der Remote-MCP-Server erzwingt ausschließlich OAuth 2.1 mit PKCE. Es gibt keinen Private-App-Token-Pfad. Scalekits Analyse nennt die Konsequenz: „Die direkte API unterstützt sowohl OAuth 2.0 als auch Private-App-Access-Tokens — letztere sind die einzige praktikable Authentifizierungsmethode für Headless-, geplante oder Hintergrund-Agenten, die keinen browserbasierten Consent-Flow abschließen können."

PKCE erfordert einen browserbasierten Consent-Flow — ein Mensch klickt „Allow" in einer Redirect-URL, HubSpot stellt einen Authorization Code aus, der Client tauscht ihn gegen Tokens. Refresh-Tokens sind Single-Use und rotieren bei jedem Refresh. Das ist sicher für interaktive Nutzung. Es ist unbrauchbar für einen Hintergrund-Agenten, der um 2 Uhr nachts läuft, um über Nacht geänderte Deals in ein Data Warehouse zu synchronisieren, oder einen geplanten Workflow, der jede Stunde auf gestallte Deals prüft und Follow-up-Tasks erstellt. Es gibt keinen Menschen, der auf „Allow" klickt, wenn das Token abläuft.

Die direkte HubSpot-API unterstützt Private-App-Access-Tokens — gescoped Bearer-Tokens ohne Redirect, ohne Browser, ohne Consent-Flow. Das ist, was Headless-Agenten und geplante Workflows tatsächlich brauchen. Ein Custom-MCP-Modul kann für unbeaufsichtigte Operationen über Private-App-Tokens und für interaktive Agent-Sessions über OAuth 2.1 authentifizieren — das Modul handhabt den Auth-Pfad intern, der Agent ruft get_deals auf und weiß nicht und kümmert sich nicht darum, welche Credentials verwendet werden.

Das Rate-Limit verschärft dies. HubSpots API-Nutzungsrichtlinien setzen 100 Requests pro 10 Sekunden für Private-Apps auf Free/Starter, 190 pro 10 Sekunden auf Professional/Enterprise. Dasselbe Limit gilt für MCP-Server-Requests — sie laufen gegen dieselbe CRM-Search-API darunter. Ein Agent, der 30 Tool-Aufrufe parallel gegen ein Free/Starter-Portal feuert, wird ein Drittel davon fehlschlagen lassen. Der First-Party-Server gibt eine 429 ohne strukturierte Retry-Anleitung zurück, außer was der MCP-Client implementiert. Ein Custom-Modul erzwingt Rate-Limiting pro Tool — jedes Tool deklariert sein eigenes Limit, das Backbone drosselt, und der Agent erhält eine strukturierte 429 mit einem Retry-After-Header statt eines Crashes.

Was ein Custom-MCP-Modul bietet

Das Modul-Pattern folgt dem MCP-Modul-Code-Standard: Jedes Tool hat ein typisiertes Input-Schema, ein typisiertes Output-Schema, ein Rate-Limit, ein Audit-Log und einen Error-Contract. Der Agent ruft Tools namentlich mit strukturierten Argumenten auf, nicht Free-Form-API-Aufrufe gegen rohe Endpoints.

Für HubSpot füllt das Custom-Modul die sechs Gaps:

Custom Objects. Das Modul stellt typisierte Operationen auf Custom-Object-Schemata bereit — get_renewal_record(renewal_id), search_custom_objects(object_type, filters), update_partnership_status(partnership_id, status). Jedes Tool-Schema kodiert die Properties, Assoziationen und Business-Meaning des Custom Objects. Der Agent erreicht Custom-Object-Daten über das Modul, nicht über einen Workaround.

Prüfbare Schreibpläne. Das Modul erstellt einen strukturierten Plan für mehrstufige Änderungen — „verschiebe 47 Deals von 'Demo' nach 'Proposal Sent', aktualisiere das Close-Datum auf 12 davon, erstelle Follow-up-Tasks für die Deal-Owner" — und routet ihn vor der Ausführung an einen menschlichen Reviewer. Der Plan ist ein typisiertes Objekt, kein Free-Form-Text-Blob. Der Reviewer genehmigt, lehnt ab oder modifiziert. Das Modul führt nur den genehmigten Plan aus und loggt jede Änderung.

Multi-Portal-Routing. Das Modul akzeptiert einen portal_id-Parameter auf jedem Tool-Aufruf und löst intern die korrekten Credentials, den Token-Store und den Endpoint. Der Agent verwaltet keine OAuth-Sessions. Ein einzelner Agent-Aufruf kann Deal-Daten über fünf Portale in einem Durchgang abfragen.

System-Level-Design. Das Modul stellt Pipeline-Management, Lifecycle-Stage-Konfiguration und Workflow-Automatisierung als typisierte Tools bereit — create_pipeline_stage(pipeline_id, label, display_order, probability), update_lifecycle_stage(contact_id, stage), enroll_in_workflow(contact_id, workflow_id). Diese mappen auf die HubSpot-Automation-API-v4- und Pipeline-Management-Endpoints, die der First-Party-Server nicht bereitstellt.

Gemanagte Daten-Schicht. Das Modul synchronisiert Portal-Daten nach Zeitplan in eine lokale Datenbank — Deals, Kontakte, Unternehmen, Engagements, Custom Objects — und führt Cross-Objekt-Queries gegen die lokale Kopie. Der Agent fragt „zeige mir alle Deals, die seit mehr als 14 Tagen in 'Proposal Sent' sind ohne Engagement in den letzten 7 Tagen" und das Modul liefert die Antwort in Sekunden, nicht Minuten paginierter API-Aufrufe.

Sensitive-Data-Zugriff. Das Modul authentifiziert sich über Private-App-Tokens mit den spezifischen Scopes, die zum Lesen sensibler Properties nötig sind — nicht über den blockierten Pfad des MCP-Servers. Der Agent liest Call-Notizen zu einem Healthcare-Kundendatensatz, weil das Modul die direkte API mit dem korrekten Scope verwendet, nicht die pauschale Blockade des First-Party-Servers.

Die Semantic Layer: Was der First-Party-Server nicht kodiert

Das Pattern ist dasselbe wie die NetSuite-Analyse. Der First-Party-Connector gibt der KI Zugriff auf Datensätze. Ein Custom-MCP-Modul gibt der KI das Verständnis, was diese Datensätze bedeuten. Das ist die Semantic Layer — typisierte Schemata, die dem Agenten sagen, welche Deal-Stages für das Forecasting dieses Unternehmens als „gewonnener Umsatz" zählen, welche Lifecycle-Stages das „Qualified Lead"-SLA dieses Marketing-Teams konstituieren, welche Custom-Object-Properties der „Renewal Value" für das Churn-Modell dieses Customer-Success-Teams sind.

Betrachten Sie eine Pipeline-Analyse. Der First-Party-Server stellt search_crm_objects mit Filtergruppen bereit. Ein Agent kann alle Deals in einer bestimmten Phase finden. Was er dem Agenten nicht sagen kann, ist, dass für dieses Unternehmen die „Closed Won"-Phase in der Sales-Pipeline als Umsatz zählt, aber dieselbe Phase in der Renewals-Pipeline nicht — Erneuerungen werden unter einer separaten Umsatzlinie gezählt. Ein Agent, der diese Unterscheidung nicht kennt, produziert ein Forecasting, das doppelt zählt. Das typisierte Schema des Moduls kodiert die Unterscheidung: get_revenue_pipeline_summary(period, pipeline_ids=["sales"], exclude_pipeline_ids=["renewals"]). Der Agent erhält eine korrekte Antwort, weil die Frage, die er stellt, die Frage ist, die das Unternehmen meint.

Oder betrachten Sie Lifecycle-Stages. Der First-Party-Server kann die Lifecycle-Stage eines Kontakts lesen. Er kann dem Agenten nicht sagen, dass für dieses Unternehmen ein Kontakt erst dann ein „Marketing Qualified Lead" wird, nachdem er ein Formular mit einem Unternehmensgrößen-Feld über 50 Mitarbeitern ausgefüllt hat — eine Regel, die in einem Custom-Workflow lebt, nicht in der Lifecycle-Stage-Definition. Das Modul kodiert die Regel in seinem Tool-Schema: get_qualified_leads(since_date, min_company_size=50, source="form_submission"). Die Regel ist im Schema, nicht im Prompt.

Warum dies generalisiert

Das HubSpot-Pattern — ein First-Party-MCP-Server mit 12 Tools, der Standard-Objekte abdeckt, eine Semantic-Layer-Gap, die der Vendor nicht liefert, eine Authentifizierungs-Einschränkung, die Headless-Agenten blockiert, und ein Rate-Limit, das naive parallele Aufrufe bricht — ist dieselbe Struktur, die im CRM- und ERP-Landschaft erscheint:

• NetSuite hat einen First-Party-AI-Connector-Service mit einer Genauigkeits-Gap — Oracles eigene FAQ warnt „KI kann halluzinieren. Validieren Sie immer Ergebnisse gegen Quelldaten." Die Semantic-Gap ist, welche GL-Konten „Umsatz" für dieses Unternehmen konstituieren. Die NetSuite-MCP-Modul-Analyse behandelt dies eingehend.
• Shopify hat einen First-Party-Storefront-MCP und ein Universal Commerce Protocol mit Google, aber der B2B-Pfad — kundenstufenbasierte Preisgestaltung, Bulk-RFQ-Quoting, Inventory-Holds gegen NetSuite, Cross-Channel-Order-Attribution — ist nicht in der First-Party-Oberfläche. Die Shopify-Connector-Analyse behandelt dies.

Der Anthropic 2026 State of AI Agents Report (500+ technische Führungskräfte, reale Implementierungen bei Novo Nordisk, Doctolib, L'Oréal, Shopify) identifiziert die Integration mit bestehenden Systemen als die Nummer-1-Barriere für die Agent-Einführung — 46% der Organisationen nennen sie, vor Datenzugang (42%), Sicherheit (40%) und Modellintelligenz. 47% verwenden einen hybriden Build-and-Buy-Ansatz: nicht vollständig vorgefertigt, nicht alles In-House, sondern eine Plattform, die sie mit Custom-Code erweitern. Die First-Party-MCP-Server sind die „Buy"-Hälfte. Das Custom-Modul ist die „Build"-Hälfte. Die Teams, die 2026 Produktions-Agenten ausliefern, sind die, die beides tun — der First-Party-Server für das, was er abdeckt, das Custom-Modul für das, was er nicht abdeckt.

HubSpot lieferte einen soliden First-Party-Server. Für Standard-Objekt-Lookups und einfache Updates reicht er. Für Custom Objects, prüfbare Schreibvorgänge, Headless-Authentifizierung, Multi-Portal-Operationen, System-Level-Design und Sensitive-Data-Zugriff ist das Custom-Modul der Produktionspfad. Der MCP-Modul-Code-Standard definiert die Struktur. Der HubSpot-Connector ist die Referenzimplementierung für den CRM-Fall — der Fall, in dem 12 Tools starten und die Semantic Layer in die Produktion führt.

---

Ein B2B-Service-Unternehmen, das HubSpot über fünf Kunden-Portale betreibt, mit Custom Objects für Erneuerungen und Partnerschaften, Workflow-Automatisierung für Pipeline-Management und einem vierteljährlichen Forecast, der von der korrekten Unterscheidung von Vertriebs- und Erneuerungsumsatz abhängt, erhält einen Agenten, der Custom-Object-Datensätze auflöst, prüfbare Schreibpläne für Batch-Pipeline-Änderungen erstellt, für geplante Syncs Headless authentifiziert, in einer einzigen Session über Portale routet und die Umsatz-Stage-Unterscheidung in typisierten Schemata kodiert — jeder Tool-Aufruf geloggt und jede Exception an einen menschlichen Reviewer geroutet. Dieser Build ist Phase 2-3 der Vier-Schritt-Methode und ist typischerweise in 5-8 Wochen live.

Fordern Sie einen gescoppten Build an. Einwöchiges Discovery. Sie erhalten ein System-Inventar, eine Workflow-Mappe und einen fixierten Scope — ob Sie mit uns bauen oder nicht.