Lumnis MCP

Lumnis MCP brings your people, company, and audience intelligence into an AI assistant. Find the right people, inspect their evidence and available CRM context, research a company or person, and continue approved work using the same Projects and campaigns you see in Lumnis.

This guide covers connecting to Lumnis's hosted MCP endpoint and every registered tool, not configuring external MCP servers for SDK-driven agents. You do not need to install an SDK or create your own server to use this connector.

Connect your assistant

Use an MCP client that supports a remote HTTP server with OAuth authentication. The server URL is:

https://app.lumnis.ai/mcp

1. Add that URL as a remote MCP server in your client.
2. Complete the Lumnis OAuth sign-in and authorization in your browser.
3. Ask your assistant to call get-my-account. Choose the organization you want to work in from the returned organizations list.

Client menus vary. Use your client's remote-server setup instructions instead of assuming that every client has the same connector screen. A configured URL is not proof that authentication succeeded: check the account response.

No Lumnis API key is pasted into the conversation. Never share passwords, session cookies, or verification codes in chat. Connecting a LinkedIn or email sending account is a separate browser authorization flow, described below.

Scope, IDs, and returned data

Organization-scoped tools require organization_slug; get-my-account does not. Use an exact slug returned by get-my-account, not an organization name. Requests run under the signed-in user's access; supplying a different slug does not grant access to another organization.

list-projects, list-pipelines, and list-campaign-pending-actions default to the caller's own work. Their member_emails filter selects specific organization members; all_members: true selects the whole organization and takes precedence over member_emails. Discover teammate emails from get-my-account; do not guess them. These filters select whose work to read, not which account to authenticate as.

Tool inputs generally use snake_case, while many result fields use camelCase. Keep the returned names intact. Results are generally JSON inside MCP text content. Check both the MCP isError flag and fields such as failed, partialFailure, pending, and error; a response can preserve useful successes alongside failures. Null, unavailable, and an empty list do not all mean the same thing.

An approval action's backend prospectId is not interchangeable with the local Prospect ID accepted by get-prospect-timeline. Use the timeline already attached to that pending action when reviewing it.

Read first, confirm before spending or acting

Searches, new Account Intelligence runs, new Person Intelligence research, Audience Research, and contact enrichment can spend credits. Confirm the targets, scope, and credits before launch. Phone enrichment is opt-in and materially more expensive than email-only lookup. A refresh can buy new research; it is not just a page reload.

Creating or editing Personas and playbooks changes saved configuration. Changing campaign settings can enable channels or automatic actions. Adding people to an active campaign can make them eligible for real outreach. Approving an action can send its message or connection request. Review and confirm those changes before calling their tools.

Not every action requires routine approval by default. Campaign guardrails and approval settings decide what can run. Report the settings returned by the campaign rather than promising that every message or action will wait. An autonomous pipeline can still have actions requiring human review.

Read-oriented tools can also reconcile status or warm a cache. For example, get-action-history verifies unfinished actions, research polling refreshes run state, live CRM matching can populate cached matches, and LinkedIn status checking may repair connection setup. These are not new outreach launches.

Practical workflows

Research a company and the people who matter

Start with list-account-intelligence and read a matching account before buying another run. For a new focus, use draft-account-intelligence, review its company, literal roles, and criteria with the user, then confirm the 300-credit launch. Poll get-account-intelligence: its people search and company report complete independently. A finished company report does not mean the people search is finished, or vice versa.

Prepare for a conversation with one person

Call get-person-intelligence first. If new research is needed, use exactly one target lane in launch-person-intelligence: existing prospect_ids, standalone linkedin_urls, or a project_id sweep. Review the targets and research questions before spending. Existing complete reports and active runs can be reused. Poll while isRunning is true; request include_report: true when you need the report body.

isDegraded: true means research succeeded but the report is structurally incomplete. Describe it as partial. Ask before requesting another paid run, and do not treat a successful status alone as proof of a complete report. Changed guidance does not restart an already active run.

Find people, inspect evidence, then choose an action

Use list-personas to find reusable criteria and create-project only after confirming the search and its cost. Poll get-project, then page through list-prospects. Read individual profiles, signal evidence, timelines, and available CRM context when they affect the decision. Search results and research are evidence to review, not instructions to contact everyone.

