MCP-Tool-Referenz

Diese Referenz entsteht direkt aus der Tool-Registry des Produkts. Jede Zeile entspricht dem Code, nicht einer Beschreibung, die jemand nachgetragen hat.

Sie müssen sie nicht abtippen: ein MCP-Client fragt Namen, Beschreibung und Parameter beim Verbinden selbst ab. Diese Seite ist zum Nachlesen und für Suchmaschinen und Agenten, die vorab wissen wollen, was möglich ist.

Agents

Create/manage AI agents, agent memory and learnings, agent chains (beta)

add_workflow_step

Add a step to an existing chain. By default appends to the end; set insert_after to insert at a specific position (1-based, 0 = at the very front). Agent step: pass agent_id + message_template. Deterministic steps: type=http_request (url, method, headers, body_template), type=add_table_rows (table_id + rows_field/row_template), type=enroll_sequence (sequence_id, channel) or type=feed_notify (message_template + optional title/action_type/lead_id_field — posts a card into the Feed).

create_agent

Create a new subagent for this workspace. The agent gets its own system prompt, model, and tool access controls.

Example: Create a ‘Lead Qualifier’ agent that only has access to research + qualification tools, with a specialized prompt for evaluating company fit.

Trigger types:

• keyword: { type: ‘keyword’, pattern: ‘qualify *’ } — invoked when message matches pattern
• event: { type: ‘event’, event: ‘lead_replied’ } — invoked on system event
• schedule: { type: ‘schedule’, cron: ‘0 9 * * 1’ } — runs on schedule
• channel: { type: ‘channel’, channel_id: ‘uuid’ } — default agent for a channel

create_workflow

Create a Workflow — the event-driven automation (per event: webhook, schedule, or manual run). Steps run in order, passing outputs forward: agent steps (bounded judgment, any connected MCP), deterministic steps (API call, add table rows, enroll into a Sequenz, post a feed card), and conditions. Use it for the automation AROUND Tabellen and Sequenzen — per-row work belongs in a table column, per-lead touch plans in a Sequenz. Dry-runnable via run_workflow(dry_run=true). IMPORTANT: for agent steps call list_agents first to get real agent IDs; if an agent doesn’t exist, create it with create_agent before creating the workflow.

delete_agent

Delete a subagent from this workspace.

delete_workflow_step

Remove a step from a workflow by 1-based position. Remaining steps shift down.

diagnose_workflow_run

Self-debug a failed or low-quality Workflow run. Returns a structured diagnosis: which step failed, the error, the resolved prompt + actual output, and a list of suggested fixes (add retry, edit prompt, gate with a condition, swap agent). The first stop when a run “succeeded” but changed nothing, or a user asks why a Workflow failed — then apply the fix via set_workflow_step_retry / update_workflow_step / set_workflow_step_condition.

get_agent

Get full details of a subagent including system prompt and configuration.

get_agent_memories

Get agent learnings and memories. These are data-driven insights the system has learned from campaign outcomes, reply patterns, and user feedback. Use this to understand what works for this workspace.

get_workflow_history

Get execution history for agent chains — shows each run with steps, quality scores, tool calls, and any issues. Use this to debug and optimize chains. Reads the new workflow_runs tables first; falls back to audit_log for runs predating the migration.

install_workflow_template

Install a battle-tested workflow template into this workspace. Missing agents the template references are auto-created. Idempotent: re-installing returns the existing workflow id unless force=true — a force install writes a FRESH copy of the template steps and retags the previous row as “-superseded” + disables it (returned as superseded_workflow_ids), so the slug never resolves to two rows. IMPORTANT: an agent that ALREADY exists is reused with its CURRENT system_prompt — a template prompt change does NOT reach it. Those agents come back in agents_with_stale_prompt; pass refresh_agent_prompts:true to overwrite them with the template text.

invoke_agent

Invoke a subagent with a message. The agent runs with its own system prompt and tool access, then returns the result.

list_agents

List all agents in this workspace with their status, assigned tools, and skill count. Use get_agent for full details of a specific agent.

list_workflow_templates

List battle-tested chain templates available for one-click install. Each template has a stable slug; pass it to install_workflow_template to deploy.

list_workflows

List the workspace’s Workflows (event-driven automations) — id, name, enabled state, trigger, and step count. The discovery entry point for the Workflow primitive: run_workflow, get_workflow_history and the step-editing tools all need an id from here.

reinforce_memory

Reinforce an existing memory with new evidence. Increases confidence score.

run_workflow

Run a Workflow now. Pass optional context data that the first step receives. Set dry_run=true for a safe rehearsal — side-effect tools (message sends, campaign enrollment) no-op and return their would-be payload, so you can verify the steps before anything goes out. Set max_credits to cap what this run may spend: the run stops BEFORE the step that would exceed it, and already-completed steps stand. Same brake Tabellen-Läufe have — use it for anything that loops over rows.

set_workflow_enabled

Activate or deactivate a chain. When disabled, scheduled fires are skipped, event triggers do not match, and manual runs are still allowed (so users can test before re-enabling). Equivalent to the on/off switch on the chain detail page.

set_workflow_max_concurrency

Set how many runs of this chain can be in flight at once. Default 1 — schedule fires that arrive while a previous run is still going are silently dropped. Set higher for chains that are genuinely safe to run in parallel (e.g. per-lead reply triage). Set 0 to disable the lock entirely (advanced).

set_workflow_step_condition

Attach (or clear) a condition on a chain step. The step only runs when the condition evaluates true against the accumulated chain context. Optionally jump to else_jump_to (1-based) when false. Pass condition: null to clear an existing condition.

set_workflow_step_parallel_group

Tag a step with a parallel_group. Adjacent steps sharing the same group run concurrently via Promise.all. Pass parallel_group: null to make the step sequential again.

set_workflow_step_retry

Configure retry policy on a chain step. Transient failures (rate limits, 5xx, agent timeouts) are retried with exponential backoff before the step is recorded as failed. Set max_attempts: 1 (or pass null) to disable retries. Capped at 5 attempts and 30s backoff per attempt.

store_agent_memory

Store a new learning/insight for the agent. Use this when you discover something about the workspace, their ICP, messaging patterns, objections, or preferences.

submit_workflow_feedback

Submit human feedback on a chain step — used to improve agent performance. The feedback is stored in agent memory and influences future runs.

update_agent

Update a subagent configuration. Can change prompt, tools, triggers, or model.

update_workflow_step

Edit an existing step IN PLACE — agent fields AND the deterministic config of any step kind. Pass only what changes; everything else (condition, parallel_group, retry) is preserved. Use this to fix a typo’d url, a wrong args_template, a transform mapping or a switch case — do NOT delete and re-add for that: deleting shifts positions, and else_jump_to / switch goto store POSITIONS, so a delete+re-add silently re-points your branches. requires_tool_call=true means the step only counts as done when the agent actually CALLED a tool — use it on steps that must actuate (reply, book, escalate), so a text-only turn is recorded as failed instead of a green run that changed nothing. The step KIND is not editable (a http_request is not a tool_call) — for that, delete and add. To change which AGENT runs a step, also delete + add (preserves the audit trail).

weaken_memory

Weaken a memory when contradicting evidence is found. Decreases confidence.

Analytics

Funnel, campaign stats, ICP performance, timelines, qualification feedback insights

get_campaign_stats

Get aggregate campaign stats (email: sent/opened/replied/bounced; LinkedIn: sent/connected/replied).

get_feedback_insights

Get AI-generated insights from pipeline feedback: what works, what doesn’t, and recommendations.

get_funnel

Get lead funnel overview (counts by status: pending, approved, contacted, replied, meetings, etc.).

get_icp_performance

Reply performance by ICP attribute (industry, company size, title, seniority). Rates are positive replies per CONTACTED lead. Only segments with ≥20 contacted leads are ranked (smaller ones are counted in lowSampleExcluded, never presented as top ICPs); read the returned note and never report a tiny-sample or excluded segment as a winner. No meeting metrics.

get_playbook_stats

Get per-playbook statistics (companies, leads, approval rates, sequence performance).

get_reply_chains

Get detailed reply chain analytics with lead, company, playbook, and sourcing metadata. Shows industry, company size, buying signals, and channel breakdowns.

get_sequence_comparison

Get A/B test sequence comparison data: which sequences and variants perform better.

get_timeline

Get daily activity timeline (leads contacted, opens, replies, meetings) for the last N days.

Autonomous Missions

Launch, monitor, and approve long-running autonomous missions

create_mission

Launch an autonomous mission: a long-running agent that plans and works toward a goal on the background worker, using read-only workspace tools (research, lead/company/pipeline analytics). It CANNOT send, enrol, or book — it pauses and asks for approval, and the platform executes any approved action. Use for open-ended work like “analyse why playbook X underperforms and draft a fix” or “research 20 lookalikes of our converts and propose a segment”. Returns a mission_id; poll with get_mission.

decide_mission

Resolve a mission that is waiting_approval: approve, reject, or request edits to what it proposed. Approving an action lets the PLATFORM execute it (e.g. the proposed outbound step) and resumes the mission; reject/edit resumes it with your guidance. Only valid when the mission status is waiting_approval.

get_mission

Get a mission’s full state: goal, status, living plan, recent event trace, registered deliverables (artifacts), and — if it is waiting_approval — exactly what it is asking to do so you can decide_mission.

list_missions

List this workspace’s autonomous missions (newest first) with their status. Filter by status to find ones awaiting approval.

Background Jobs

Queue and track long-running jobs in the background worker

bulk_agent_run

Run a workspace agent on multiple companies in the background. The prompt template supports placeholders: {{company_name}}, {{domain}}, {{industry}}, {{company_id}}, {{location}}, {{employee_count}}. Returns a batch_id for tracking progress. Use get_batch_status to monitor.

cancel_job

Cancel a pending background job. Cannot cancel running jobs.

enqueue_job

Queue a long-running job to the background worker. Use for tasks that take >5 minutes: pipeline runs with many companies, deep research on 50+ leads, long agent chains, bulk operations. Returns a job_id for tracking.

get_batch_status

Check the status and progress of a pipeline batch (enrichment, agent run, etc.).

get_job_status

Check the status of a background job by ID.

list_active_batches

List active pipeline batches (running enrichments, agent runs, etc.) for a playbook.

Blacklist

Manage domain/email blacklist entries

add_blacklist

Add entries to the blacklist. Supports single or batch add. Valid types: domain, email, company, person, phone, linkedin_url.

list_blacklist

List blacklist entries (blocked domains, emails, companies, persons, phones, LinkedIn profile URLs). Supports filtering by type and search. Valid types: domain, email, company, person, phone, linkedin_url.

remove_blacklist

Remove entries from the blacklist by their IDs.

Calendar

Calendar integration status and meeting outcomes

list_calendar_integrations

List connected calendar integrations with sync status, last sync time, and error state. Calendars are connected via Settings → Integrations.

update_meeting_outcome

Record meeting outcome after it has occurred.

Calendar Booking

Provider-agnostic check_calendar_availability + book_meeting that any agent can call. Dispatches to cal.com / Calendly via the adapter SDK.

book_meeting

Books a meeting on a sender’s connected calendar. Cal.com confirms directly. Calendly returns either a confirmed booking (paid Scheduling API plan) or a one-time scheduling link (free plan) — caller should embed the link in the next outbound reply when kind=‘link_only’. Use ONLY a slot returned by check_calendar_availability.

check_calendar_availability

Returns ISO 8601 start times of bookable slots on a sender’s connected calendar (Cal.com or Calendly) for the next N days. Use this BEFORE proposing or booking any specific time.

get_booking_link

