GrowthKit Revenue Intelligence MCP Server

Add one or more leads to a campaign. Standard fields (company_name, contact_email, etc.) go to typed columns. ANY OTHER FIELD you pass automatically gets stored in the metadata jsonb column — no schema migration needed for new fields. Examples of custom fields: booth_number, source_event, scanned_at, follow_up_priority, notes_from_call. Call getCampaignLeadFields first to discover what custom fields are already used in this campaign.

Cancel a pending reminder by ID.

Check for unread notifications (direct messages and broadcasts).

Delete ALL memories. Irreversible. Always ask for explicit confirmation. You MUST provide a change_reason.

Return only counts, not content — use for overview/sizing (e.g. 'how many competitor memories exist?') before deciding whether to list or search. Optionally filter by chapter via metadata_filter.chapter. For a per-chapter breakdown in one call, prefer getChapterOverview.

Create a new campaign briefing. Use after collecting the 7 required fields via the campaign-briefing-playbook (search 'campaign-briefing-playbook' in playbook chapter to load the methodology). Sets status='draft'. Returns the created campaign id. NEVER call this without first running the playbook conversation — every campaign needs a complete briefing.

Schedule a reminder. Convert relative times to ISO 8601.

Create a prioritized task. Provide the four ICE inputs (impact, confidence, effort_constraint, effort_nonconstraint); the DB computes ice_score. Show the inputs to the user for confirmation before calling.

Add a note to a CRM record — a deal, company, or contact. Provide content (HTML supported) and at least one target id (deal_id, company_id, or contact_id). Use to log call summaries, context, or decisions against the record.

Check if CRM is connected and which provider is active.

Create a follow-up activity on a CRM record. Provide a subject and set type (call | meeting | task | email | deadline; default task). Optionally link it to a deal, company, or contact and set a due_date (YYYY-MM-DD). Use to schedule next steps after an interaction.

Create a new company. ALWAYS search first to avoid duplicates.

Create a new contact. ALWAYS pass company_id when the company exists.

Create a new deal. Requires title + stage_id. MUST call crmGetPipelines first.

Get full company details by ID. Returns name, domain, industry, employees, address, CRM link.

Get all contacts linked to a company, by company ID. Use to find who to reach at a known company.

Get all deals linked to a company, by company ID. Use after crmSearchCompany or crmGetCompany to review that company's pipeline.

Get full contact details by ID.

Get the full record for one deal by ID. Use after a search or list returns a deal id when you need its complete details.

Get all pipelines with stages. ALWAYS call before creating deals to get valid stage_id.

List companies from CRM with structured filters. Use for segment queries like 'all pharma companies with 50-200 employees in DACH'. All filter fields optional. Returns companies with id, name, industry, employees, country, and pagination info. Unlike crmSearchCompany (which does fuzzy name search), this does precise structured filtering.

List people/contacts from CRM with structured filters. Use for segment queries like 'all CEOs in pipeline companies'. All filter fields optional. Unlike crmSearchContact (fuzzy lookup of one person by name), this does precise structured filtering across the contact base. Returns contacts with id, name, title, company, and pagination info.

Search CRM for a company by name. ALWAYS search before creating to avoid duplicates.

Search CRM for a contact by name or keyword (fuzzy match); returns the top matches. Use to look up one known person. For structured segment queries across the contact base (e.g. 'all CEOs in pipeline companies'), use crmListPeople instead.

Update a deal. Use generic names: company_id, contact_id, expected_close.

Delete a document and its associated insights. Irreversible — always confirm with the user first.

Permanently delete ONE why-now signal, e.g. one recorded on the wrong company. Always confirm with the user first: name the company, the signal sentence and its source, and wait for an explicit yes. There is no undo and no version history. signal_id is the `id` of a signal from listLeadSignals (active_only=false also lists expired ones). Only this signal is removed — the lead's other signals stay untouched. If the signal is right and only a detail is wrong, use updateLeadSignal instead. 404 signal_not_found means the id is unknown or not in this workspace.

Delete memories by IDs. Always confirm with user first. You MUST provide a change_reason explaining WHY these memories should be deleted. The reason is stored in the version history audit log.