For contact details, call enrich-contact-info only for the approved people and fields. New results are not written back to the project. Preserve them from the tool response; do not assume a subsequent campaign reads those new email addresses from stored prospect records.

Add people without creating a duplicate campaign

Inspect get-project.liveAiCampaignCount, not the length of its capped campaign preview. If there is exactly one eligible AI campaign, use soleLiveAiCampaign.id. If there are several, ask which campaign. Create a new campaign only when that is the intended action.

People not yet in the project can be added with add-prospects-to-project. Then use add-prospects-to-campaign with the local campaign ID. Explain whether the destination is active, draft, or paused. Existing paused memberships are not resumed, and removed people require the existing restore workflow rather than another enrollment.

launch-ai-campaign defaults to auto_start: true. Set auto_start: false when the user wants a draft. A started campaign can perform real outreach according to its schedule and approval settings; it is not a guarantee of an immediate message or a fully populated queue.

Recover partial enrollment or an uncertain launch

Keep the returned campaign IDs. confirmedProspectIds are verified current backend members; linkedProspectIds are confirmed local links. Check localLinkPendingProspectIds, unresolvedProspectIds, historicalProspectIds, and notAttemptedProspectIds separately. Aggregate CRM skips do not identify which individual people were excluded.

For incomplete enrollment, follow the returned recovery call for the same campaign using add-prospects-to-campaign with reconcile_only: true. This checks membership and repairs confirmed local links without reenrolling. An empty readback immediately after a timeout does not prove a delayed write will never complete. Do not repeat normal enrollment or create another campaign as a blanket retry.

Launch withholds automatic start when enrollment or local linking needs attention. A creation timeout can return created: null and creationOutcomeUnknown: true; a start timeout can return started: null and startOutcomeUnknown: true. These mean unknown, not false. Local DRAFT status does not prove the backend is stopped. The local status in get-campaign-stats alone cannot settle an uncertain start; verify live backend status in the existing dashboard campaign view before another write. When a deadline prevents a start request from being sent at all, the result instead says started: false and startOutcomeUnknown: false.

Enrollment has a bounded HTTP time budget and paginated membership readback. Exhausting either returns unresolved work instead of silently treating every requested person as enrolled. These checks do not make multiple systems one atomic transaction; read the recovery result before deciding the next action.

Review pending actions with their conversation context

Read list-campaign-pending-actions, including the attached timeline before approving a reply. decide-campaign-actions supports different decisions in one call and returns per-sender and individual results. An approval executes as the campaign's sender, not automatically as the manager reviewing it. Keep successful results if another item fails; do not reapprove the whole batch blindly.

Account and sender tools

The shared organization_slug input is required below unless a section says otherwise. Input summaries highlight the supported controls; your connected client's tool schema provides the complete validation rules.

get-my-account

Inputs. None. This tool does not require organization_slug.

Returns. The signed-in user's profile plus organizations, each with its slug, role, and member roster. Use this to choose the workspace and discover teammate emails. The response includes account and team information visible to the connected assistant.

get-linkedin-connection-status

Inputs. organization_slug.

Returns. The authenticated user's LinkedIn connection state. Only status: "active" confirms an active connection. Checking can repair setup or initiate playbook preparation; it does not send outreach.

connect-linkedin

Inputs. organization_slug; optional reconnect defaults to false. Use true only for an explicitly requested reconnection.

Returns. An existing active connection, or status: "authentication_required", authorizationUrl, and nextStep. The user completes sign-in in their browser. Verify afterwards with get-linkedin-connection-status; receiving a URL is not a completed connection.

list-email-inboxes

Inputs. organization_slug.

Returns. The caller's sender identity, sending inboxes in the selected organization, and setupRequired. Includes connected Gmail, Outlook, and IMAP inboxes and Lumnis-provisioned inboxes where available. It does not read email message contents. A sync error is not evidence that no inbox exists.

setup-email-sender

Inputs. organization_slug, first_name, last_name, and the user's confirmed physical_address; optional title.