Returns the public scheduling link to send to a lead so they can self-book. Use this when the lead prefers picking their own time over confirming a specific slot. Prefers the per-sender link (senders.metadata.calendar_link); falls back to the workspace’s connected Cal.com / Calendly booking URL — preferring whichever provider the sender is configured for.

Channels

Connect Slack, Teams, Discord, Telegram, WhatsApp, webhooks

create_channel

Connect a new messaging channel to this workspace. Generates a webhook URL for receiving messages.

Channel types and required credentials:

• slack: { bot_token, signing_secret } — optionally { channel_id, app_id }
• teams: { bot_id, tenant_id, app_password } — optionally { webhook_url }
• discord: { bot_token, guild_id, channel_id }
• telegram: { bot_token } — optionally { chat_id }
• whatsapp_business: { phone_number_id, access_token, verify_token }
• webhook: { secret } — generic HTTP webhook (inbound/outbound)
• email: { address, imap_host, smtp_host, username, password }

After creation, use the returned inbound_webhook_url to configure your messaging platform.

delete_channel

Disconnect and remove a channel from this workspace.

list_channels

List the CONTROL surfaces this workspace is operated through (Slack, Teams, Discord, Telegram) — they route messages to workspace agents. Use when you need to notify the team or find the channel id for send_channel_message. These NEVER send to a lead: lead outreach runs on the send accounts (E-Mail, LinkedIn, WhatsApp) through a Sequenz.

send_channel_message

Send a message to THIS workspace’s connected channel (Slack, Telegram, Discord). Strictly workspace-scoped — only sends to channels belonging to the current workspace. For Slack, sends via chat.postMessage. Supports plain text and markdown. Use this to notify the workspace, send daily summaries, or communicate with the team.

setup_slack_channel

Guided setup for connecting a new Slack workspace. Creates the channel and provides step-by-step instructions for creating the Slack app and configuring it.

test_channel

Test a channel connection by verifying credentials and sending a test message.

update_channel

Update a channel connection. Can change credentials, routing, agent, or config.

Conversations

View email/LinkedIn/WhatsApp conversation threads per lead

get_conversation_stats

Get conversation statistics: total replies, unhandled count, by channel breakdown.

get_lead_thread

READ the full message history with one lead — every message both directions, in order, across LinkedIn, E-Mail and WhatsApp. Use it BEFORE drafting a reply, before enrolling someone who may already be in a conversation, and whenever a human asks “what did we actually say to them?”. Accepts a lead id, e-mail, LinkedIn URL or name. By default it SYNCS from the provider first (LinkedIn via the connected inbox, E-Mail via the connected sender) because the local record is structurally incomplete — webhooks only deliver what a workspace happened to subscribe to, and a thread a colleague continued by hand on LinkedIn is otherwise invisible. Pass sync:false for a fast local-only read. Pairs with get_lead (who they are) and draft_reply / send_lead_reply (what to do next); list_conversations is the cheaper local-only sibling.

list_conversations

List conversations for a specific lead (email, LinkedIn, WhatsApp messages).

list_recent_replies

List recent inbound replies across all leads (for monitoring inbox).

Copy Generation

Generate personalized emails, LinkedIn messages, reply drafts, meeting prep

draft_reply

Generate an AI reply draft to an inbound message from a lead. Use this for email, LinkedIn, AND WhatsApp replies.

generate_meeting_prep

Generate meeting preparation notes for a lead (pain points, solutions, talking points).

Cost Monitoring

Monitor workspace spend (LLM + external services) and get ranked cost-optimization suggestions

get_cost_optimizations

Analyze workspace spend and return ranked, actionable cost-saving suggestions (model downgrades for routine work, oversized prompts, prompt-caching candidates, dominant services/steps) with estimated monthly savings. Returns the underlying summary too.

get_cost_summary

Get the workspace spend summary over the last N days: total USD split into LLM (ai_usage_log) and external services (service_usage_log), plus breakdowns by model, source, service, pipeline step, and day. Use this to monitor where money goes.

Custom Integrations

Connect ANY third-party provider by name + API key or vendor MCP URL (no allowlist)

connect_integration

Connect ANY third-party provider to this workspace by free-form name — the first step of the external-API play. Two shapes: pass mcp_url when the vendor ships its own MCP endpoint (its tools are DISCOVERED right here and are callable immediately — the result lists them), or api_key for REST providers plus docs_url, which is what you read to wire calls yourself. Both may be given: MCP for agent work, the key for Tabellen-Spalten (column volume belongs on direct HTTP). THE ACCESS IS VERIFIED BEFORE THE SLOT EXISTS: a key the provider rejects (or a value that is plainly not a key) returns an error and creates nothing — do not retry the same value, read the reason and ask the user for the right one. Pass base_url so the check can actually run; without it the slot is created but flagged UNVERIFIED (verified: false in the result) and only proves itself on the first real run. An mcp_url that reports zero tools is treated as not connected. Idempotent per vendor name: calling again rotates the key and re-verifies. Pairs with: create_custom_tool (reference the slot via auth:{adapter_id} — never paste keys into configs), then workspace_table_add_column (per-row) or the tool_call workflow step (per-event). No allowlist exists — a vendor we have never heard of works the moment its access is stored.

disconnect_integration

Disconnect a provider from this workspace — the credential slot goes inactive, columns/tools referencing it fail with a NAMED reason on their next run (nothing is deleted silently). Use when a customer rotates away from a vendor or revokes access. Re-connecting later under the same name (connect_integration) reactivates the slot with the new key. Pairs with list_integrations (find the adapter_id).

list_integrations

What this workspace can reach, in two lists. CONNECTED: every provider wired up, with kind (adapter = we wrote the code and maintain it · integration = the vendor’s own API/MCP that we forward to), pays (platform_only = runs on OUR key against credits · own_key_only = the customer must bring a key, a blocking step · either = our key by default, their own optional) and docs_url. AVAILABLE: what is NOT connected yet but could be, same fields — so you can RECOMMEND instead of demanding a key we already pay for. Call this FIRST when a user mentions an external tool. Metadata only, never credentials. Connections the daily health check found broken are listed on purpose with status degraded plus last_error carrying its failure class in front (e.g. [auth_failed] …) — tell the user to re-connect rather than assuming it is gone. verified: false means something different: the access was stored but never proved against the provider (usually no base_url) — it may work, it just has not been shown to. A connection with NO verified field predates the check and says nothing either way; do not report it as broken. Pairs with connect_integration (a vendor in neither list), create_custom_tool (wire a call), find_tools (a tool that may already cover the need).

Custom Tools

Create/manage workspace-specific custom tools

create_custom_tool

Create a workspace custom tool — THE way to wire a connected provider’s API (the step after connect_integration: read the provider docs, then mint the call). The tool becomes available to every agent in this workspace, as a Tabellen-Spalte (workspace_table_add_column) and as a Workflow tool_call step. House recipe: get_play(‘external_api_to_column’). Check list_custom_tools first to avoid duplicates; verify with test_custom_tool before wiring.

Handler types:

• http_webhook: Calls an external HTTP endpoint. Config: { url, method, headers, body_template, auth: { adapter_id, credential_key?, header?, scheme?, username?, key_position? } } — auth references the workspace credential slot (list_integrations). A pasted key is REFUSED, not discouraged: a secret in headers, in auth_header (deprecated) or in the URL query fails create/update with a named error, including a precomputed base64 of one. Read the provider docs for its auth SHAPE and pick one: scheme ‘Bearer’ (default on Authorization) · header ‘X-API-Key’ with no scheme (bare value) · scheme ‘Basic’ — we base64-encode for you, key as password with username ” by default, or key_position ‘username’. A secret in the URL/query is refused (run records keep URLs). The url may carry {{placeholders}} filled from the call: url ‘https://api.vendor.com/v1{{path}}’ with method ‘{{method}}’ makes ONE tool cover the provider’s whole API (input picks path + verb). The origin must be literal in the config — input chooses the path, never the host, because the workspace credential rides along.
• supabase_query: Runs a parameterized query. Config: { table, select, filters, single }
• javascript: Sandboxed JS logic. Config: { code } — receives ‘input’ variable, must return result
• chain: Chains multiple tools. Config: { steps: [{ tool_name, input_map }] }
• static: Returns templated response. Config: { response_template }

delete_custom_tool

Delete a custom tool from this workspace.

list_custom_tools

List the custom tools this workspace has defined (name, description, handler type, enabled). Call BEFORE create_custom_tool to avoid minting a duplicate — an existing tool that covers the need is always preferable. Pairs with: list_integrations (which provider credential slots exist to reference), test_custom_tool (run one), workspace_table_add_column (use one per row) and the tool_call workflow step (use one per event).

test_custom_tool

Run a custom tool once with sample input and see the real result — the verification step between create_custom_tool and wiring the tool into a Tabelle column or Workflow tool_call step. Executes the LIVE handler (a real HTTP call for http_webhook tools), so use a harmless sample. Also the ad-hoc way to answer a one-off question through a connected provider API without building anything permanent. Returns response_shape — a fingerprint of the response SHAPE (keys + types, never values): record it, and a later run reporting a different shape means the provider changed its answer and the tool needs re-deriving from the docs.

update_custom_tool

Update an existing custom tool. Can change description, schema, handler config, or enabled status.

Deals

CRM pipeline: list/get/create/update deals and move deal stages (first-class Deal entity)

create_deal

Create a deal for a lead/company. Stage defaults to the first pipeline stage; status is derived from the stage.

get_deal

Get one deal by id, or by lead_id (the lead’s open deal).

list_deals

List deals (CRM pipeline) with optional stage/status/playbook filters + pagination.

set_deal_stage

Move a deal to a stage (e.g. meeting_booked, closed_won). Status (open/won/lost) is derived; a reason can be attached.

update_deal

Update a deal’s fields (name, amount, currency, close_date, company/playbook link).

Deliverability

Email deliverability: inbox placement, recipient-ESP segments, inbox health, sender recovery. Toggle off to stop the module looking and proposing entirely.

get_deliverability_health

Email deliverability health from the latest monitoring run: per-inbox status/ESP/daily limit/warmup, plus campaign bounce/reply rates. Sourced from hourly/daily Instantly checks.

get_esp_segment_report

Recipient-ESP segment report (Gmail / Microsoft / T-Online·GMX / other): bounce and reply rate per recipient mailbox provider. Exposes a Microsoft-specific collapse that aggregate numbers hide.

get_placement_report

Inbox placement test results (Instantly Inbox Placement add-on): inbox / spam / missing rate per provider (Google / Microsoft / Yahoo) from the latest seed test. The direct “are we in spam” signal. Empty if the add-on is not active or no test has run.

resume_email_sender

Resume a paused/errored email sender (Instantly). Human-gated recovery step after investigating why it was auto-actioned. Restores to 50% of the pre-pause daily limit (min 15).

Enrichment

Contact enrichment (email, phone), company enrichment (tech stack, signals), and email validation

bulk_enrich_contacts

Enrich multiple contacts in batch (email + optional phone). Max 100 per batch.

enrich_contact

Find verified email and phone for ONE contact via the connected contact-enrichment integration. Paid per lookup — for a whole leadlist prefer an enrichment COLUMN on the Tabelle (workspace_table_add_column kind “enrichment”, category “contact_enrichment”) so the spend is capped by max_credits and the result lands on the row.

get_company_enrichment

Get enrichment details for a company: tech stack, recent news, buying signals, qualification data, and enrichment metadata.

get_enrichment_credits

Check remaining ZeroBounce email validation credits.

list_company_buying_signals

List companies with detected buying signals. Useful for finding hot leads and high-intent companies.

search_people_at_company

Search for people at a company by job title using Fullenrich People Search.

update_company_signals

Manually add or update buying signals for a company.

validate_email