Find lookalike companies for a seed and re-rank them by fit. mode='account' (seed={domain}) finds companies similar to that domain via Hunter similar_to; mode='icp' (no seed) discovers companies matching your saved ICP; mode='won_deals' is not yet implemented. Each candidate comes back with similarity_to_seed (0–100 firmographic closeness to the seed), canonical_icp_score (0–100 vs your global ICP; null if not on the Pro plan), divergence + divergence_flag (≥25 = seed diverges from ICP — a product signal), classification, and already_in_crm. Read-only — it never writes and never reveals emails/phones (do that per-lead separately). To control cost, only the top `shortlist_size` pre-ranked candidates are fully enriched + scored; the rest come back with enriched:false and null scores (candidates with enriched:false were NOT evaluated — null is 'not scored', not a low score). NOTE: mode='account' uses Hunter `similar_to`, which requires a Hunter Premium/Data-Platform key; without it, discovery automatically falls back to query/industry filters and says so in `warnings`.

Compose an email via the user's connected email provider (currently Gmail; Microsoft 365 coming in Phase B). DEFAULT mode is 'draft' — creates a real draft in Gmail that the user can review before sending. Only use mode='send' when the user explicitly confirms sending with keywords like 'sende', 'schick raus', 'verschicken', 'send it', 'raus damit'. On 'draft' success, response includes draft_url the user can click to open the draft in Gmail. On 'send' success, response includes a tracking_id (1×1 pixel auto-injected for open-tracking). The From address is resolved server-side (5-level precedence: explicit from > user-token integration > user-token default > account default > account email) — do NOT fabricate a From address. Optional crm_deal_id links the message to a deal for future activity writeback. Requires active email provider OAuth connection.

Store knowledge into long-term memory. Supports single items and batch embedding (max 50). IMPORTANT — Chapter System: Every memory MUST be classified into exactly one chapter via metadata.chapter. Available chapters: icp, strategy, campaigns, analytics, brand, competitors, learnings, general, pipeline, signals, playbook. Always analyze the content and pick the most specific chapter. Use general only as a last resort. BEFORE STORING: Search target chapter first to check for duplicates. QUALITY: 50-300 words, specific and factual, one concept per memory. AUTO-TAGGING: Before saving ANY memory, search the playbook chapter for 'tag-taxonomy' to load the current tag taxonomy. Then add 3-7 relevant tags as a comma-separated string in metadata.tags (e.g. metadata: { chapter: 'campaigns', tags: 'saas,series-a,dach,linkedin,demand-gen' }). Pick the most specific tags from the taxonomy. You may add 1-2 free-form tags if needed. For batch embeds, tag each item individually. PLAYBOOK SYSTEM: Available playbooks: icp-workshop, onboarding, campaign-brief, weekly-review, competitor-analysis, content-brief. When the user asks to do any of these tasks, use prompts/get to load the full playbook and follow its steps.

Get company info by domain or name. Returns industry, employees, revenue, location, technologies. Prefer `domain` — it is unambiguous; a name matches whatever the provider thinks it means. `domain_unresolved` is not a provider failure — no provider was called and no credit was spent. The reply carries `candidates` (up to five domains with titles): offer them to the user, or pass `country` / `industry` as hints and try again.

Get person profile from email or LinkedIn URL.

Find contacts at a company. Filter by seniority or department.

Find one person's email by name + domain.

Read the weekly AEO report history — how this workspace's brand shows up in AI answer engines. Per ISO week (field: period) and domain: visibility, share_of_voice and own_cited (all ratios 0..1, multiply by 100 to display a percentage), avg_position (1 = best; null = never mentioned that week, NOT zero), plus prompts_scored and attempted_but_no_data. Each series point also carries per_engine: one entry per answer engine with engine, prompts_scored, attempted_but_no_data, visibility, share_of_voice and avg_position. In per_engine, visibility/share_of_voice/avg_position are null (not 0) when that engine produced no data, and there is deliberately NO own_cited — that one exists only at the week level. Weeks before 2026-08-29 have their per_engine rebuilt from the stored by-engine metrics, so the per-engine trend has no gap. Returns { domains: { <domain-slug>: { series: [...], latest_card } } }. Omit domain to get every tracked domain. Use when the user asks about AI-search visibility, share of voice in LLM answers, or how often the brand gets cited.

Get a single campaign with full briefing details and lead-stage counts.

One campaign lead with everything stored about it: contact, company, score, lifecycle_stage, metadata and the complete enrichment_data. That is where you answer why a contact was chosen and who else was found: enrichment_data.persona holds the trail (persona_naehe, persona_treffer, gewaehlt, alternativen, getauscht), enrichment_data.kandidaten_liste the people the enrichment found, and metadata.vorheriger_kontakt the contact this one replaced. Read-only, spends no credits. ⚠ campaign_lead_id is the `id` of a row from listCampaignLeads (campaign_leads.id). It is NOT the `lead_id` from pipelineStatus' top_10 or listLeadSignals: that one names the company row and answers lead_not_found — exactly as a lead from another workspace does.