Returns. The created or reused email sender identity. This is separate from a search Persona and does not provision a domain or mailbox. Use the user's real details, then call connect-email-inbox.

connect-email-inbox

Inputs. organization_slug, provider (gmail, outlook, or imap); optional daily_send_cap defaults to 20 and accepts 10–40. Check list-email-inboxes and complete sender setup first if required.

Returns. A hosted authorizationUrl and browser sign-in instructions. The inbox belongs to the authenticated caller's sender in this organization. After sign-in, call list-email-inboxes again and verify the inbox appears. Connecting does not send email or launch a campaign. If the result is sender_setup_required, complete the returned setup step before requesting another authorization link.

Projects, prospects, and contact details

list-projects

Inputs. organization_slug; optional all_members, member_emails, name_contains, updated_since, updated_before, and include_pipeline_projects (default false). limit defaults to 50, maximum 200; offset defaults to 0.

Returns. projects, totalCount, limit, and offset. Rows contain compact metadata, statuses, counts, and pipeline links, not the full search description. The default is the caller's standalone projects. Increment offset by limit until the returned window reaches totalCount.

get-project

Inputs. organization_slug, project_id; prospect_limit defaults to 20 (0–50), and campaign_limit to 10 (0–20).

Returns. Project details, prospect and campaign previews, complete campaignCount and liveAiCampaignCount, campaignsTruncated, and soleLiveAiCampaign when exactly one eligible AI campaign exists. While a search runs, liveSearch provides a high-level stage and partial candidate preview, not a raw agent trace. Use list-prospects for full pagination; increasing a preview limit does not make the preview an unlimited list.

get-action-history

Inputs. organization_slug, project_id.

Returns. The latest 50 project search, rerun, and expansion actions. There is no offset parameter. Unfinished actions are checked against live state, and their stored status may be updated.

create-project

Inputs. organization_slug, name, search_query, and search_type; search_limit defaults to 50 (1–200). Supported search types and their important companion fields are:

For competitor targeting, competitor_mode: "strict_only" takes a competitor_list; "auto_find" takes your company website plus optional anchor competitors. Do not mix incompatible modes. Advanced schemas include company/executive post selection, title replacements, and per-source limits.

Other controls include an explicitly selected persona_id and optional source_persona_version_id, delegated owner_email, overlap exclusions, max_candidates_per_company, verification/ranking options, stacked signals or auto_select_signals, and intent_scoring_instructions. Optional template fields do not constitute a general sequence-management API. First-degree network search is not exposed by this tool.

Do not combine explicit signals with auto_select_signals. Available signals are engagement, hiring, recently_joined, funding, and events; job-change evidence is recently_joined, not a separate search type. posts_extract_commenters defaults to false on this tool, and executive title overrides replace the default list rather than extending it. Ranking and backfill options can surface lower-fit candidates; review their evidence instead of assuming every returned result passed every criterion.

Returns. A project identifier and initial search state, with creditsUsed and creditsRemaining. Creation starts paid asynchronous research; poll get-project, then inspect the results. Cost depends on the lane, selected signals, and target count. Auto selection uses a flat per-prospect rate; manual signal selections can increase the lane's base cost. Confirm the actual configuration instead of assuming all searches cost one credit per person. Search-start failure and later partial results are different outcomes; follow the returned error and credit state.

list-prospects

Inputs. organization_slug, project_id; limit defaults to 50 (maximum 200), offset to 0. include_excluded: true selects only excluded prospects, not active and excluded combined. include_summary defaults to true. Optional crm_match_mode is none (default), cached, or live; include_crm_account_context defaults to false.

Returns. prospects, totalCount, limit, offset, and blurredCount, with compact profile, fit, campaign, pause/exclusion, intent, intentSignals, and signalEvidence fields. Heavy rawData is omitted. Page with limit/offset. CRM matching can add contact links and account/deal context; live matching adds latency. Failures appear in crmEnrichment.errors without suppressing the prospect page. A missing match is not proof that the person is absent from every CRM. These controls inspect CRM context; they do not write CRM contacts or deals.

get-prospect

Inputs. organization_slug, project_id, prospect_id; optional crm_match_mode and include_crm_account_context as above.