Validate one or many email addresses via the connected email-validation integration. Pass email for a single address or emails for a batch — exactly one of the two. Charged per address in both forms.

Experiments

Messaging angles — create, list, promote the default narrative hook

create_messaging_angle

Create a new messaging angle — a distinct narrative hook for outreach (e.g. pain-point, social-proof, ROI-focused) that can be A/B tested against others.

list_messaging_angles

List all messaging angles — distinct narrative hooks used in outreach (e.g. pain-point, social-proof, ROI-focused). Each angle can be A/B tested.

promote_angle

Promote a messaging angle to be the default for its persona. Archives the old default.

Feed

AI-prioritized recommendations, lead context, custom feed cards

create_feed_action

Create a one-off custom action in the feed for a specific lead (e.g. ‘review contract’, ‘schedule demo’).

get_lead_context

Get full context for a lead: profile, company, conversations, and pending actions.

get_lead_intelligence

Everything known about a lead + company: profile, firmographics, signals+provenance, score/heat, enrichment, engagement, conversations, CRM/deal, relevant Wissen. The single holistic lead context — prefer this over get_lead_context when you need the full picture.

get_recommendations

Get pending agent recommendations (prioritized actions for the SDR).

pause_lead_sequences

Pause a lead’s active outreach sequences. Optionally generates a farewell draft (stored in replies queue for approval, never auto-sent).

Import

Import companies from CSV, CRM (HubSpot, Salesforce, Pipedrive), or other sources

crm_discover_tools

Discover what tools the connected CRM MCP server exposes. Shows available read tools organized by type (contacts, companies, search). Use this first to understand what data you can pull from the CRM.

crm_import_history

View past CRM import runs for this workspace.

crm_import_to_playbook

Import contacts and/or companies from the connected CRM MCP server into a playbook. Reads data via MCP (never writes to CRM), deduplicates against existing records, and creates new companies/leads. Triggers the pipeline automatically. Use crm_discover_tools first to find the right tool, then crm_preview_import to dry run.

crm_preview_import

Preview what CRM data would be imported into a playbook (dry run). Calls the CRM MCP server to pull contacts/companies, then checks for duplicates against existing records. Does NOT write anything.

crm_pull_data

Pull raw data from a CRM (contacts, companies, deals) for inspection or custom processing. Use crm_import_to_playbook to directly import into a playbook with dedup.

import_companies

Bulk import companies into a playbook. Provide an array of company objects with name and domain. Handles deduplication and triggers the pipeline automatically.

revert_company

Undo AI-generated changes on a company (ICP scoring, enrichment, custom fields).

Leads

List, filter, approve, reject, bulk-manage, import leads

approve_leads

Approve one or more leads for outreach.

bulk_lead_action

Perform bulk actions on leads: delete, move (to playbook), approve (with auto-enrollment), reject, or archive.

create_lead

Create one lead on the entity spine (name, company, contact details). Writes the canonical lead record — NOT a table row; to also track it in a Tabelle, add a row there and link it. For bulk imports use workspace_table_import_from_file or import_leads instead of looping this.

crm_push_leads

Push selected leads to the workspace CRM (HubSpot) with company data + conversation history. External side-effect is irreversible.

enroll_preflight

Check prerequisites before enrolling a lead in a playbook. Returns blockers (missing credentials, missing sequence, blacklist) without mutating state.

get_lead

Get one lead’s full record: profile, company, status, and conversation history. For the complete picture (signals, heat, enrichment, CRM stage, pinned Wissen) prefer get_lead_intelligence — this is the lighter read.

get_lead_counts

Get lead counts by status (funnel overview).

list_leads

List leads on the ENTITY SPINE (the workspace-wide lead records that sequences, replies and the CRM board share) with optional filters (status, playbook, pagination). Rows in a Tabelle mirror these via lead-linking — read table data with workspace_table_get; read the canonical lead state here.

revert_lead

Undo AI-generated changes on a lead (enrichment, copy, variables). Reverts only AI-written fields, not manual edits.

update_lead

Update lead fields.

update_lead_priority

Batch update priority scores for leads based on closed-loop optimization signals

update_lead_status

Update lead status (e.g. mark as meeting_booked, not_interested).

LinkedIn

LinkedIn search, profiles, company data, sequence management

enroll_linkedin_sequence

Enroll leads into a LinkedIn Sequenz — the gated transition from data to outreach: each lead gets its own enrollment that the stepper walks (connect → wait → message …, reply stops it). Provide manual steps or auto-generate from personalization variables. A LIVE EXTERNAL-WRITE action: sends will go out from the connected LinkedIn account — confirm with the human before enrolling, never speculatively. For bulk per-row enrollment from a Tabelle, prefer an outreach terminal column (send-gated) over looping this tool.

get_linkedin_sequence_stats

Get LinkedIn sequence stats, sender pool health, and active enrollments. IMPORTANT: without sequence_id/playbook_id the stats are org-wide across ALL sequences — including imported history from previous tools. Scope to one sequence for campaign-level truth.

linkedin_company_profile

Get a detailed LinkedIn company profile — name, description, industry, headcount, website, headquarters, specialties. Use when the user pastes a company LinkedIn URL or asks “tell me about company X on LinkedIn”. Accepts a full URL (linkedin.com/company/{slug}), a vanity slug, or a numeric company ID.

linkedin_search_companies_by_url

Search companies using a LinkedIn Sales Navigator search URL. Use when the user has a pre-built Sales Navigator search link. NOT for company page URLs (use linkedin_company_profile for those).

linkedin_search_people

Search people at a company on LinkedIn Sales Navigator by role and seniority. Use when the user says “find decision-makers at company X” or “who works at Y?”. Accepts a company name OR a LinkedIn company URL (linkedin.com/company/{slug}).

set_linkedin_enrollment_state

Change the state of LinkedIn sequence enrollment(s). Pass exactly ONE selector: lead_id (that lead’s enrollment), sequence_id (every enrollment in the sequence), or enrollment_id (one row). state: “paused” stops further steps · “active” resumes and recomputes the next step · “cancelled” ends one enrollment (enrollment_id only) · “retry_now” re-arms a FAILED enrollment so the cron resumes from the step that failed (lead_id only, Unipile-driven enrollments only). Unsupported combinations return the supported ones instead of failing blankly.

LinkedIn Engagers

Extract engagers (reactors + commenters) from any LinkedIn post and resolve their current employer — composable primitives for agent chains

extract_and_resolve_engagers

One-shot: extract engagers from a LinkedIn post AND resolve their companies. Use when the user asks “who engaged with this post and where do they work?” Returns post metadata, resolved engagers with company data, and resolution stats. For more control (filtering, concurrency), use extract_post_engagers + resolve_engagers_companies separately.

extract_post_engagers

Extract people who engaged with a LinkedIn post — reactors and commenters. Use when the user says “who liked/commented on this post?” or “get engagers from this LinkedIn post”. Accepts any LinkedIn post URL, URN, or numeric id. Returns each engager with name, headline, public_identifier, and engagement types. Does NOT resolve companies — chain with resolve_engagers_companies for that, or use extract_and_resolve_engagers for a one-shot flow.

parse_linkedin_post_id

Parse a LinkedIn post URL or URN into its components — kind (activity / ugcPost / share), numeric ID, and the Unipile path param. Use to validate a user-provided link before calling extract_post_engagers. No credentials required.

resolve_engager_company

Resolve a single engager’s current employer via LinkedIn profile lookup. Tries the rich LinkedIn profile endpoint, then /users fallback, then headline parsing. Use inside agent chains when you need to resolve one person at a time. For batch resolution, use resolve_engagers_companies instead.

resolve_engagers_companies

Batch-resolve companies for a list of engagers — typically the output of extract_post_engagers. Runs with configurable concurrency (default 5, max 20), respects Unipile rate limits. Returns resolved engagers with company data and stats (ok / no_positions / lookup_error / headline_fallback / unresolved). Use right after extract_post_engagers.

MCP Health

Check and refresh connected vendor MCP integrations

check_mcp_integrations

List all workspace MCP integrations and report their health. When refresh=true, re-discover and cache tool schemas. Returns credential_scope per adapter so external users understand which tools they cannot reach.

Outreach

Email campaigns, outreach sync, and campaign analytics

bulk_enroll_whatsapp

Enroll multiple leads into a WhatsApp 3-step sequence. Each lead needs a phone number. If whatsapp_account_id is omitted, the playbook-scoped sender is auto-selected (playbook_id required in that case). Idempotent — leads already enrolled (by lead_id OR phone) are silently skipped.

get_whatsapp_stats

Aggregate WhatsApp sequence stats for the workspace: active / completed / replied / failed / no_whatsapp counts plus total_sent messages.

list_outreach_campaigns

List campaigns/sequences in the CONNECTED outreach tool for a channel — each with its mappable copy variables (the {{placeholder}} names found in the campaign copy). Use these names as field_mapping keys when configuring an outreach column or enrollment. Adapter-agnostic: resolves the workspace’s connected tool by category. For the native WhatsApp/LinkedIn sequencer use get_sequence instead.

list_whatsapp_enrollments

List WhatsApp sequence enrollments for the workspace. Each row represents a lead enrolled in a 3-step WhatsApp sequence. Filter by status or playbook_id.

send_linkedin_message

Send a LinkedIn message to a lead via HeyReach.

send_whatsapp_message

Send an APPROVED WhatsApp message. Only use after user confirms the draft from draft_reply tool.

set_whatsapp_enrollment_state

Change the state of WhatsApp sequence enrollment(s). Pass exactly ONE selector: lead_id (that lead — and any other enrollment on the same phone number) or playbook_id (every enrollment for leads under it). state: “paused” stops further steps · “active” resumes and recomputes next_step_at from the current step delay (enrollments already past the last step are marked completed). WhatsApp has no per-enrollment retry or cancel — those states are rejected with the supported list.

Outreach Prep

Batch-prepare pending leads for sending: validate emails, hold invalid/role-based/off-ICP leads, regenerate link-free copy, mark ready

prepare_for_outreach

Batch-prepare a playbook’s pending leads for sending: validate emails (ZeroBounce), hold invalid/role-based/off-ICP leads (qualification_status=‘disqualified’), regenerate link-free copy for survivors, and mark them ready. Async with progress; idempotent — re-run to pick up new pending leads.

Playbooks

Create, edit, clone, delete playbooks and personas; link/unlink/list a playbook’s Tabelle references (the v2 “Bausteine” reference bundle — by reference, never a copy)

approve_playbook

Approve a draft playbook for use in pipeline.

clone_playbook

Clone a playbook with its personas and sequences.

create_persona

Create a persona for a playbook — define target job titles, seniority, messaging tone, challenges, goals, objections, value props, and CTA.

create_playbook

Create a new playbook with full configuration — ICP, messaging, offer, qualification, research instructions, and all settings.

create_playbook_campaign

Manually create an outreach campaign for this playbook.

create_playbook_from_template

Create a new playbook from a pre-built template. Includes all config and personas from the template.

delete_persona

Delete a persona from a playbook.

delete_playbook

Delete a playbook.

get_playbook

Get full playbook details including all fields, personas, and sequences.

link_playbook_campaign

Link an EXISTING outreach campaign (by external campaign id) to a playbook. Use when a campaign was already created in Instantly/HeyReach and the playbook should adopt it instead of creating a new one. channel=“email” links Instantly, channel=“linkedin” links HeyReach. Creates the sequence row if missing.

list_personas

List all personas for a playbook.

list_playbook_templates

List available pre-built playbook templates. Returns slug, name, description, channels, and persona count.

list_playbooks

List all playbooks in the workspace with status, ICP summary, and lead counts. Use get_playbook for full configuration details.

playbook_table_link

