RICHTEN SIE IHREN AGENT
AUF ECHTEN KONTEXT.
Jedes Model wird automatisch zu einem Satz MCP-Tools. Richten Sie Claude auf Ihren Workspace aus, und es kann mit einem Befehl gegen Ihren echten Kontext lesen, schreiben und planen. Kein Connector zu bauen, kein Export zu kopieren.
WAS MCP IST.
Das Model Context Protocol (MCP) ist ein offener Standard, um KI-Anwendungen mit den Tools und Daten zu verbinden, die sie brauchen. Statt dass jeder Assistent sein eigenes Plugin-Format erfindet, legt MCP einen einheitlichen Weg fest: Ein Server beschreibt, was er anbietet, ein Client nutzt es.
Ein MCP-Server veröffentlicht eine Liste von Tools — jedes mit Namen, Beschreibung und typisiertem Eingabeschema. Ein MCP-Client — ein Desktop-Assistent, ein Coding-Agent, Ihr eigenes Programm — erkennt diese Tools zur Laufzeit und lässt das Modell entscheiden, wann es sie aufruft. Das Modell fragt, der Server antwortet mit strukturierten Ergebnissen, und der Client kann den Menschen fragen, bevor ein Tool läuft.
Der praktische Effekt: Ein MCP-Server genügt, und jeder MCP-kompatible Client kann ihn nutzen. Die Spezifikation ist öffentlich unter modelcontextprotocol.io.
WARUM EIN CRM MCP-NATIV SEIN SOLLTE.
MCP nachträglich an ein CRM anzubauen heißt meist, eine API zu umhüllen, die für eine Oberfläche entworfen wurde. CMP42 beginnt am anderen Ende: Die Tool-Oberfläche wird aus Ihrer Ontologie generiert.
Tools, die Ihre Ontologie sprechen
Ein generisches „Datensätze abfragen“-Tool lässt das Modell raten, was es gibt. CMP42 erzeugt Tools pro Model — get_contact, list_deals_at_stage —, sodass der Agent Ihre tatsächlichen Geschäftsobjekte und deren typisierte Felder sieht.
Typisierte Eingaben, klare Fehler
Tool-Eingaben folgen dem Model, das Sie deklariert haben, und jeder Schreibvorgang wird validiert. Sendet ein Agent einen unpassenden Wert, erhält er eine klare Fehlermeldung und korrigiert sich — statt ein Feld oder eine Phase zu erfinden.
Eine Oberfläche für jeden Agent
Heute Claude, im nächsten Quartal ein anderer Client, nächsten Monat ein eigener Agent Ihres Teams. Alle nutzen dieselben Tools — kein herstellerspezifisches Plugin, das bei jedem neuen Agent des Monats neu gebaut werden muss.
TOOLS, DIE IHR AGENT AUFRUFEN KANN.
Ab Werk gibt es zwei Arten von Tools. Context-Tools arbeiten über den gesamten Graphen. Model-Tools werden für jeden Model-Typ generiert — für die Standards und für alles, was Sie selbst deklarieren.
| Tool | Art | Was es tut |
|---|---|---|
get_context | Context | Liest ein Objekt samt seinem Umfeld — die typisierten Kanten und die Quellobjekte, die ein Agent zitieren kann. |
list_related | Context | Folgt typisierten Kanten eines Objekts: dem Unternehmen, das ein Kontakt kennt, dem Deal, den er verantwortet, dem Dokument, das er verfasst hat. |
write_note | Context | Schreibt eine Notiz in den Graphen. Validiert, versioniert und dem Agent oder Menschen zugeordnet, der sie geschrieben hat. |
get_contact | Generiert · Model | Liest ein Objekt eines Model-Typs — hier einen Kontakt. |
list_deals_at_stage | Generiert · Model | Listet Objekte eines Model-Typs, gefiltert nach einem deklarierten Feld — hier Deals in einer bestimmten Phase. |
write_note_on_company | Generiert · Model | Schreibt in den Graphen, bezogen auf einen Model-Typ — hier eine Notiz zu einem Unternehmen. |
Jedes Model erzeugt sechs Standard-Tools mit fester Namenskonvention: {model}.create, {model}.read, {model}.update, {model}.delete, {model}.list, {model}.search. Models mit tagged fields bekommen zusätzlich {model}.filter. Namen verwenden Singular snake-case für das Model und dot-suffix für die Aktion — Beispiele: contact.create, deal.update, note.search.
Der Austausch rechts veranschaulicht das Muster: Ein Modell findet die Verlängerungs-Deals, holt den Kontext zu einem davon und schreibt eine Notiz zurück — drei Aufrufe, jede Antwort strukturiert, jeder Schreibvorgang zugeordnet. Die Tool-Namen folgen den Beispielen oben; die Struktur der Nutzdaten ist beispielhaft und erscheint mit der Alpha.
→ tools/call list_deals_at_stage
{ "stage": "renewal" }
← deal cmp42://deal/… "Aspen · Q4-Verlängerung"
owner → cmp42://contact/…
→ tools/call get_context
{ "uri": "cmp42://deal/…" }
← company, 2 contacts, 3 docs · Quellen zitiert
→ tools/call write_note_on_company
{ "company": "cmp42://company/…",
"body": "Verlängerungsrisiko: Budgetverantwortung gewechselt …" }
← Notiz geschrieben · v1 · written_by: agent:claudeJEDES MODEL WIRD ZU TOOLS.
Sie schreiben nie einen MCP-Server für Ihr CRM von Hand. Models werden in TypeScript-artigem YAML deklariert und mit einem Befehl migriert. Bei der Migration erzeugt CMP42 die passenden Tools, mit Eingabeschemata aus den Feldern, die Sie deklariert haben.
Fügen Sie ein Model Engagement hinzu, und Ihr Agent kann Mandate nach Phase auflisten und Notizen dazu schreiben — ohne dass jemand Verbindungscode schreibt. Migrationen sind abwärtskompatibel, die Tools, auf die sich Agents bereits verlassen, funktionieren weiter.
# models/engagement.yaml
model: Engagement
fields:
title: string
stage: "scoping" | "active" | "closed"
$ cmp42 migrate
✓ get_engagement
✓ list_engagements_at_stage
✓ write_note_on_engagementFUNKTIONIERT MIT JEDEM MCP-CLIENT.
Alles, was MCP-kompatibel ist, kann die Tool-Oberfläche von CMP42 nutzen. Dazu gehören:
- Claude Desktop
- Claude Code
- Cursor
- Cline
- Jeder eigene Agent, der mit dem MCP SDK gebaut ist
Für Clients ohne MCP — einen Slack-Bot, eine interne App, ein Skript — ist jede Operation auch über REST und GraphQL verfügbar. Alle Integrationsmöglichkeiten →
Clients verbinden sich über einen von zwei MCP-Transports. Lokales stdio für Entwicklung und CLI-Setups (Cursor, Claude Code lokal) — der CMP42-Prozess wird als Subprozess gestartet. Streamable HTTP für gehostete Agents (Claude Desktop, ChatGPT Custom Connectors, hosted Cursor). Authentifizierung erfolgt über einen workspace-scoped API-Token im MCP-Client-Config; der Token deckt einen Workspace und definierte Models ab. Vollständiger OAuth 2.1 folgt nach GA.
GLEICHE AUTHENTIFIZIERUNG. GLEICHER AUDIT-TRAIL.
MCP ist keine Hintertür in Ihr CRM. Authentifizierungsmodell und Audit-Trail sind für MCP, REST und GraphQL identisch: Ein Agent, der write_note aufruft, unterliegt denselben Regeln wie ein Dienst, der die API nutzt — und sein Schreibvorgang wird genauso protokolliert.
Jedes Objekt ist versioniert, und jeder Schreibvorgang hält fest, welcher Mensch oder Agent ihn erzeugt hat. Laufen Agents innerhalb eines Process, erhalten Sie zusätzlich die vollständige Laufhistorie, menschliche Freigabeschritte und den Token-Verbrauch pro Lauf.
EIN MCP-TOOL BENENNEN.
Design Partner erhalten das Recht, ein MCP-Tool vorzuschlagen und zu benennen. Passt es zur Plattform, bauen wir es und liefern es unter Ihrem Namen aus — an alle künftigen Kunden. Starke Bewerbungen beschreiben ein echtes Tool aus einem echten Workflow.
Zwölf Plätze, sechs Monate Alpha ab Oktober 2026, 6.900 € einmalig.