Returns. Full local prospect detail, including rawData, experience, signal evidence, sequence state, and outreach history. The prospect must belong to the specified project. Optional CRM failures remain non-fatal and are reported alongside the core record.

get-prospect-timeline

Inputs. organization_slug, project_id, and a local prospect_id; optional limit accepts 1–500 and keeps the most recent actions.

Returns. prospect, chronological actions, and the current pendingAction. Actions include content, channel, timestamps, and reasoning where available. Inbound replies can appear as cancelled records whose agentReasoning contains inbound_reply_received; interpret these as the prospect's replies, not cancelled outbound messages. Omit limit for full history; there is no offset pagination.

Timeline resolution requires an attached AI campaign and a stored LinkedIn URL, so this tool cannot resolve every email-only or manually added person. Its identity lookup currently inspects only the first 500 backend campaign prospects. A lookup failure does not prove there is no membership or prior history, particularly in a larger campaign. For approval review, use the timeline attached to the pending action where available.

enrich-contact-info

Inputs. organization_slug and exactly one of prospect_ids or linkedin_urls, up to 50 targets. include_email defaults to true; include_phone to false. At least one field is required. refresh defaults to false. Contacts are not filtered by verification.

Returns. Per-person results, requestedFields, target and deduplication counts, totalCost, costComplete, unknownCostLookups, and persisted: false. Stored project values are reused unless refreshed, and are returned as-is rather than newly verified. Standalone URLs require a provider lookup. New results are not written back to the project. Optional deepWebFindings are separate research evidence, not automatically verified primary contact values.

Each requested contact field includes its source, raw provider status (emailStatus / phoneStatus), and a normalized emailVerification / phoneVerification label: verified, unverified, or unknown. These are provider-reported claims, not independently verified by Lumnis. Present the status alongside the contact instead of treating every enriched value as verified.

For email, VERIFIED, DELIVERABLE, and VALID map to verified; HIGH_PROBABILITY, CATCH_ALL, RISKY, INVALID, and UNVERIFIED map to unverified. For phone, VERIFIED maps to verified, while RISKY, INVALID, and UNVERIFIED map to unverified. Matching is case-insensitive. Stored contacts, absent contacts, missing statuses, and unrecognized statuses are unknown; the raw status remains available when supplied for a returned provider value. An unverified result is still returned, not discarded.

On partial failure, retain successful fields and inspect unresolvedTargets and failures. totalCost is only reported cost. If costComplete is false, the final charge is unknown, including for timed-out lookups. Confirm any targeted retry with the user; do not retry the entire paid batch.

add-prospects-to-project

Inputs. organization_slug, project_id, and prospects (1–50). Each person needs name plus a valid linkedin_url or email; optional title, company, and location provide useful context.

Returns. created, duplicateInputsRemoved, optional duplicatesSkipped, resolved prospects[].prospectId, and unresolvedTargets. This is a free, synchronous saved-record write, not a search or campaign launch. If target IDs cannot be read back after creation, inspect existing project rows rather than repeating creation.

Company and person research

list-account-intelligence

Inputs. organization_slug; include_archived defaults to false.

Returns. Organization accounts ordered by recent activity, including company information, durable slugs, report/people state, runs, and deduplicated people counts. No tool-level limit or offset is exposed. Check for an existing account before buying another run.

get-account-intelligence

Inputs. organization_slug, account_slug.

Returns. Account facts, company report, buying committee, candidates, campaigns, and runs. Poll while people.isRunning or report.isRunning is true. Treat their completion states independently and check the research date and source evidence before acting on a claim.

draft-account-intelligence

Inputs. organization_slug, company with a public domain, and roles (1–30 literal roles/functions). Company name, logo, employee count, and location are optional. Optional instructions guide the draft.

Returns. Normalized company, roles, and editable criteria, plus nextStep. This researches and drafts review criteria but does not create the account, launch the people search, or spend the 300 launch credits.

launch-account-intelligence