Verknüpft eine Tabelle (workspace_table) mit einem Playbook — als Referenz, nie als Kopie. Das Playbook-Bundle („Bausteine”) referenziert damit das Tabellen-Segment; die Tabelle selbst bleibt unverändert und kann von mehreren Playbooks referenziert werden. Optionales label benennt die Rolle der Referenz (z. B. „Sourcing”). Pro (Playbook, Tabelle) gibt es genau eine Verknüpfung — erneutes Verknüpfen aktualisiert das Label. Ist Playbook oder Tabelle unbekannt (oder die Tabelle gelöscht), wird nichts geschrieben und eine klare Fehlermeldung zurückgegeben.

playbook_table_unlink

Löst die Referenz eines Playbooks auf eine Tabelle. Die Tabelle selbst und ihre Zeilen bleiben unverändert; nur die Verknüpfung dieses Playbooks wird entfernt. Idempotent — eine nicht vorhandene Verknüpfung ist ein No-op.

playbook_tables_list

Listet die Tabellen-Referenzen eines Playbooks — je Referenz die Tabelle (id, name, entity_binding), ob sie archiviert ist, die Anzahl aktiver Zeilen, das optionale Label und wann die Referenz erstellt wurde. Zusammen mit playbook_assets_list ergibt das das vollständige Referenz-Bundle („Bausteine”) eines Playbooks.

set_playbook_status

Change a playbook’s lifecycle status — pause, resume (active), archive, or move through draft/approval. Use this to archive or pause/resume a playbook; update_playbook does NOT change status. To remove a playbook entirely, use delete_playbook instead.

update_persona

Update a persona — modify job titles, seniority, department, challenges, goals, objections, value props, tone, or CTA.

update_playbook

Update any playbook fields — ICP, messaging, offer, qualification, research instructions, senders, channels, steps, and all settings.

Replies

Review, approve, edit, bulk-manage pending reply drafts

approve_reply

Approve and send reply draft(s) from the queue. Pass reply_id for one or reply_ids for several — exactly one of the two. Sends immediately; there is no undo.

backfill_replies

Import historical replies from connected outreach platforms (Instantly, HeyReach) into the workspace. Idempotent — re-running with the same since window does not duplicate.

edit_and_send_reply

Edit a reply draft and send the edited version.

get_reply_feedback_history

Get reply feedback history: how drafts were handled (approved, edited, rejected) with edit distances and classification data. Useful for analyzing reply quality.

list_replies

List pending reply drafts in the reply queue with lead and conversation context.

reject_reply

Reject reply draft(s) — removed from the queue without sending. Pass reply_id for one or reply_ids for several.

Reply-to-Meeting (lead-centric)

Lead-centric booking actions the reply-to-meeting Workflow uses: book_meeting_for_lead (book + mark lead booked), send_lead_reply (send the queued draft), escalate_reply (hand back to a human). Availability/pause/self-book links reuse the generic calendar + lead tools.

book_meeting_for_lead

Books a meeting on the sender’s calendar FOR a specific lead and marks the lead meeting_booked (persisting the booking id). Use ONLY a slot from check_calendar_availability. Calendly free plan returns a scheduling link instead — embed it in the next reply. Prefer this over the generic book_meeting when acting on a lead.

escalate_reply

Hand the conversation back to a human: marks the lead needs_review and files a pending escalation for the operator. Use when the lead declines, asks something sensitive, or the agent is stuck.

schedule_reply_followup

Schedule a chase reply N hours from now if the lead has gone silent (typically 24/48/72h). Use only while waiting for the lead to commit to a time. Fires a one-shot follow-up run for this lead.

send_lead_reply

Sends the lead’s queued draft reply on their active channel (email/LinkedIn/WhatsApp). Write only the message body — no salutation. Never paste a booking URL; set include_scheduling_link=true and the correctly lead-attributed link is appended. Requires a reply-queue draft (draft_id) for this lead.

Research

Research companies, qualify against ICP, find leads

find_companies

Find companies matching ICP criteria (industries, size, regions, tech stack, buying signals).

find_leads_at_company

Find decision-makers at a company by role/title. Returns name, title, LinkedIn URL.

qualify_company

Qualify a company against a playbook ICP. Requires research data. Returns qualified (bool), score (0-100), reasoning.

research_company

Research a company to get industry, size, location, products, LinkedIn URL, competitors, and recent news.

research_web

Research any topic on the web. Uses AI-powered deep web research to answer questions, gather information, or investigate topics. Returns a detailed text response.

scrape_page

Scrape a web page and return its text content. Useful for reading articles, documentation, product pages, or any public URL.

search_web

Search the web for a query and return a list of results with titles, URLs, and snippets. Good for finding specific pages, articles, or resources.

Research Agent Setup

Connect Research Agent via MCP URL to discover and use all research tools in chat

connect_research_mcp

Connect your Research Agent via MCP URL. Discovers available tools and makes them usable in the Command Center.

Runs

One monitoring read over every execution — table Abläufe, Workflow runs, sourcing runs (the Run primitive)

list_runs

ONE monitoring read for every execution in the workspace — table Abläufe (column runs, imports, source fills), Workflow runs, sourcing runs, and queued/running background JOBS — merged onto one row shape: source, title (never a raw id), kind, status, item counts, credits_used, error, timestamps, dry_run flag. The entry point for “what is running / what just happened / what failed?” across all four engines; drill into a specific run with the engine’s own tools (workspace_table_run_health, diagnose_workflow_run, check_sourcing_progress, get_job_status). Filter by status (running | succeeded | failed | cancelled), source (table | workflow | sourcing | job), and limit (default 50, max 200).

Sales Blueprint Brain

Manage the workspace Sales Blueprint Brain — knowledge base and feedback

analyze_icp

Derives the ICP from CLOSED deals — which segments actually convert and which only ever lose — and by default writes the winner out as a draft Playbook (ICP fields, good/bad-fit criteria, qualification prompt, personas). Use this when a workspace asks “who should we sell to”, before building a sourcing list, or after a quarter of deals has closed. Reads a connected CRM (HubSpot) when there is one, otherwise the workspace’s own deals — so it works without any integration. Also refreshes the Sales Blueprint icp_definition + personas sections; touches no other section. Needs at least 5 deals and at least one WON deal for the playbook. Pair with get_playbook to review, approve_playbook to activate, source_companies to fill it.

extract_from_document

Extracts sales knowledge from an uploaded workspace document and merges it into the Sales Blueprint Brain. Supports PDFs, Word docs, text files. The extraction classifies content by blueprint section (ICP, personas, objections, copy patterns, etc.).

get_blueprint

Returns the workspace Sales Blueprint Brain — full or specific sections. Use this to read the current ICP, copy patterns, personas, objection playbook, and other strategic knowledge.

rate_meeting

Stores a meeting outcome rating for a lead. Used to refine ICP and personas — qualified meetings reinforce targeting patterns, disqualified meetings flag segments to avoid.

rate_reply

Stores a reply quality rating for a lead. Used to train copy patterns — great/good replies reinforce what worked, bad replies flag what to avoid.

seed_blueprint_from_crm

Seeds the workspace Sales Blueprint Brain from connected CRM data (HubSpot MCP). Fetches won/lost deals, contacts, and company info via HubSpot MCP tools, then generates ICP, personas, objection playbook, and copy patterns. Requires HubSpot MCP integration to be connected.

update_blueprint_section

Updates a specific section of the workspace Sales Blueprint Brain. Creates the blueprint if it does not exist yet. Logs the change to the changelog.

Senders

Manage email and LinkedIn sender accounts, LinkedIn pool health and warmup

create_sender

Create or update a sender (one person with their contact data, signature, and linked channel accounts). Idempotent by email — calling this twice with the same email updates the existing row instead of creating a duplicate. Pass only the fields you have; account IDs are optional and can be linked later via update_sender. Use list_available_accounts first to get valid Unipile account_id values.

delete_sender

Delete a sender. Use force=true to remove even if used by playbooks.

get_sender_pool_health

Get LinkedIn sender pool health: warmup progress, daily limits, sends today, and account status for all connected LinkedIn accounts.

list_available_accounts

List all connected channel accounts (email, LinkedIn, WhatsApp via Unipile) that can be linked to a sender. Shows current assignment so the chat can pick accounts that are not yet linked. Use this BEFORE create_sender or update_sender to get valid account_id values.

list_senders

List all senders (persons with linked email/LinkedIn/WhatsApp accounts) for the workspace.

list_unipile_connections

List ALL Unipile accounts for this workspace with their connection status (connected / pending / disconnected / error). Use this to troubleshoot connection issues or to verify that a newly-started OAuth flow finished. For picking accounts to link to a sender, prefer list_available_accounts (which filters to connected + shows assignment).

set_linkedin_plan

Set the LinkedIn plan type (standard or sales_navigator) for a sender account. Affects search and messaging capabilities.

start_unipile_auth

Generate a Unipile hosted-auth URL for the user to connect an email, LinkedIn, or WhatsApp account. The URL expires in 30 minutes. After the user opens the URL and authenticates, a webhook saves the account to this workspace — then call list_unipile_connections to verify it appeared. Use this as step 1 of any sender setup flow when list_available_accounts shows no accounts for the desired provider.

update_sender

Update sender contact data, signature, and linked channel accounts. Pass only fields you want to change. Account IDs must come from list_available_accounts (validated to belong to this workspace).

Sending Schedules

Reusable send windows (days, hours, pace, timezone, lead-local) that decide WHEN a sequence may send

sending_schedule_create

Create a reusable Sendefenster. Use it when a workspace sends into another market (“US-Zeiten”), needs a tighter window, or wants a pace (“nur alle 15 Minuten”). Attach it afterwards with update_sequence({sequence_id, schedule_id}). lead_local=true means the window is read in the LEAD’s timezone when it is known — 09:00 for the lead, not for you.

sending_schedule_list

List the workspace’s Sendefenster (sending schedules) — the reusable time windows that decide WHEN a Sequenz may send. Start here before setting a schedule on a sequence: update_sequence({schedule_id}) needs an id, and ids are not guessable. Exactly one schedule per workspace is the default (used by every sequence that has none of its own).

sending_schedule_update

Change a Sendefenster. It applies to EVERY sequence using this schedule from the next tick — no enrollment is rescheduled retroactively, a lead that was already due simply waits for the next opening.

Sequences

Create, edit, clone multi-channel outreach sequences

clone_sequence

Clone a locked sequence to create an editable copy (without campaign links).

create_sequence

Create a Sequenz — the per-lead touch plan on ONE channel (email, linkedin, or whatsapp): ordered steps with delays and copy, walked per enrolled lead over time. Starts as status draft with linear steps and runs its branching NATIVELY from the start (graph_mode on) — add conditions later with update_sequence({graph}) and they execute, no switch to flip. Optionally bind trigger signal types so a detected buying signal routes leads in deterministically. Nothing sends on create — sends start when leads are ENROLLED (enroll_linkedin_sequence, or an outreach terminal column on a Tabelle).

delete_sequence

Delete a sequence template. Empties its queue first (cancels in-flight enrollments referencing it); enrollment history survives. A sequence linked to an external campaign needs force=true — the external tool campaign is NOT stopped automatically.

empty_sequence_queue

Empty the native sequencing queue: cancel every in-flight enrollment (active/pending/paused) for a sequence template or a whole playbook, optionally one channel (linkedin, whatsapp or email — default all three). Cancelled leads never send and can be re-enrolled later. Terminal states (completed/replied/failed) are untouched.

get_sequence

Get sequence details and locked status. Pass simulate to also get a DRY-RUN timeline — the projected touches (node, channel, day-offset) a lead in that hypothetical state would experience. Pure projection: nothing is enrolled or sent.

list_sequences