Discover which fields are actually used in a campaign's leads. Returns standard columns with non-null values PLUS all metadata (custom) keys with usage counts and sample values. ALWAYS call this BEFORE asking the user about lead structure or before adding new custom fields — it tells you what's already established for this list.

Get memory count per chapter. Use as FIRST STEP in new conversations or reviews.

Get a specific document with fresh download URL and linked insights.

Get the version history of a specific memory. Shows all previous versions with timestamps and who made changes.

Return the workspace's open/in-progress tasks ranked by ICE (highest priority first) plus the total open count. Call this at the START of any planning, prioritization, or 'what should I work on next' discussion to ground the conversation in current open tasks before advising.

Read the weekly SEO report history for this workspace's domains: Google Search Console clicks and impressions, average position, AI-referral sessions and content-brief counts — one data point per ISO week, oldest first. Returns { domains: { <domain-slug>: { series: [...], latest_card } } }. IMPORTANT: avg_position is null for a week with no data — null is NOT zero and must never be charted or averaged as zero. Omit domain to get every domain the workspace tracks. Use when the user asks how SEO, organic search or Search Console performance developed over time.

Retrieve the highest-scoring leads from the CRM, ranked by ICP fit. Returns company details, contact (if any), 4-dimension score breakdown, and qualitative reasons like 'Industry X — strong match to ICP'. By default filters out leads with <50% data completeness to avoid false-positives from data-sparse ICP matches (e.g. leads where only the contact's seniority matched but industry/employees/country are unknown). Override via filters.min_completeness if you want incomplete leads too. Requires scoreLeads to have been run at least once. Requires Pro plan. Read-only — does not trigger new scoring. Call scoreLeads first if your CRM has new companies or ICP has changed (check icp_version_hash in the response to detect staleness). The fit gate decides on `score_fit` against `fit_gate_min` (default 60), never on `score`: `score` is the composite that ranks leads INSIDE the gate and is structurally low for cold leads, so comparing it with the threshold is always wrong.

Retrieve the current state for a (kind, key) in the current session. Returns null if not set. Use this when you need to merge into existing state or verify what's stored. NOTE: Active working memory entries are ALSO automatically injected into the system prompt by Build Messages — you usually don't need to call this manually. Only call when you need a specific record's full state on-demand.

List leads in a campaign, optionally filtered by lifecycle_stage or enrichment_status. Returns up to 100 per call. Compact rows by default — id, company name, domain, score, fit_gate, strong_signals, has_email, has_phone, lifecycle_stage — which is what you need to rank and to decide. The compact rows carry no contact. fields=full adds the contact (contact_name, contact_role, contact_email, contact_phone), enrichment_provider, enriched_at and enrichment_persona: why the enrichment picked this contact — persona_naehe (closeness of the contact's role to the campaign persona, 0 to 1), persona_treffer, gewaehlt, the alternativen it passed over, and getauscht when it replaced a contact who was already there; that previous contact is kept in metadata.vorheriger_kontakt. enrichment_persona is null when the lead was never enriched with a persona. For one lead's complete record — including kandidaten_liste, everyone the enrichment found — call getCampaignLead with the row's id. The fit gate decides on `score_fit` against `fit_gate_min` (default 60), never on `score`: `score` is the composite that ranks leads INSIDE the gate and is structurally low for cold leads, so comparing it with the threshold is always wrong.

List campaigns for the current user, optionally filtered by status. Returns campaign metadata plus per-stage lead counts.

List recently deleted memories that can be restored. Shows content preview and deletion info.

List stored documents with optional filtering by category or chapter.

List the stored why-now signals for one lead or for a whole campaign: `id` (the signal_id that updateLeadSignal and deleteLeadSignal take), type (funding, hiring, job_change, leadership, acquisition, expansion, tech_change, regulatory, event, inbound, other), the one-sentence signal, its source URL, the observed date, a confidence, and `cite`. Read-only. When you use a signal in outreach, use `cite` VERBATIM as the source line — it is already formatted for the reader ("ad-hoc-news, 27. August 2026"). Never write "observed", "observed_at" or "as observed on": those are field names from our data model, not words a prospect should read. Never present a signal without its source and date.

List stored memories in stored order with pagination. Unlike searchMemory (semantic relevance ranking), use this to browse, enumerate, or audit a chapter — not to find the most relevant memory for a question. Filter by chapter via metadata_filter.chapter.

List reminders, ordered by remind_at ascending. By default returns only pending reminders; pass status=sent|cancelled|all to widen. Optionally scope to one task via task_id. Returns each reminder's id, title, remind_at, and status.

List tasks in the workspace, ranked by ICE (highest first). Optional filters.

List all team members (token holders) for your account. Shows display names, roles, and identifies which token is yours.

Run ONE stage of the qualification chain for the next N candidates. Stages in order: resolve → score → signals → reveal → rescore; rerank follows reveal and re-judges the contacts that are already there. ALWAYS call with dry_run=true first and show the user the candidate count and estimated_credits; only after explicit confirmation call again with dry_run=false and confirm_credits set to the number you showed. reveal spends 3 credits per lead (13 with with_phone) and resolve spends 1 per lead; score, signals and rescore spend none — so resolve needs confirm_credits too, not just reveal. rerank calls no provider at all: it reads the stored candidate lists, and the only credit it can spend is one per contact it actually swaps (the new address is verified). That number is not knowable before the run, so its estimate is 0 — use rerank instead of a second reveal whenever the contacts are there but the wrong people. A stage with 0 candidates is not an error — it means the previous stage has to run first, and the reply then carries `why_zero` with per-condition `counts` and a finished sentence in `de` and `en`: report that reason, never invent one. `why_zero` is absent whenever there are candidates. Never run this against a demo campaign; it is refused with 403. The response ends with `next`: pending counts per stage (label_de/label_en, why_zero at 0) — base every next-step suggestion on it, never on chat history. The fit gate decides on `score_fit` against `fit_gate_min` (default 60), never on `score`: `score` is the composite that ranks leads INSIDE the gate and is structurally low for cold leads, so comparing it with the threshold is always wrong.

Show where a campaign's leads stand in the qualification chain. Returns the funnel (how many leads have a domain, firmographics, a score, a signal, an email, a phone), how many candidates each stage currently has, and the top 10 leads by priority. Read-only, spends no credits. Call this FIRST whenever the user asks what to do with a campaign — the pending counts tell you which stage to run next. The gate_column field says which signal column the reveal gate uses; if it reads 'active_signals' the gate is softer than specified and weak signals still count. The reply carries `stages` — one entry per stage with its pending count and `label_de`/`label_en`. Use those labels when you name a stage to the user; the internal ids (resolve, reveal) are not words a user knows. `contacts` counts three states, not two: `passend`, `andere_rolle`, `fehlt` — the middle one is the common case that "has an e-mail" hides, a contact who is there but in the wrong role. The fit gate decides on `score_fit` against `fit_gate_min` (default 60), never on `score`: `score` is the composite that ranks leads INSIDE the gate and is structurally low for cold leads, so comparing it with the threshold is always wrong.

APP-PRIVATE: initiates a click-to-call to one lead from the user's own verified caller ID. Not model-callable (hidden via _meta.ui.visibility:["app"]). Invoked only by the lead-call-card iframe when the human clicks ☎ Anrufen. The gk_ session token is taken server-side; the app passes campaign_lead_id only.

Restore a memory to a previous version. Works for both existing and deleted memories. Use version_id from getHistory or listDeleted results.

APP-PRIVATE: saves the post-call disposition / note / next action for one call. Not model-callable (hidden via _meta.ui.visibility:["app"]). Invoked only by the lead-call-card iframe after a call. The gk_ session token is taken server-side; the app passes call_log_id (from place_call) plus optional disposition / notes / next_action.

Trigger ICP lead scoring. Two independent modes — choose by WHERE the leads live, they do not overlap. (1) CAMPAIGN MODE — mode='campaign' plus campaign_id: scores the leads of one campaign (campaign_leads). Use this whenever the request is about a campaign, an imported/uploaded lead list, or leads that are not in a CRM. Needs no CRM connection and no Pro plan. Scores are written back onto the campaign's leads; read them via listCampaignLeads (score / completeness per lead). (2) CRM MODE — mode='full' | 'delta' | 'company_ids': scores this user's connected CRM companies. 'full' = every company (slow for >1k), 'delta' = only those new or changed since the last run (recommended for routine updates), 'company_ids' = a specific list. Persists to the lead_scores table; read results via getTopLeads. Requires a connected CRM and a Pro plan (active or trialing). If the user has no CRM or no Pro plan, campaign mode is the only mode that will work. Both modes score on the same 4 dimensions (industry 35%, employees 25%, geo 20%, seniority 20%) with missing-data renormalization and return counts plus a per-user summary. Write-operation — it persists scores.

Search long-term memory using semantic similarity. ALWAYS SEARCH BEFORE ANSWERING marketing/strategy questions. Use short, specific keywords as queries. Available chapters: icp, strategy, campaigns, analytics, brand, competitors, learnings, general, pipeline, signals, playbook. TAG FILTERING: Memories are auto-tagged. Use metadata_filter with tags key to filter (e.g. metadata_filter: { chapter: 'campaigns', tags: 'linkedin' }).

Send a notification to a team member. First use listTeam to find the recipient. For 2-person teams, the recipient is auto-resolved.

Set the workspace effort weights (constraint vs non-constraint lane) and optional display labels. Re-stamps open tasks so their ICE re-ranks.

Store structured state for the current chat session. Use this to persist data that must survive history compression — wizard fields, suggestion lists, active entities. Three kinds: 'wizard' (multi-turn field collection), 'working_set' (ephemeral suggestion lists with TTL), 'pinned_entity' (durable context). Call this AFTER the user confirms a value, BEFORE moving to the next step. The state object replaces (not merges) — fetch first if you need to merge.

Render an interactive call card of leads that have a phone number, each with a ☎ Anrufen button. The HUMAN user clicks a button to place a click-to-call from their own verified caller ID. This tool ONLY displays the card — it never places a call itself, and there is no model-callable call tool (UWG § 7: calls are human-initiated only). Optionally scope to one campaign_id; omit it to aggregate all callable leads across the user's campaigns. Use when the user asks to see or call leads (e.g. "zeig mir anrufbare Leads", "welche Leads kann ich anrufen"). The fit gate decides on `score_fit` against `fit_gate_min` (default 60), never on `score`: `score` is the composite that ranks leads INSIDE the gate and is structurally low for cold leads, so comparing it with the threshold is always wrong.

Check off or re-open a single step in a task's checklist. Provide the task `id` and the `step_id` of the step to toggle. Omit `done` to flip the step's current state; set done=true/false to force a specific state (idempotent). Use when the user completes or reopens a checklist item on a task that has steps.

Update fields on an existing campaign. Pass only the fields to change. Use `scoring` to give THIS campaign its own lead-scoring profile — without it the campaign is scored against the user's global ICP, which is wrong whenever the campaign targets a different market. A campaign with its own profile also re-scores automatically when the profile changes.

Update fields on an existing campaign lead. Pass lead_id (UUID from listCampaignLeads) and an updates object with only the fields to change. Use this to mark leads as rejected, manually correct enrichment data, or attach custom metadata. Setting lifecycle_stage='rejected' REQUIRES rejected_reason in the same call. The metadata field is shallow-merged into existing metadata jsonb — existing keys are preserved unless overwritten by the same key. Score/dim_*/icp_version_hash are NOT writable here (those come from scoreLeads). crm_external_id/crm_synced_at are NOT writable either (CRM-Sync owns those).

Correct ONE stored why-now signal in place. signal_id is the `id` of a signal from listLeadSignals — call that with active_only=false to also see expired signals. updates carries only the fields to change: type, signal, source_url, source_label, observed_at, last_confirmed_at. Anything else is ignored and named in `ignored_fields`. The signal stays on its lead: lead_id is not writable, so a signal recorded on the wrong company is removed with deleteLeadSignal, not moved. Changing type, observed_at or last_confirmed_at makes the database recompute expires_at — the reply says so in `expires_at_neu_berechnet`; expires_at itself cannot be set. Setting last_confirmed_at to the date you re-checked the source revives a signal whose expiry has passed — for signals that describe an ongoing state (e.g. tech_change: the system is still in use). Event types (funding, hiring, …) keep counting from observed_at, so for them last_confirmed_at extends nothing; check `signal.expires_at` in the reply. Errors: 404 signal_not_found (unknown id, or not in this workspace), 409 duplicate_source_url (this lead already has another signal with that URL — delete that one first or use a different source), 400 with code signal_too_short, signal_too_long, invalid_type or source_required.

Update content or metadata of a stored memory. Use to enrich, fix, or reclassify. You MUST provide a change_reason explaining WHAT changed and WHY. The reason is stored in the version history audit log.

Update fields of a task. Partial update; status='done' sets done_at automatically. ice_score recomputes when impact/confidence/effort change.

Upload a file to GrowthKit document storage. Optionally extracts text and embeds insights.

Check if an email is deliverable. Use before outreach.