Inputs. organization_slug, the reviewed company, roles, and criteria from drafting. Criteria include name, target_audience, must_haves, exclusions, and post_topics, with outreach, seniority, and extra context where relevant. Optional competitors, engagement_activities, and exec_titles refine signals. Omitted competitors use the organization's known sales-Persona competitors; an empty list explicitly requests no competitor targets. Activity overrides (reactions, comments, authored_posts) require an explicit competitors list. Executive title overrides replace the defaults.

Returns. Account/project identifiers, launch state, credit information, and polling guidance. A run costs a flat 300 credits and creates or reuses the durable account while creating run-specific research records. It includes engagement, recently joined, and hiring signals. It intentionally maps the account without excluding everyone already found, contacted, or in CRM. Confirm the reviewed criteria and spend first.

launch-person-intelligence

Inputs. organization_slug and exactly one of prospect_ids, linkedin_urls, or project_id. Explicit lists accept up to 50 targets; a project sweep's optional limit defaults to 25 (maximum 50). Optional company_context, research_instructions, and up to 10 questions guide the report. refresh defaults to false.

Returns. Separate launched and failed arrays, with target identifiers, run IDs, responseId, and reused where applicable. A successful HTTP response can still contain failed targets. Project sweeps choose top-scoring non-excluded prospects; explicit IDs must be visible in the selected organization. Standalone LinkedIn research needs no project.

New research is paid per person. Complete reports and active runs are reused by default; incomplete reports may require new paid work. refresh: true bypasses a completed report, but still reuses an active run. Guidance is research direction, not evidence establishing a fact. Poll with get-person-intelligence; do not relaunch the full batch because one target failed or a report has not arrived yet.

get-person-intelligence

Inputs. organization_slug and exactly one of linkedin_url or project_id; include_report defaults to false.

Returns. runs with camelCase fields including prospectId, linkedinUrl, status, isRunning, isDegraded, error, startedAt, completedAt, and report. With include_report: false, report: null is returned rather than the report body. Reads reconcile run state and are organization-scoped. The current read is capped at 200 runs with no MCP offset input; a project response is not an unlimited research archive. A degraded success is a partial report, not a complete answer or permission to buy a refresh automatically.

Audience research

list-audience-briefs

Inputs. organization_slug.

Returns. The newest 25 non-archived organization audience run/brief summaries, so you can find an ID and inspect recent research before launching. No tool-level pagination or archive controls are exposed; a missing older brief is not proof that no previous research exists.

get-audience-brief

Inputs. organization_slug, brief_id; optional sections, include_drafts (default true), and feed_limit (default 10, range 0–100). Sections are theRead, howAttentionMoved, themeTrends, takeaways, painPoints, openOpportunities, topVoices, postIdeas, topPosts, competitors, and seeds.

Returns. briefId, status, and the requested digest sections when ready; otherwise progress/error information. painPoints includes audience language, while postIdeas can include drafts and grounding judgments. Competitor and seed sections depend on what that run requested. feed_limit caps a preview, not a pageable archive of every collected post. Select only the sections needed for the question to reduce response size.

launch-audience-research

Inputs. organization_slug, audience; optional name, selected persona_id, tier, company_context, content_direction, posts_date_range, competitors, and seed_profiles. Competitor controls include own_company, company/executive post toggles, exec_titles, and max_execs_per_target.

Returns. briefId, initial status, tier, peopleRead, timeframe, source selections, creditsUsed, creditsRemaining, and viewAt. Poll get-audience-brief; the run continues server-side. The audience portion is typically described as 20–40 minutes, not a completion guarantee, and extra sources add time.

Current tiers are light (150 credits, 50 people), standard (default; 300 credits, 100 people), deep (600 credits, 200 people), and max (1,200 credits, 400 people). Confirm the selected tier before spending. Supported windows are past-week, past-2-weeks, past-3-weeks, and past-month (default). Up to five competitors and 25 personal LinkedIn seed profiles can add separate reports. Reading expert seed posts is listen-only; it is different from finding their engagers through a prospect search.

company_context and content_direction also become organization steering defaults for later runs. Do not supply invented company details or save a temporary direction without making that persistence clear.

Personas and playbooks

list-personas

Inputs. organization_slug.

Returns. Reusable organization Personas and targeting criteria. No tool-level pagination is exposed. Select an existing Persona with the user, or use freeform search criteria when no saved Persona fits.