List the workspace’s Sequenzen (the per-lead touch plans) — id, name, channel, status, step count, whether it runs the branching graph natively (graph_mode), whether it is locked to an external campaign, and its trigger-signal bindings. The discovery entry point for the Sequenz primitive: every other sequence tool needs an id, and ids are not guessable. Filter by playbook or channel to narrow.

release_sequence_leads

Release PAUSED leads of a manual-release Sequenz into the active send queues (paused → active across LinkedIn, WhatsApp and E-Mail). Use it after reviewing the per-lead copy: sequences with release_mode=manual birth every enrollment paused, and NOTHING sends until this release. lead_ids releases exactly those; limit releases the OLDEST n; neither releases everything paused. Note: in a manual-release Sequenz, paused IS the awaiting-release state — a batch release also resumes individually paused leads of this sequence. Enable/disable the gate itself with update_sequence({release_mode}).

update_sequence

Update sequence steps, a branching graph, status, or trigger-signal bindings. Linear steps and the branching graph are two representations of the same touch plan: set graph to author a BRANCHING sequence (nodes start|send|wait|condition|stop + then/else edges); omit it to keep linear steps. Cannot edit steps/graph if the sequence is locked (linked to a campaign); bindings stay editable. Set graph_mode=true to make NEW enrollments execute the branching graph natively — multichannel: LinkedIn, WhatsApp and email nodes hand off between steppers (email sends from the workspace’s connected mailbox with a hard daily cap; without a connected mailbox the email node parks with an honest reason). In-flight enrollments keep their snapshot. Without graph_mode, a stored graph is authoring/preview only and the linear stepper keeps running.

Social Listening

Monitor LinkedIn for posts by topic/keyword, scrape engagers, resolve companies, and run pipeline

create_social_topic

Create a new social listening topic for a playbook. Topics run on their own schedule defined by frequency_per_day (1–6 scans/day).

delete_social_topic

Delete a social listening topic. Past scans are kept; the topic_id on those rows becomes NULL.

get_scan_history

View past social listening scan results. Optionally filter by playbook or topic.

list_social_topics

List configured social listening topics for the workspace. Optionally filter by playbook.

run_social_scan

Run a social listening scan immediately. Pass either topic_id (preferred) or playbook_id (uses the playbook’s first enabled topic).

Each scan: searches LinkedIn for posts matching the topic keywords, scrapes engagers (post author + reactors + commenters), resolves their companies (with domain via search→profile lookup), creates leads, and runs the playbook pipeline.

scan_linkedin_post

Scan a specific LinkedIn post URL — scrapes engagers, resolves companies, creates leads, runs the pipeline. Uses the playbook for pipeline settings.

update_social_topic

Update an existing social listening topic — change name, keywords, threshold, frequency, target playbook, or enable/disable it.

Sourcing

Source companies from Google Maps, LinkedIn, post engagement, custom data sources

check_sourcing_progress

Check progress of LEGACY asynchronous sourcing runs (sourcing_runs rows: status, source, companies_created, error, timestamps). source_companies now enqueues table-source JOBS — watch those with list_runs instead; this tool only covers runs started by source_from_linkedin and the legacy pipeline engine.

create_data_source

Create a new QUELLE (data source) for this workspace. Its config describes how to call an external API and map the response to normalized company data. Use this after researching the target API’s documentation.

The adapter_config shape:

• base_url: API base URL
• auth: { type: “header”|“query”|“bearer”, key?: string, value_template?: “Bearer {{api_key}}” }
• request: { method: “GET”|“POST”, path: “/endpoint”, body_template?: { … }, headers?: { … } }
• polling (optional, for async APIs): { status_path, status_field, done_value, failed_values, result_id_field, interval_ms, timeout_ms }
• results (optional): { path?: “/results/{{id}}/items”, results_field?: “data.items” }
• field_mapping: { name: “response_field”, domain: “website_field”, phone: “phone_field”, … }

Use {{variable}} placeholders in templates — they get replaced with credentials + input params at runtime.

For an MCP-backed source (e.g. an Apify actor via mcp.apify.com), set connection_type=“mcp” and shape adapter_config as:

• mcp: { url: “https://mcp.apify.com”, auth: { type: “bearer”, credential_key: “api_key” } }
• call: { tool: “call-actor”, args: { actor: "", input: { … } } }
• result.async (Apify actors are async — call-actor returns RUNNING, so poll then fetch): { async: { dataset_id_path: “storages.datasets.default.id”, // NOT “defaultDatasetId” run_id_path: “runId”, status_path: “status”, poll_tool: “get-actor-run”, poll_args: { runId: “{{run_id}}” }, fetch_tool: “get-dataset-items”, fetch_args: { datasetId: “{{dataset_id}}”, limit: 500 }, items_path: “items” } }
• field_mapping: { level: “company”|“contact”, name: ”…”, domain: ”…”, … } (job-listing actors: map the hiring company name; a job title is a buying signal, not a company)
• credential_adapter: “apify-mcp” (resolves the platform Apify token) Set target_playbook_id so the feed lands in ONE playbook. Set credential_keys to [“api_key”] (the platform token satisfies it) or [] for none. NOTE: many actors (Indeed/StepStone) return job listings without a real company domain — that’s fine, companies import by name and the research step resolves the domain later.

create_webhook_source

Create an INBOUND webhook data source: a per-workspace ingest URL that external tools (RB2B, Snitcher via Zapier/Make, Clay, custom scripts) POST to. Returns the ingest URL + secret to paste into the external tool.

Exactly ONE target:

• target_playbook_id: each POST is mapped to a company (field_mapping) and inserted as ‘pending’ in that playbook — the normal pipeline runs on it.
• target_chain_id: each POST fires that Agent Chain; the body is available to steps/conditions as {{webhook.}} (n8n-style event trigger).

field_mapping (playbook target only) maps each company field to a dot-path in the webhook body, e.g. { “name”: “company.name”, “domain”: “company.website”, “industry”: “company.industry”, “employee_count”: “company.size” }. Supported company fields: name, domain, industry, country, city, linkedin_url, phone, employee_count. At least name or domain must be mappable.

delete_data_source

Delete a workspace-defined Quelle. Built-in Quellen cannot be deleted — disable them with toggle_data_source instead.

find_similar_to_converted

Use Research Agent to find companies similar to leads on this playbook that already replied / booked a meeting / converted. Inserts them as new companies with source=lookalike. Best for squeezing the long tail after Google Maps sourcing saturates.

get_pool_benchmarks

Benchmarks aus DEN EIGENEN Konversionen dieses Workspace (leads + companies, auf organization_id gefiltert), optional auf ein Playbook eingegrenzt: welche Branchen, Groessen und Regionen bei EUCH konvertiert haben. Trotz des Namens liest es NICHT den geteilten Pool — pool-weite Suche: search_pool; aehnliche Firmen zu Konvertierten: find_similar_to_converted. Ohne eigene Konversionen kommen leere Verteilungen zurueck, keine Marktzahlen.

get_pool_contacts_by_domain

Retrieve known contacts from the global company pool for a given domain.

introspect_mcp_source

EXPERIMENTAL. Point at any MCP server and figure out how to import its data into the pipeline. Three modes: (1) neither actor nor tool → lists the server’s tools so you can pick one; (2) actor set (Apify) → reads the actor’s input+output schema (free, no run) and returns a ready async config; (3) tool set → samples the tool once (small), detects sync vs Apify-async + where rows live, and proposes a field_mapping. Returns a ready-to-save config for source_from_mcp (test) / create_data_source (save daily). Never auto-saves.

list_data_sources

List every QUELLE (data source) configured for this workspace — built-in ones (Google Maps, Leads-Finder, …) and workspace-defined ones — with their enabled/disabled status. A Quelle fills a Tabelle with rows; it is not a Modul (column) and not a Tool. Pairs with create_data_source (add one), test_data_source (prove it returns rows) and workspace_table_add_source (attach it to a Tabelle).

list_pending_companies

List companies pending qualification for a playbook.

search_pool

Browse/filter the global company pool like a human would in the pool UI — read-only, nothing is imported. Filter by industry, location, country, employee/revenue range, sources, has-email/phone/linkedin and last-seen dates, or pass query for semantic free-text search (“Logistikunternehmen mit eigener Flotte”). Returns compact company rows with a contactCount. To then pull results into a playbook, call source_from_pool with the same filters or with the exact domains you picked.

source_companies

Source companies matching a playbook ICP into the playbook’s linked company Tabelle. Derives the search terms from the playbook ICP (industries × regions), then enqueues ONE consolidated table-source run — the fill runs in the background as a job (watch it with list_runs; rows appear in workspace_table_get). source picks the source module: ‘scraping’ (Maps, default, paid), ‘lead_sourcing’ (lead database, paid), ‘pool’ (platform pool, free). A PAID source REQUIRES a positive max_credits (money-audit). Needs a company-bound Tabelle linked to the playbook (playbook_table_link) — to fill an arbitrary Tabelle with your OWN query instead, use workspace_table_add_source.

source_from_linkedin

Source companies from any LinkedIn URL. Accepts both Sales Navigator search URLs and LinkedIn post URLs. Auto-detects the type: post URLs extract engagers (likes/comments), search URLs import companies from SN results. Runs SYNCHRONOUSLY over your connected LinkedIn (Unipile) and reports the companies it created — no cron delivers results later. Uses your LinkedIn account, so it is bounded by that account’s limits.

source_from_mcp

EXPERIMENTAL. Source B2B companies/leads from a remote MCP server (e.g. Apify MCP at https://mcp.apify.com) into a playbook as pending records. Generic: point it at any MCP url + tool + field mapping. Handles Apify-style async (call-actor → get-dataset-items) via the result.async config. level=“company” inserts companies; level=“contact” inserts companies then leads attached by domain. Runs synchronously and may take up to ~150s while the remote tool works (long Apify actors can exceed this — prefer fast actors for the experiment). Additive: does not touch the normal sourcing pipeline.

source_from_pool

Source companies + leads directly from the global pool into a playbook. Three modes: (1) pass domains to import an exact selection (e.g. picked via search_pool); (2) pass filters (industry, location, country, employee/revenue range, …) to import the most recently seen matching companies; (3) pass neither and the most-recent N pool companies are taken. All modes only create leads with a usable email (valid/catch_all), dedup by domain, and run the pipeline so imports get qualified against this playbook’s ICP.

test_data_source

Test a Quelle with a lightweight auth check — the proof that its access works BEFORE a scheduled run depends on it. Pairs with toggle_data_source (park a broken one).

toggle_data_source

Enable or disable a Quelle. A disabled Quelle is skipped in the sourcing waterfall — use this instead of deleting when a provider is temporarily unusable.

update_data_source

Update a Quelle: its request config, its priority in the sourcing waterfall, or its metadata.

System Overview

Explain the platform model — primitives, object model, governance — to an agent orienting itself (explain_system), plus the setup+debug contract for Workflows/Sequenzen/Tabellen: which tool writes which config field, what the runtime actually executes, and what dry_run really simulates (automation_capabilities)

automation_capabilities

Read the SETUP + DEBUG contract for Workflows, Sequenzen and Tabellen before you build or debug one — so you never have to discover a limit by trial. Returns: workflow (step-level + workflow-level config fields, each with the exact MCP tool that writes it and what the engine does with it), sequence (same for touch plans, incl. the branching graph), debug (which read tool answers “what did this run actually do” per primitive), dry_run.simulated_tools (the ONLY tools that no-op under dry_run — anything else your agent step calls executes for real during a rehearsal), and stored_but_not_executed (config you CAN write that the live runtime ignores today, with the reason — e.g. a branching sequence graph is authoring/preview only, and sequence status is not an execution gate). Read-only, no side effects.

explain_system

Explain the GTM Automation platform model to an agent orienting itself: the 11 primitives (Workspace, Wissen, Tabelle/Spalte/Zelle, Sequenz, Workflow, Run, Integration, Playbook, Agent, Command, Feed), the house plays index (call get_play for the steps), the object model, the HANDOFF matrix (handoffs — every connection between Wissen, Playbook, Quelle, Tabelle, Sequenz, Workflow, Signal and Feed: what creates it, with which tools, plus myths: the connections that do NOT exist and what to do instead), the governance rules every agent MUST follow, how to operate, the holistic Lead Intelligence read (get_lead_intelligence), the v2/classic product profile, and recommended first tool calls. Call this first when connecting fresh, or any time you need the orientation again as structured JSON — it is the same content as the server’s initialize instructions.

get_play

Get the HOUSE BUILD ORDER for a standard GTM motion — the ordered steps, which tools to call at each step, WHY each step sits where it does, and the guardrails. Use it BEFORE building when a request matches a known motion, instead of deriving an order from tool names: “source leads, qualify them and build a LinkedIn sequence” → lead_list_to_outreach; “every day new matching companies” → recurring_source; “enrich this list I already have” → enrich_existing_list; “when X happens, do Y” → event_to_action. Call with no id to list the available plays. Getting the ORDER wrong is the expensive mistake here — running a column before its source filled the rows, or paying to enrich rows that qualification was about to discard.

Tool Modules

Enable, disable and configure the workspace’s tool modules

configure_tool_group

Set configuration for one tool group in this workspace (default settings, provider preferences). Merges into the existing config rather than replacing it. Pair with list_tool_groups to see current values.

disable_tool_group

Switch a tool group OFF for this workspace — its tools stop being offered to agents. Use it to narrow what an agent can reach. Core groups cannot be switched off. Pair with list_tool_groups.

enable_tool_group

Switch a tool group ON for this workspace, so its tools become callable by Command and the workspace agents. Pair with list_tool_groups to get the id. Takes effect immediately.

list_tool_groups

List the tool GROUPS available to this workspace and whether each is on. Use it before enable_tool_group / disable_tool_group, or when a tool you expected is missing from your list — a switched-off group is the usual reason. Not to be confused with a Modul (an addable Spalte in a Tabelle).

Triggers

Event-driven automation triggers (events, schedules, keywords, thresholds)

create_trigger

Create a new automation trigger. Types:

• event: fires on system events (lead_replied, meeting_booked, etc.)
• schedule: fires on cron schedule
• keyword: fires when keyword detected in message
• threshold: fires when metric crosses threshold
• pipeline: fires at pipeline step completion

delete_trigger

Delete an automation trigger.

get_trigger_log

View recent trigger execution history. Shows when triggers fired, results, and errors.

list_triggers

List all automation triggers for this workspace. Triggers fire agents automatically based on events, schedules, keywords, or thresholds.

update_trigger

Update an existing trigger configuration.

Website Scraper

Scrape company websites to find leads (cheap, Firecrawl + LLM-based)

scrape_leads_from_domain

Scrape a company website for leads matching specified roles. Uses self-hosted Firecrawl + LLM extraction + pattern-based email derivation. Cached 30 days per org+domain. Pass the real company name so the LLM can disambiguate employees from partners/testimonials.

Website Visitors

Identify companies visiting your website via Snitcher

get_visitor_details

Get detailed website visit data for a specific company domain. Shows all sessions, pages visited with time spent, referrers, and devices over the last 7 days.

get_website_visitors

Get recent website visitors identified by company. Returns company name, domain, industry, pages visited, time on site, and visit count. Use this to find companies showing buying intent by visiting the customer website.

Wissen

Operate Wissen assets (the workspace’s reusable, immutably-versioned knowledge: ICP, Persona, Offer, Positioning, Messaging Angle, Proof): list (optionally filtered by kind/status, e.g. status=proposed for pending proposals), read an asset with its current revision + history, create, revise (append revision), roll back the current-revision pointer, approve/reject a proposed asset, archive

asset_usage_list

Zeigt, wo ein Wissen-Asset verwendet wird — die Playbooks und Slots, die es referenzieren, mit dem Hinweis, ob die Bindung fixiert ist (pinned). Nützlich, um vor einer Änderung oder Archivierung die „Verwendet von”-Abhängigkeiten zu prüfen.

playbook_asset_pin

Bindet ein Wissen-Asset an einen Playbook-Slot (per Referenz; optional auf eine Revision fixiert). slot ist die Rolle und muss zur Asset-Art passen (icp, persona, offer, positioning, messaging_angle, proof, signal) — ein ICP-Slot nimmt nur ein icp-Asset. Ohne pinned_revision_number folgt die Bindung der jeweils aktuellen Revision des Assets (Verbesserungen wirken automatisch); mit pinned_revision_number wird sie auf genau diese Revision fixiert (reproduzierbar). Pro (Playbook, Slot) gibt es genau eine Bindung — erneutes Binden ersetzt die vorige. Passt die Art nicht zum Slot oder ist Asset/Revision/Playbook unbekannt, wird nichts geschrieben und eine klare Fehlermeldung zurückgegeben.

playbook_asset_unpin

Löst die Bindung eines Playbook-Slots (entfernt das an diesen Slot gebundene Wissen-Asset). Das Asset selbst und seine Revisionen bleiben unverändert; nur die Referenz dieses Playbooks für diesen Slot wird entfernt.

playbook_assets_list

Listet die Wissen-Asset-Bindungen eines Playbooks — je Slot das gebundene Asset (id, kind, name), die wirksame Revisionsnummer (die fixierte, sonst die aktuelle) und ob die Bindung fixiert ist (pinned) oder der aktuellen Revision folgt.

wissen_asset_approve

Entscheidet über ein vorgeschlagenes Wissen-Asset (z. B. ein vom System destilliertes Learning): approve schaltet es aktiv (fließt ab sofort in Prompts ein), reject verwirft es. Vorschläge findest du über wissen_asset_list mit status=proposed.

wissen_asset_archive

Archiviert ein Wissen-Asset (Soft-Delete: status = archived). Der Inhalt und die Revisions-Historie bleiben erhalten; das Asset erscheint nur nicht mehr als aktives Asset.

wissen_asset_create

Legt ein neues Wissen-Asset an (Revision 1). kind ist eine der Asset-Arten (icp, persona, offer, positioning, messaging_angle, proof, signal), name ist pro (Workspace, kind) eindeutig, content ist der typisierte Body dieser Art. Der Inhalt wird fail-closed validiert — unbekannte Felder oder ein fehlendes Pflichtfeld werden mit einer klaren Fehlermeldung abgelehnt, ohne dass etwas geschrieben wird. Ein signal-Asset beschreibt ein Kaufsignal (name, description, detection_hints, optional signal_type_key/strength) und referenziert über icp_refs/offer_refs die Asset-Ids bestehender icp-/offer-Assets dieses Workspace — die Referenzen werden ebenfalls fail-closed geprüft (Existenz, richtige Art, gleicher Workspace).

wissen_asset_get

Liest ein Wissen-Asset: seinen aktuellen Revisionsinhalt (typisierter Body je nach kind) plus die Revisions-Historie (Metadaten je Revision — Nummer, note, actor, Datum). Über die Historie erkennst du, welche Version aktuell aktiv ist und worauf du mit wissen_asset_set_revision zurücksetzen kannst.

wissen_asset_list

Listet die Wissen-Assets dieses Workspace — die wiederverwendbare, versionierte Wissensbasis (ICP, Persona, Offer, Positioning, Messaging Angle, Proof, Signal). Nur Metadaten pro Asset (id, kind, name, status, aktuelle Revisionsnummer, updated_at) — die Inhalte einer Revision holst du über wissen_asset_get. Optionaler kind-Filter grenzt auf eine Asset-Art ein; optionaler status-Filter grenzt auf active/archived/proposed ein — status=proposed findet die vom System vorgeschlagenen Assets (z. B. destillierte Learnings), die noch auf eine Entscheidung per wissen_asset_approve warten.

wissen_asset_revise

Erstellt eine neue Revision eines Wissen-Assets (revision_number = max+1). Standardmäßig ist sie ein VORSCHLAG: sie wird angehängt und ist lesbar, aber das Asset zeigt weiter auf die bisherige Version — {{asset.*}} löst also NICHT auf die neue auf, bis ein Mensch sie über wissen_asset_set_revision aktiviert. Mit activate: true wird sie sofort aktiv (nur wenn der Nutzer das ausdrücklich will). Revisionen sind unveränderlich — dies überschreibt nie eine bestehende Version. content wird wie beim Anlegen validiert (fail-closed). Optionale note dokumentiert die Änderung (z. B. die Learnings, aus denen sie stammt).

wissen_asset_set_revision

Setzt ein Wissen-Asset auf eine ältere Revision zurück (Rollback), indem der Zeiger auf die aktuelle Revision umgesetzt wird — der Inhalt wird nie verändert. Über wissen_asset_get siehst du die verfügbaren Revisionsnummern.

Workflow Steps

Per-step workers a Workflow calls: qualify companies, discover + enrich leads, enrich a lead, mark leads ready for outreach

discover_and_enrich_leads

Discover leads at a company and enrich with email/phone. Returns leads found.

enrich_lead

Enrich a single lead with email and phone via the lead_enrichment step.

qualify_companies

Qualify pending companies against playbook ICP. Returns qualification results.

sync_leads_to_outreach

Sync approved leads to their outreach sequence (Instantly for email, HeyReach for LinkedIn).

Workspace

Workspace settings, credentials, memory (facts, preferences, instructions)

create_notification_trigger

Create a custom notification trigger. Events: new_leads, reply_received, campaign_metric, pipeline_stage, meeting_booked. Conditions vary by event:

• new_leads: { vertical?, source?, min_count? }
• reply_received: { category? (positive_interest/negative/not_now/objection/neutral), min_count? }
• campaign_metric: { metric (bounce_rate/open_rate/reply_rate), threshold (percent), operator? (gt/lt, default gt) }
• pipeline_stage: { stage (e.g. “qualified”, “enriched”) }
• meeting_booked: {} (no condition needed)

delete_memory

Delete a workspace memory entry.

delete_notification_trigger

Delete a notification trigger.

generate_mcp_key

Generate or rotate the workspace MCP API key (used by external clients to call /api/mcp/[key]). Rotating invalidates the previous key immediately. Returns the new key once — store it; it is not retrievable in plain text from a UI later if lost.

get_mcp_key

Read the workspace MCP API key (used for /api/mcp/[key] external access). Returns null if no key has been generated yet.

get_settings

Get workspace settings and integration status (which integrations are configured).

get_setup_status

Snapshot of this workspace’s campaign-setup readiness: channel connections (email/LinkedIn/WhatsApp), senders, playbooks, and required integrations. Returns a list of concrete next_steps the agent can act on. Call this FIRST when a user asks to set up or launch a campaign — it prevents guessing and avoids skipping prerequisites. Refresh it between major actions (e.g. after connecting an account).

list_memories

List stored workspace memories (learned facts, preferences, instructions, contacts, context). Useful for understanding what the system knows about this workspace.

list_notification_triggers

List all notification triggers for this workspace.

list_prompts

List all pipeline-stage prompts with their defaults, current values, and override status.

memory_doc_append

Hängt einen gelernten Eintrag als neue Zeile an ein Speicher-Dokument an — legt es bei Bedarf neu an (z. B. beim ersten Learning zu einem Topic). Damit hält der Agent dauerhaft fest, wie er vorgeht, was der Nutzer bevorzugt, welche Fehler gemacht/korrigiert wurden oder was beim Debugging einer Chain herauskam. title wird nur bei Neuanlage verwendet (sonst automatisch aus dem Topic abgeleitet); ein sehr langes Dokument wird automatisch an den ältesten Zeilen gekürzt.

memory_doc_get

Liest ein Speicher-Dokument vollständig (kompletter Markdown-Inhalt) anhand seines Topic-Slugs. Übliche Slugs: campaign-playbook, user-preferences, mistakes-and-corrections, agent-debugging — es sind aber beliebige eigene Slugs erlaubt.

memory_doc_list

Listet die Speicher-Dokumente dieses Workspace — das selbstpflegende Markdown-Gedächtnis des Agenten (z. B. wie Kampagnen gebaut werden, Nutzer-Präferenzen, Fehler & Korrekturen, Agent-/Chain-Debugging). Nur Metadaten je Dokument (topic, title, updated_at, Zeichenzahl) — den vollen Inhalt liefert memory_doc_get.

memory_doc_revise

Ersetzt den Inhalt eines bestehenden Speicher-Dokuments vollständig (z. B. manuelle Bereinigung/Kuratierung durch einen Nutzer). Für einzelne Ergänzungen ist memory_doc_append besser geeignet — memory_doc_revise überschreibt den gesamten Inhalt.

reset_prompts

Remove all workspace prompt overrides, restoring defaults.

save_memory

Save a new workspace memory (fact, preference, instruction, contact info, or context about the organization).

set_prompt_overrides

Save pipeline-stage prompt overrides. Overwrites existing override for each key provided.

set_reminder

Set a reminder that will send a Slack notification at a specific time. Use when the user says “remind me”, “erinnere mich”, or asks to follow up later.

update_credentials

Update integration API keys (instantly_api_key, heyreach_api_key, hubspot_api_key).

update_memory

Update an existing workspace memory entry.

update_notification_trigger

Update a notification trigger (name, event, condition, enabled).

update_settings

Update workspace settings (offer_summary, sender_name, tone, language, notifications, etc.). Use notifications key to toggle Slack alerts per type: { notifications: { positive_replies: true/false, morning_briefing: true/false, meeting_prep: true/false } }. All default to true (opt-out).

Workspace Tables

Operate Tabellen (workspace database tables): discover every creatable capability (workspace_capabilities), read the relational schema (tables + columns + relation edges), list, create a table, soft-delete a whole table, add a column (incl. relation), update a column (name/run_condition/config), soft-delete a column, read rows, add a row, edit a manual/relation cell, soft-delete a row, trigger a column run, import a playbook’s companies/leads as entity-bound rows, build/refresh the “Positive Leads” list (sync_positive_leads — every positively-replied lead as a pure entity-bound view), fill/schedule company-row SOURCES (add_source / schedule_source / list_sources / delete_source), and save a table as a reusable workflow template + recreate a table from one (structure-only, validated)

workspace_capabilities

Discover EVERYTHING this workspace can do — the live, data-driven catalog of creatable capabilities, so you never have to guess what modules exist. Returns two blocks: columns (the add-column catalog grouped by ORIGIN — grundlagen = what the table itself does (manual/formula/AI/relation), unsere_tools = built and maintained by us (no key, runs on credits), verbundene_anbieter = the third-party providers THIS workspace connected, called directly against their API. Each item carries id, label, column_kind, category, cost_per_row, connected, selectable, backed_by (which connected provider actually answers a category module — otherwise you would be guessing), and the create_tool that creates it, e.g. workspace_table_add_column with create_kind) and sources (the company-row import sources — pool, scraping, lead database, Indeed jobs, generic scraper actor, LinkedIn post-engagers, job-change, lookalike, social listening, webhook — each with connected/suggested/paid flags and the create_tool that creates it, e.g. workspace_table_add_source or workspace_table_schedule_source). Org-scoped; reflects THIS workspace’s connected integrations. Use it to find a module’s id + the exact tool to call before creating a column or source.

workspace_schema_get

Read the workspace’s relational data model AND its Wissen assets: tables, columns, relation edges, and the reusable knowledge (ICP/Persona/Offer/Positioning/Messaging Angle/Proof) — call this to understand the workspace before operating on it. Returns every Tabelle (id, name, entity_binding, description) with its columns (key, name, kind, data_type); a ‘relation’ column additionally carries its RESOLVED edge (target_table_id, target_table_name, display_column), so the tables response is a graph — tables are nodes, relation columns are directed edges to their target table. Also returns assets — a list-level view of every Wissen asset (id, kind, name, status, current_revision_number; empty [] when none) — fetch an asset’s typed content body via wissen_asset_get. Also returns handoffs — the workspace’s CONFIGURED cross-substrate wiring (edges: enroll columns → Sequenzen, create_lead → Tabellen, workflow steps → Tabellen/Sequenzen/Feed, signal bindings) plus dangling: handoffs whose target is missing or archived — DEAD CONFIG that looks alive; check it before extending a motion, and fix or remove what it names. handoffs.legend is the RULE beside that state: every handoff that can exist (Wissen → Playbook → Quelle → Tabelle → Sequenz, plus the Workflow’s steps), through which mechanism and with which tools, and legend.myths — the handoffs that do NOT exist (a Sequenz never writes back into a Tabelle, a Playbook starts nothing) with the path to take instead. Read the legend BEFORE wiring anything new: an invented edge is configured, looks finished, and never fires. Org-scoped to this one workspace. Optional table (name or id) narrows the tables to a single table; relation edges still resolve names across the whole workspace, and the assets block always covers the whole workspace.

workspace_table_add_column

Add one column to an existing Tabelle (workspace database table). table accepts either the table name or its id. Kinds ‘manual’ (data entered directly, no config), ‘ai’ (config: { prompt, model?, output_schema?, role? }), ‘enrichment’ (config: { category, args_template, waterfall?, accept_when? }), ‘relation’, and ‘tool’ (config: { category, tool?, args_template? } — a terminal action-sink that acts on the row’s linked lead/company by capability CATEGORY; permits ‘crm’ and read-only/neutral categories, other send categories are refused at run time. OUTREACH TERMINAL variant: config { channel: ‘email’|‘linkedin’|‘whatsapp’, copy_mode?: ‘cells’|‘template’, copy_source_columns: string[] (‘cells’ mode), sequence_id: string (‘template’ mode — stored sequence template rendered per row), campaign_id?, list_id?, field_mapping? } — running it ENROLLS the row’s lead into the connected outreach tool’s campaign/sequence, contactability-gated + idempotent) are supported. relation: verweist eine Zeile auf eine Zeile einer anderen Tabelle; config { target_table_id, display_column }; data_type wird automatisch auf ‘reference’ gesetzt; Wert via update_cell = Ziel-Zeilen-ID. Every other kind (source/formula/system) needs a config payload only settable via the UI. Running an ‘ai’/‘enrichment’ column via workspace_table_run_column spends Credits einmalig pro erfolgreicher Zelle (success-only) — preview the spend with workspace_table_run_column mode ‘dry_run’ first; live runs require max_credits. The new column is appended after every existing one (position = max + 1).

workspace_table_add_row

Add one row to a Tabelle (workspace database table). values maps column key -> value; every key must already exist as a column on the table (create columns via the UI first) — an unknown key is rejected with the list of valid keys.

workspace_table_add_source

Fill a Tabelle NOW from a data source (one-shot company-row import) — the agent parity for ‘Firmen hinzufügen → Quelle’. table accepts a name or id. Pick a source module id (discover them via workspace_capabilities): ‘pool’ (free), ‘lookalike’ (free own-data), ‘scraping’ (Maps, paid), ‘lead_sourcing’ (lead database, paid), ‘indeed_jobs’ (hiring signal, paid), ‘generic_actor’ (any catalog scraper actor — needs actor_id + field_mapping{name:…}, paid), ‘post_engagers’ (LinkedIn post → engager companies, uses your LinkedIn). query/location/max_results feed the search. A PAID source REQUIRES a positive max_credits (money-audit). Returns the enqueued job id — the fill runs in the background (watch rows with workspace_table_get). For a RECURRING source, use workspace_table_schedule_source instead; ‘job_change’ is schedule-only.

workspace_table_cascade_preview

Simuliert den Ablauf einer Tabelle ab einer Spalte (oder ab allen Einstiegsspalten): welche Spalten liefen und was wäre der Worst-Case-Credit-Preis. Nur Vorschau — kein Verbrauch, keine Ausführung. Der Governance-Schritt VOR workspace_table_run_column bei bezahlten Spalten: erst Preis kennen, dann mit max_credits laufen lassen. row_count ist standardmäßig die aktuelle Zeilenzahl der Tabelle (live abgefragt); ein übergebener row_count überschreibt das. Die Kostenbasis pro Zelle entspricht der Worst-Case-Basis der max_credits-Obergrenze.

workspace_table_create

Create a new Tabelle (workspace database table) with its initial columns. Column positions are assigned by array order (first column = position 0). Kinds ‘manual’ (data entered directly, no config), ‘ai’ (config: { prompt, model?, output_schema?, role? }), ‘enrichment’ (config: { category, args_template, waterfall?, accept_when? }), ‘relation’, and ‘tool’ (config: { category, tool?, args_template? } — a terminal action-sink that acts on the row’s linked lead/company by capability CATEGORY; Phase 1 permits ‘crm’ and read-only/neutral categories, send categories (email/linkedin/whatsapp/voice) are refused at run time) are supported. relation: verweist eine Zeile auf eine Zeile einer anderen Tabelle; config { target_table_id, display_column }; data_type wird automatisch auf ‘reference’ gesetzt; Wert via update_cell = Ziel-Zeilen-ID. Every other kind (source/formula/system) needs a config payload only settable via the UI. Running an ‘ai’/‘enrichment’ column via workspace_table_run_column spends Credits einmalig pro erfolgreicher Zelle (success-only) — preview the spend with workspace_table_run_column mode ‘dry_run’ first; live runs require max_credits. Table names must be unique per workspace.

workspace_table_delete

SOFT-delete a whole Tabelle. The table stops existing in the list, schema, and grid, its in-progress runs are stopped, and its columns + rows are archived along with it — but the delete is REVERSIBLE by an operator (nothing is hard-dropped; cells are left untouched). REFUSED if another Tabelle still references this one via a relation column — remove those relation columns first. table accepts a name or id. Since a deleted table no longer resolves by name/id, calling this again on an already-deleted table returns a clean ‘not found’ rather than an error about the delete itself.

workspace_table_delete_column

SOFT-delete one column from a Tabelle. The column stops existing in the grid, filters and schema, stops running, and stops cascading — but the delete is reversible by an operator (the underlying row is archived, not destroyed; cells already computed are left untouched). REFUSED if another active column still references this one (via a {{cell.}} template ref in prompt/formula, or a run_condition leaf) — remove those references first. table accepts a name or id; column accepts a key or id.

workspace_table_delete_row

SOFT-delete one row from a Tabelle. The row stops existing in the grid, counts, and filters — but the delete is REVERSIBLE by an operator (the underlying row is archived, not destroyed; its cells are left untouched). table accepts a name or id; row_id is the row’s id. Idempotent: deleting an already-deleted row is a clean no-op.

workspace_table_delete_source

Remove a SCHEDULED source from a Tabelle by its id (from workspace_table_list_sources). Stops any future runs of that source. Org-scoped — a cross-workspace id is invisible (clean not-found).

workspace_table_dependencies

Zeigt den Abhängigkeitsgraph der Spalten einer Tabelle — welche Spalte welche referenziert, Einstiegsspalten, Zyklen.

workspace_table_export

Export a Tabelle as CSV text — the way a finished leadlist LEAVES the platform (agents/CLI pipe it to a file: gtm call workspace_table_export --table X --json). Returns { csv, row_count, truncated } with columns in grid order; structured cell values are serialized as JSON strings. Capped at max_rows (default 1000 here, hard ceiling 10000) — for bigger tables or an .xlsx file use the download route /api/app//database//export?format=csv|xlsx (browser, session-gated). Read-only, free.

workspace_table_from_pipeline

Generate a NEW Tabelle that mirrors a playbook’s LIVE pipeline as a column-per-step workflow (the pipeline → tables migration path). ADDITIVE + REVERSIBLE: it reads the playbook’s pipeline config and creates an INERT table (columns don’t run until an operator runs them) — the pipeline itself is NEVER touched, retired, or gated. Each ENABLED pipeline step becomes a column resolved by the SAME capability the step used (RULE #1, adapter-agnostic): pre_qualify/persona/copy → ai; qualification → enrichment/company_research; lead_discovery → enrichment/find_leads; lead_enrichment → enrichment/contact_enrichment; solar_analysis → enrichment/solar_analysis; outreach_sync → send-gated outreach terminal; crm_sync → CRM terminal. Columns are Domino-gated (is_not_empty on the prior column) reproducing the step cascade, and every column’s config is validated through the SAME validators a fresh column goes through. Steps with no column equivalent (disabled steps, social_listening — a SOURCE, or an outreach step with no copy column) are reported in unmapped_steps; non-recreatable columns in skipped_columns. Use workspace_table_from_pipeline to seed the table, then run columns explicitly. playbook accepts a name or id; new_table_name defaults to ’ (Pipeline-Tabelle)’.

workspace_table_from_template

Recreate a Tabelle from a saved template (see workspace_table_save_as_template): a NEW table + every column, validated through the SAME creation validators a fresh column goes through — an invalid definition can never create a broken column. Any column that can’t be recreated — a relation column whose old target table id has no entry in relation_table_map (old target_table_id -> an existing table id in THIS workspace), or a column of a kind that can’t be recreated at all (e.g. ‘source’/‘system’, typically from a previously-imported table) — is SKIPPED (never a broken/dangling column) and reported in skipped_columns. Org-scoped: only this workspace’s own templates are visible. template accepts a name or id.

workspace_table_get

Read a Tabelle (workspace database table): its columns and a page of rows. table accepts either the table name or its id. Paginated — limit defaults to 50 and is capped at 200; use offset for further pages.

workspace_table_import_from_file

Import a STORED spreadsheet (chat upload or import wizard) into a flexible Tabelle — by reference, so ALL rows are imported, not the truncated chat preview. Get the file_ref from the “[import_ref: …]” line of an uploaded xlsx/csv in the conversation. Same contract as workspace_table_import_records: mode “propose” (default) returns the AI structure proposal with zero writes; mode “apply” creates/reuses the table and inserts entity-bound onto the spine (idempotent by dedupe key). To CONSOLIDATE several files into ONE table, apply them one after another with the same proposal/table_name — duplicates are skipped, fields follow the data.

workspace_table_import_from_playbook

Materialize the playbook’s existing companies/leads into this entity-bound Tabelle as ENTITY-BOUND rows (the import path — binds each row’s entity_id to the real company/lead; idempotent by natural key; triggers the auto-cascade if the table is auto_advance). Use this instead of workspace_table_add_row when you want entity-bound rows sourced from a playbook. The table must be bound to leads or companies (entity_binding); an unbound table is rejected. table and playbook accept a name or id; max_rows defaults to 200.

workspace_table_import_records

Migrate EXTERNAL records (CRM export, Airtable, Lemlist, any API pull) into a flexible Tabelle on the ontology — flexible structured data, not a rigid schema. mode “propose” (default): the AI maps the record fields to a table structure (column keys, entity binding lead/company where detectable, dedupe key) and returns the proposal WITHOUT writing anything — review/edit it. mode “apply”: creates (or reuses, by name) the table and inserts the records ENTITY-BOUND onto the spine (leads matched by email, companies via the shared company resolver; idempotent by dedupe key — duplicates are skipped). Pass the proposal from the propose step (optionally edited); omit it to propose+apply in one shot. Max 500 records per call — repeat apply calls with the SAME proposal to append further batches.

workspace_table_list_sources

List a Tabelle’s SCHEDULED sources (workspace_table_sources) — id, launch, category, config, cadence, max_credits, max_results, label, last_run_at. Use the ids (and the stored config as the edit base) with workspace_table_schedule_source (update) or workspace_table_delete_source. table accepts a name or id.

workspace_table_run_column

Run a column on a Tabelle (workspace database table) — (re)computes a formula/ai/tool/enrichment column across all rows, or a subset via row_ids. RECOMMENDED FLOW for paid columns (ai/enrichment): call with mode ‘dry_run’ first — free and side-effect-free, returns {rows, estimated_credits, sample_inputs} so the spend is known before it happens; then run live with max_credits set. A LIVE run of a paid column REQUIRES max_credits (> 0, hard cap): once the run’s credit tally would exceed it, remaining cells are skipped with reason ‘max_credits_reached’ and the run completes partially. Live runs are asynchronous (background job, returns the job id — poll with workspace_table_get); dry_run answers immediately. No automatic retries.

workspace_table_run_health

Report a Tabelle’s per-column RUN HEALTH — for each column: total cells, succeeded / failed / skipped / pending / running counts, and the distinct provider error (or skip) messages ranked by frequency. This is the debugging read: it surfaces WHICH column is failing and WHY (e.g. a solar column skipping ‘no_coordinates’, an enrichment column erroring ‘rate limited’), so you can fix the column config. Optionally narrow to one column (key). Columns are returned most-broken first. truncated is true if the issue-cell sample cap was hit.

workspace_table_run_source

Run a SCHEDULED source NOW instead of waiting for its cadence — the missing counterpart to workspace_table_schedule_source. Enqueues EXACTLY the job the cron dispatcher would enqueue on the next due tick (same payload, same worker, same engine), so it is a real rehearsal of the scheduled run and not a lookalike: the one-shot workspace_table_add_source takes a DIFFERENT path (its config carries the values you just passed). Use it after editing a source (cadence/caps/config) to see the result immediately rather than up to 24h later. A paid source still needs its stored max_credits (> 0) — refused with that reason otherwise. Stamps last_run_at, so the next scheduled tick does not fire again right away. Returns the job id — follow it with list_runs.

workspace_table_save_as_template

Save this workspace’s OWN Tabelle as a reusable workflow template — a STRUCTURE-ONLY snapshot of its entity binding and every active column’s key/name/kind/data_type/config/run_condition. NEVER includes rows, cell values, or credentials (any credential-ish config key is stripped before saving). Use workspace_table_from_template to recreate a table from it later, in this or another workspace. table accepts a name or id.

workspace_table_schedule_source

Create OR update a SCHEDULED source on a Tabelle — the agent parity for ‘Geplante Quellen’. To CREATE: give table + source module id (‘pool’/‘scraping’/‘lead_sourcing’/‘indeed_jobs’/‘generic_actor’/‘lookalike’/‘job_change’/‘social_listening’/‘profile_posts’) + cadence (off/daily/thrice_daily). To UPDATE an existing one: give table + source_id + the fields to change (cadence/max_credits/max_results/label/config — a config edit is re-validated exactly like create). A newly created source defaults to cadence ‘off’ (INERT) — nothing runs until you set a cadence. A scheduled PAID source (scraping/lead_sourcing) REQUIRES a positive max_credits. ‘job_change’ takes a config { target_titles, recency_days, icp_scope, max_companies } and produces LEADS (recently-joined decision-makers). ‘social_listening’ is the LinkedIn keyword MODULE: config { playbook_id, keywords[], min_engagement?, max_posts? } — it owns its own managed topic (the 3h topics cron never double-scans it) and imports found companies/leads on every due tick. ‘profile_posts’ is the THOUGHT-LEADER module: config { playbook_id, profile_url, max_posts? } — it watches ONE person’s OWN posts (paste their profile URL) and imports everyone who engaged as LEADS, one row per person. Use it when the customer publishes on LinkedIn and wants their audience worked; use ‘social_listening’ when you want OTHER people’s posts found by search terms. The cron dispatcher re-fills the table from due sources. ICP-DYNAMIC: pass icp_playbook_id with source ‘scraping’ — the run then derives its search terms from that playbook’s ICP on EVERY run and skips the terms used in the last 7 days (the rotation the legacy daily runs had), so a daily cadence walks the ICP matrix instead of re-scraping the same query forever.

workspace_table_stop_run

Stop every in-progress run on a Tabelle (workspace database table) — the mirror of workspace_table_run_column. Flips the table’s ‘running’ runs to ‘cancelled’ and skips their still-queued cells; the worker checks the cancelled status before each remaining cell and halts, so NO new cell starts and no further Credits are spent (an already-executing cell may finish). Idempotent — returns { aborted_run_ids: [] } when nothing is running. table accepts a name or id. OrgScope-bound: only this workspace’s runs can be stopped.

workspace_table_sync_positive_leads

Build/refresh the “Positive Leads” list — a Tabelle holding every lead that replied positively (interested, meeting_intent, meeting_booked, meeting_held) as ENTITY-BOUND rows, so name/e-mail/title/status mirror the live lead. A pure VIEW: creates no deals, starts no sequences, spends no credits, never auto-runs columns. Idempotent — re-run to append newly-positive leads. Use active_within_days to keep stale bulk-imported “positive” leads out (e.g. 90 → only leads with activity in the last 90 days); omit it to include all. max_leads defaults to 500.

workspace_table_templates_list

List this workspace’s OWN saved table/workflow templates (id, name, description, column_count, created_at) — structure-only snapshots, no rows/cells. Use workspace_table_from_template to recreate a table from one.

workspace_table_update

Update a Tabelle’s table-level settings — its name, description, and the CO4 auto_advance toggle. table accepts a name or id. auto_advance is the chain-orchestrator opt-in: when true, inserting a NEW row auto-runs the table’s auto_run ENTRY columns (columns with no upstream deps), so the whole chain self-advances on every new row — auto-cascade spends credits without a human in the loop, so leave it off unless that is intended. Column-level auto_run is set separately via workspace_table_update_column. At least one field must be given.

workspace_table_update_cell

Update one manual or relation cell in a Tabelle (workspace database table) row. Columns of kind “manual” take any value matching the column’s data_type. Columns of kind “relation” take the id of a row in the relation’s configured target table as value — it is validated to be a real, in-scope row before the write (an unknown/foreign id is rejected with a clean error, no write); pass an empty value to clear the relation. Every other computed column kind (formula/ai/tool/enrichment/system) is rejected so agents never overwrite a run’s output.

workspace_table_update_column

THE agent path for editing an existing column — in particular its run_condition (the Domino gate: this column only runs for rows where the condition passes), and — for ‘ai’/‘enrichment’ columns — prompt/model/other config fields. table and column accept a name/key or an id. run_condition is a Condition tree ({all: […]} / {any: […]}, nestable up to 3 levels) or a leaf { column, op, value? } — op is one of is_empty/is_not_empty/equals/not_equals/contains/gt/lt/gte/lte, column must be another key on THIS table; pass run_condition: null to clear it (the column then always runs). A changed condition only affects the NEXT run, never retroactively. config is a partial patch merged onto the column’s stored config (ai/enrichment only) and re-validated — the contract field role is FIXED once a column exists (spec §5.75) and rejects any change with a clean error naming the fix (create a new column instead); output_schema is editable and hard-validated on every patch. kind can never be changed — it is not even accepted by this tool’s schema; create a new column for a different kind.

workspace_tables_list

List every Tabelle (workspace database/table) in this workspace with its id, name, entity binding, description, and row count. Use this to find a table’s id/name before calling the other workspace_table_* tools.