create-persona

Inputs. organization_slug, name, use_case, and target_audience. Optional structured fields include outreach_reason, must_haves, nice_to_haves, exclusions, seniority bounds, geographies, company_attributes, competitors, post_topics, additional_context, and equal-preference flags. Company attributes cover industries, funding stages, and employee-count bounds. Supported use_case values are sales, recruiting, vc_investor, partnerships, community, fundraising, market_research, and other.

Returns. A saved Persona and initial version whose ID can be used in search or audience workflows. This saves reviewed criteria; it does not run the UI research wizard or launch a prospect search. Recruiting Personas do not retain sales competitor criteria.

update-persona

Inputs. organization_slug, exact persona_id, and updates and/or section_changes; optional change_note. updates replaces supplied fields or lists. Ordered section operations are add, remove, replace, and clear, for targeting lists and company industry/funding lists.

Returns. The updated Persona with a new reversible history version. Omitted fields stay unchanged; empty lists clear lists, and supported null values clear optional fields. add deduplicates values; remove matches exact strings. Confirm the patch before writing.

list-playbooks

Inputs. organization_slug; active_only defaults to true.

Returns. Playbooks available for campaign selection. Set active_only: false to include archived/historical ones. No tool-level limit or offset is exposed. Find a suitable playbook before creating one.

get-playbook

Inputs. organization_slug, playbook_id.

Returns. A playbook containing full markdown, parsed sections, and sectionFormat (legacy or sectioned). Read it before editing, especially when preserving existing strategy matters.

create-playbook

Inputs. organization_slug, name, and a content source. Use content_mode: "provided" with either content or sections, or content_mode: "generate" with a goal. Mode can be inferred when only one source is supplied; make it explicit when ambiguous. Generation also accepts organization_context, up to 20 sample_prospects, and warm_intro_context.

Returns. playbookId, name, and source. Provided markdown is saved verbatim; structured sections produce the canonical headings used by the section editor. Supported sections are sequencing, message_tone, positioning, constraints, cta_strategy, follow_up_logic, objection_handling, and approval_safe. Creating a playbook does not launch outreach, but it creates usable saved campaign strategy.

Structured section bodies are checked before saving. Section-like headings inside examples can confuse the editor, so ambiguous bodies are rejected without creating a playbook. Remove those headings or use complete reviewed content, which is saved verbatim.

update-playbook

Inputs. organization_slug, playbook_id, and the requested name, content, or section_updates; optional change_reason. Full content and section_updates are alternatives, not simultaneous sources.

Returns. Updated playbook data with a new version. Full markdown replaces the old text verbatim. A section patch preserves omitted sections and an empty string removes that section. Both the existing document and the proposed merged sections are checked before saving. Unsafe legacy, custom, duplicate, or fenced-heading structures are rejected by section editing rather than silently rewritten. Read the existing text and supply a complete reviewed content replacement when a safe section patch is not possible.

Campaigns, approvals, and pipeline visibility

get-campaign-stats

Inputs. organization_slug, project_id, and local campaign_id.

Returns. Campaign metadata and engagement, prospect, execution, pause, approval, and conversion breakdowns. AI campaigns can include supplemental backend metrics; failure to fetch those does not suppress the local detail. Supports AI and sequence campaign detail, but does not expose sequence lifecycle controls. Local status alone is not proof of backend start/stop state after an uncertain request.

launch-ai-campaign

Inputs. organization_slug, project_id, name, playbook_id, and prospect_ids. auto_start defaults to true. Optional inputs include goal, company_context, max_prospects, playbook_version, guardrails, approval_settings, and explicitly requested executing_user_email for an organization teammate.

Returns. Backend campaignId, localCampaignId, created, mirrored, enrollment counts and exact membership/link IDs, started, actual approvalSettings where available, and nextStep. Partial enrollment returns recovery instructions rather than starting. Read the earlier recovery section for unknown creation/start outcomes.

The campaign is mirrored into the project before enrollment. Live-campaign conflicts and duplicate LinkedIn identities are checked before launching; these checks do not provide a global concurrency lock. Defaults are seeded from the launch wizard and individual requested overrides are applied. Do not assume every action is approval-gated, change sending hours or approval modes by guesswork, or infer a colleague's sender identity. guardrails.channel: "email_only" avoids LinkedIn outreach but requires the executing sender's email setup. Email sender identity is resolved server-side.

add-prospects-to-campaign

Inputs. organization_slug, project_id, local campaign_id, and prospect_ids; reconcile_only defaults to false.

Returns. Campaign IDs and name, known counts, enrollmentCountKnown, confirmed and linked prospect IDs, unresolved/local-link-pending/historical/ not-attempted IDs, warnings, and nextStep. Only verified current backend members are linked locally. An active destination may act on new people under its existing settings. This tool does not create a campaign, start a draft, resume paused memberships, or restore removed people.

After a partial or uncertain write, set reconcile_only: true to verify and repair without enrolling again. Existing local links are not proof of current backend membership; reconciliation can report a mismatch without automatically deleting those links. Already-enrolled local rows can be a normal no-op outside reconciliation mode.

update-ai-campaign-settings

Inputs. organization_slug, project_id, local campaign_id, and nonempty guardrails and/or approval_settings. Guardrails cover channel, daily and follow-up caps, likes/comments, active hours/timezone, allowed weekdays (0 is Sunday), and pacing. Approval fields use auto or require per action type.

Returns. updated, local and backend campaign IDs, status, guardrails, and approvalSettings. Omitted fields remain unchanged. Completed campaigns cannot be changed. Confirm edits because enabling an action or changing a gate to auto changes real outreach behavior.

list-campaign-pending-actions

Inputs. organization_slug; optional all_members, member_emails, backend campaign_id, filter_category, and action_type. action_type takes precedence over the category. Categories are replies, initial, follow_ups, inmails, comments, likes, connections, stop, and meeting_booked. limit defaults to 100 (maximum 500), and offset to 0. include_prospect_details and include_timeline default to true; optional timeline_limit caps each history at 1–500 recent actions.

Returns. Pending-approval actions, totalMatched, and the result window. Results are merged across in-scope campaigns, filtered, then paged; compare the returned count plus offset with totalMatched. Timelines add per-person live reads, so disable them for count-only scans. A timeline may be unavailable; inspect its reason instead of assuming no prior contact. Setting include_prospect_details: false also bypasses timeline enrichment. Read context before approving replies, including on autonomous pipelines.

decide-campaign-actions

Inputs. organization_slug and 1–100 decisions, each with action_id and decision (approve, reject, or skip). Rejection needs a reason. Approvals can include notes, modified_content, and, for email/InMail, modified_subject.

Returns. bulk per-sender group results, individual results, and a summary. Subject edits use individual calls; other decisions are grouped by campaign sender. Approving can execute real outreach from that sender's account. Check each result rather than treating a mixed batch as all-or-none.

list-pipelines

Inputs. organization_slug; optional all_members and member_emails, with caller-only default scope.

Returns. Pipelines and top-level prospect/contact/reply/booking metrics. No tool-level pagination controls are exposed. Local totalContacted can undercount autonomous AI sends, so zero does not establish that nobody was contacted. Pipeline replyMode is not a substitute for checking approvals. This tool reads pipelines; it does not create, pause, or edit them.

get-pipeline-stats

Inputs. organization_slug, pipeline_id.

Returns. Aggregate metrics, per-project and per-Persona breakdowns, and funnelMetrics from live backend campaign funnels when available. Prefer the funnel for outreach-volume questions over the local contacted counter. If the live funnel is unavailable, describe that limitation instead of presenting the local lower bound as the complete sending total.

Limits of the connector

Tool availability is the registered reference above, not every action in the Lumnis interface. There is no general MCP tool here for pausing a prospect, creating or editing a recurring pipeline, deleting arbitrary records, reading mailbox messages, or controlling sequence lifecycles. Use the appropriate dashboard workflow for operations the connector does not expose.

Research can be incomplete, stale, or missing a source. Provider reads can fail independently of the core Lumnis record. Async launches and paid writes can outlive a client timeout. Preserve IDs and successful results, surface uncertainty, and confirm any additional spend or outreach rather than turning a missing result into an automatic retry.