Lumnis MCP

None. No organization_slug is needed. Use this tool to find your organizations.

• The signed-in user's profile.
• organizations, each with its slug, role, and member roster. Use these to choose the workspace and discover teammate emails.
• Account and team information visible to the connected assistant.

Only skill is required. Choose:

• "prospecting" — guidance for finding and reviewing the right people.
• "account_research" — guidance for researching a named company.
• "account_monitors" — guidance for answering from a monitor's saved runs.

No organization_slug, ICP, context, or objective is required. Authentication is still required.

The selected human-authored Markdown string directly in MCP text content, including its version and review date. The result is not a generated plan or JSON document. The endpoint makes no model calls, database reads, provider requests, or credit charges, and does not launch or change anything.

The prospecting guide explains conditional search selection, seed quality, criteria versus configuration, evidence review, and recovery from weak results. The account research guide covers company identity, reviewed buying roles, existing research, independent people/report progress, evidence gaps, and a reviewable account brief. The account monitors guide covers evidence windows, unscored rows, evidence flags, comparing two saved assessments by hand, and the questions a monitor cannot answer. The calling assistant applies the text using context already in the conversation. Guidance never substitutes for user consent, tool authorization, or the current input schema.

organization_slug.

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.

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

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.

organization_slug.

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.

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

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.

• organization_slug — your selected organization.
• provider — gmail, outlook, or imap.
• daily_send_cap — optional; defaults to 20 and accepts 10–40.

Check list-email-inboxes and complete sender setup first if required.

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.

• Required: organization_slug.
• Scope: optional all_members or member_emails.
• Filters: optional name_contains, updated_since, and updated_before.
• include_pipeline_projects — optional; defaults to false.
• limit — defaults to 50; maximum 200.
• offset — defaults to 0.

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.

• Required: organization_slug and project_id.
• prospect_limit — defaults to 20; accepts 0–50.
• judgment_status — optional: verified, needs_review, or flagged; filters the non-excluded prospect preview.
• campaign_limit — defaults to 10; accepts 0–20.

Project details, prospect and campaign previews, complete campaignCount and liveAiCampaignCount, campaignsTruncated, and soleLiveAiCampaign when exactly one eligible AI campaign exists. Prospects include judgmentStatus and judgmentLabel. prospectCount counts all matching non-excluded people; prospectsTruncated indicates a capped preview. prospectStats supplies full saved-project counts, even with prospect_limit: 0 or a judgment filter (see judgment and counts). 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.

organization_slug, project_id.

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.

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.

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.

• Required: organization_slug and project_id.
• Pagination: limit defaults to 50 (maximum 200); offset defaults to 0.
• include_excluded: true selects only excluded prospects, not active and excluded combined.
• judgment_status — optional: verified, needs_review, or flagged. Omit for all groups. Combines with include_excluded and filters before pagination.
• include_summary — defaults to true.
• crm_match_mode — optional; none (default), cached, or live.
• include_crm_account_context — defaults to false.

prospects, totalCount, limit, offset, and prospectStats. totalCount counts all matches for the exclusion and judgment filters before pagination. prospectStats stays unfiltered. Each row has judgmentStatus, judgmentLabel, 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.

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

Full local prospect detail, including judgmentStatus, judgmentLabel, 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.

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

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.

• Required: organization_slug.
• Targets: exactly one of prospect_ids or linkedin_urls, up to 100 targets.
• include_email — defaults to true.
• include_phone — defaults to false.
• refresh — defaults to false.

At least one contact field is required. Contacts are not filtered by verification.

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.

organization_slug, name, and optional prospects (1–50, same shape as add-prospects-to-project).

projectId, projectSlug, name, and, when people were supplied, the same fields as add-prospects-to-project. It is free: no search runs and no credits are used. A taken name gets a numbered variant, so to add more people later use add-prospects-to-project with the returned projectId. If adding people fails, the error names the project that was already created.

organization_slug, project_id, and prospects (1–50). Each person needs a valid linkedin_url or email. name is optional with a LinkedIn URL (read from the URL when missing) and required with an email only; optional title, company, and location provide useful context.

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.

organization_slug, optional provider (attio or hubspot; optional when exactly one CRM is connected, required when both are), and people (1–50). Each person needs a linkedin_url, or a prospect_id whose saved prospect has one; the saved prospect fills in name, email, title, company and company domain, and values you pass win. Optional name, email, title, company, company_domain, location, and custom_fields (CRM property names mapped to text values). company_linkedin_url is accepted but not used yet.

provider, totals (requested, created, linkedExisting, failed), partialFailure, and results[] with each person's action (created, linked_existing, or failed), crmRecordId, crmUrl, matchedBy (linkedin, email, name_company, created, or already_linked), and errorCode/error on failure. This WRITES to the organization's own CRM and is free. People are matched by LinkedIn URL, then email, then name and company, and a new record is created only when nothing matches. The company is matched by company_domain when given, otherwise by name. custom_fields are written on create and only fill empty fields on an existing record. Repeating a call links the same records again rather than duplicating them.

organization_slug; include_archived defaults to false.

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.

organization_slug, account_slug.

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.

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.

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 75 launch credits.

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.

Account/project identifiers, launch state, credit information, and polling guidance. A run costs a flat 75 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.

• Required: organization_slug.
• Targets: exactly one of prospect_ids, linkedin_urls, or project_id. Explicit lists accept up to 50 targets.
• limit — for a project sweep; defaults to 25, maximum 50.
• Research guidance: optional company_context, research_instructions, and up to 10 questions.
• refresh — defaults to false.

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. Each new run costs 7 credits per person and is refunded if it fails; a reused report or active run is free.

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.

• Required: organization_slug.
• Target: exactly one of linkedin_url, project_id, or run_id (the exact report's id returned by an earlier read).
• include_sections — defaults to false. Set it to true to discover section IDs, titles, availability, and sizes without retrieving their text.
• section_ids — up to 20 exact IDs from that report's sectionIndex. Retrieves selected text for one linkedin_url or run_id; not a project.
• report_version — optional reportVersion from the index. Use with section_ids to detect a report that changed between discovery and reading.
• cursor — optional sectionPage.nextCursor from the previous response. Repeat the same target, section IDs, and order to continue reading.
• include_report — defaults to false. Set it to true for the full original report response. Cannot be combined with section_ids.
• include_drafts — defaults to false. Set it to true to add outreachDrafts to each run: emails, connectionNotes and linkedinMessages, each variant opening with a different personal detail (hook, optional subject, body). null when the report has none. Combines with any other option and does not return the report body.

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.

Read only what you need.

1. Call with include_sections: true. Each run adds reportVersion, generatedAt, writer, sectionsAvailable, and sectionIndex. Index entries contain id, title, available, byteCount, and charCount.
2. Choose relevant IDs from that index, then call with section_ids and report_version. Use the returned run id as run_id when choosing from a project or when a profile has multiple historical reports.
3. Read sectionPage.sections. Each entry contains the original markdown, its charOffset, total charCount, and hasMore, along with the section's ID, title, availability, and byte count. Full report JSON and visual annotations are not included.
4. If sectionPage.nextCursor is not null, request the next page. Each page contains at most 12,000 characters of section text in total. Join fragments for each section in offset order before interpreting Markdown, tables, or citations that may cross a page boundary. Character counts and offsets use JavaScript UTF-16 units; pagination preserves surrogate pairs.

For example, to prepare for a call, discover the report's sections and select the IDs for “What they care about” and “Relevant to your context,” if present. Do not assume section numbers or IDs stay the same across reports.

sectionPage.isPartialSelection means you requested only part of the report; it does not mean the source is degraded. Continue to check isDegraded. Unknown section IDs return an error with the available index; a changed report returns report_changed and requires a fresh index. A cursor cannot be reused for a different run or selection.

Older or malformed reports may return sectionsAvailable: false with sectionsUnavailableReason; they remain readable with include_report: true. Reports with document-wide reference-style citation definitions require that full-report mode to preserve citation context. Inline citation links travel with their original section text. Section retrieval does not launch research or spend credits on a new run.

organization_slug, reviewed settings matching dashboard setup, including account members, depth, cadence, committee criteria and scoring instructions. Optional settings.crmSource (provider, fields, ownerField — the same object search-crm-companies takes) keeps the monitor topped up: before each scheduled run the search is rerun and new matches are added, never removed.

Optional settings.signalSearch assesses only accounts where a people search finds a signal this period. Fields: personaId (from list-personas), searches (job_signal, competitor_engagement, competitor_rep_engagement, high_intent; default all four), topics for high_intent (default the persona's post topics), peoplePerSearch (1–1000, default 250) and maxAccountsPerRun (default 100; null assesses every matched account). Each run pays 1 credit per person per search before any assessment, so the defaults cost 1,000 credits a run; empty or failed searches are refunded. Accounts present at creation wait for a signal instead of being assessed at once. Omit it to assess every account. The persona must belong to the organization (otherwise a 400, "Choose a persona from this organization"). The two competitor searches need the organization's website or at least one competitor; without both they fail with "Add competitors or your website" and are not charged.

Weekly email: settings.digestRecipients is who gets a short email after each scheduled run (any address; no Lumnis account needed). Omit it to send to every member of the organization, as the dashboard prefills; send [] for no email. settings.digestInstructions (optional) shapes only the email, never what the monitor checks or how it scores.

Optional settings.nextRunAt (ISO date-time with its offset, in the future and at most 365 days ahead) chooses when the first run happens; nothing is assessed or charged before it, and later runs repeat every intervalDays from it.

Optional copy_settings_from (a monitor id from list-monitors) starts from an existing monitor, for example to split it by a CRM field: its depth, cadence, competitors and titles, committee roles, notes and criteria, scoring guide, signal search, CRM source and email settings are copied once, then anything in settings replaces them. Only name and members are then required. Accounts that already have a committee found with the same committee settings in the organization reuse it instead of searching again.

monitorId and account outcomes. Creates the monitor and schedules its first run; do not also call Run now.

organization_slug, monitor_id.

The run id. Requests Run now with existing settings and cadence, using the same running-run conflict and credit rules as the dashboard. On a monitor with signalSearch, Run now starts a sweep: it pays for its searches first, then assesses matched accounts up to the per-run limit. While a sweep is searching, Run now is refused as already running.

organization_slug, monitor_id, members.

Per-account outcomes and runId when queued. Adds and deduplicates accounts; active monitors queue initial assessments, paused monitors wait for resume. On a monitor with signalSearch, added accounts are still assessed right away at the per-account price; they do not wait for a signal.

organization_slug, monitor_id, changes including latest updatedAt from get-monitor-rankings.

Updated monitor settings or a stale-edit conflict. Supports settings changes and pause/resume, and changes.crmSource replaces the saved CRM search (null stops the refresh). changes.signalSearch replaces the signal-search settings (same fields as create-monitor); null returns to assessing every account. A run in progress keeps the settings it started with. Turning signal mode off assesses accounts waiting for a signal right away at the usual price (after any searching sweep finishes); turning it on assesses only accounts with a signal from the next run, and saved results stay. Pausing does not cancel queued work, and a searching sweep still finishes and assesses its matched accounts; resuming can spend credits.

Weekly email: changes.digestEnabled turns it off or on (off keeps the list), changes.digestRecipients replaces the whole list, and changes.digestInstructions replaces the email instructions (null clears them). People added to the list get the next scheduled run's email; pass send_latest_email_to_added: true to also send them the latest one now (only the added addresses). The response's latestEmail is then the sent and failed counts, noEmail: true when the latest run had failures and nothing stood out, or null when nothing was sent.

organization_slug, monitor_id, assessment_id.

Saved item/run identifiers and pending state. Retries eligible work using frozen inputs and existing successor, credit and refund rules. Eligible work is a failed assessment or a finished one with no usable score, up to the same retry limit. Signal searches cannot be retried by hand: they run again next period, and a failed or empty search is refunded on its own.

organization_slug, monitor_id, target_account_id (from a rankings row), owner_label (free text; an empty string clears it and the row reads as Unassigned).

targetAccountId, ownerLabel, and syncedItemId. Changes the owner the way the monitor page does and updates the account's newest saved assessment, so the owner filter in get-monitor-rankings matches right away. Spends no credits.

organization_slug, monitor_id.

sentTo. Sends the latest scheduled run's weekly email to you only, as the settings' "Send me a test" does, with "[Test]" in the subject and the monitor's saved email instructions. Refused before a scheduled run has finished, or when the latest run had failures and nothing stood out. Spends no credits.

organization_slug.

monitors[] with id, name, defaultDepth (light assesses the company; deep also reads the buying committee found once when the account joined), intervalDays, status (active or paused), memberCount, nextRunAt, lastRunAt, and latestRun with its status, evidence window, and item counts. A searching run is a signal sweep whose searches are still running; it has no accounts yet and shows even on a paused monitor, because a started sweep finishes. Its signal object is the sweep's progress. Pass monitors[].id as monitor_id to the other monitor tools.

organization_slug, monitor_id. Optional run_id reads an earlier saved run instead of the latest finished one; priority filters to act, look, or keep (default all); owner filters by an exact owner label from the response's owners list (case-insensitive, not a partial match), or "__unassigned__" for accounts without one; search matches an account name or domain; page selects a 50-row page (default 1); awaiting_page and progress_page page through awaitingMembers and progressItems 50 rows at a time.

monitor settings, the selected run with windowStart and windowEnd, latestRun for current activity, items[] of 50, pagination, facets counts per priority, hasOwner, plus bounded progressItems (unfinished, failed, or skipped) and awaitingMembers (never assessed). Each item carries rank, priority, score, level, topReason, evidenceFlag (limited or warnings), ownerLabel, tier, completedAt, targetAccountId, and the assessment id. rank is a global ordinal over the whole run and does not change with filters. rank: null means unranked: validation warnings can exclude a usable score, so inspect score, assessmentStatus, and validationStatus. Pages group by priority before rank; follow pagination when needed to identify the global top accounts. A weekly run does not prove coverage of the last 72 hours; state the window.

For a monitor with signalSearch, the response also carries signalRunBudget (searchCredits, assessCount, assessCredits, total): the most one run can cost, computed the same way as the dashboard. A run with status searching lists each search in signal.searches[] with its status, a coarse stage while running (the same stage words as get-project), people when done, and error when failed; signal.checked, matched, and assessed are the run's counts. matched: 0 means no account showed a signal that period, not a failure. A sweep still searching when its period ends is closed: open searches fail with "Search failed" and unfinished matching with "Matching did not finish". In awaitingMembers, hasSignal: true means a search found someone there but the run hit its limit; waitForSignal: true means no search has found anyone there yet.

organization_slug, monitor_id, assessment_id (an items[].id from get-monitor-rankings or get-monitor-account-timeline). Optional include adds evidence (every cited record) and/or markdown (the prose report); optional evidence_ids returns just the records behind one section, signal, or finding.

The item row, the run window, the frozen context the assessment used (owner, tier, committee people, scoring guide, depth), and report.analysis as the monitor page presents it: score, level, assessment and validation status, the account-analysis bullets, why-now sections with evidenceIds, the recommendation, every signal judgment, the company analysis (company: news and hiring narratives with findings), the committee analysis (synthesis: patterns, findings, questions) and caveats. About 80 KB for a deep account. report.peopleIndex and peopleTotal list every committee member cheaply; evidenceTotal counts cited records. Caveats collapse per-person coverage lines into their aggregate. Evidence records and person reports are omitted unless requested; a deep account can carry 400 KB of evidence and 50 person reports. Current settings do not rewrite a saved assessment.

organization_slug, monitor_id, assessment_id. Optional people_limit (default 10, max 50) or people (names or LinkedIn URLs) to choose which person reports to return.

people (each person's name, title, URL, summary, reasoning, coverage statement, nothingInWindow, and dated claims with evidenceIds), the full peopleIndex (name, title, URL, activeInWindow, failed) and peopleTotal. People are ordered active-in-window first, then by number of claims, then roster order. The committee synthesis is part of get-monitor-account-report. Light monitors have no committee. A person with nothing in the window has no observed activity there, not a negative signal.

organization_slug, monitor_id, target_account_id (from a rankings row). Optional cursor from a previous nextCursor.

items[] of up to 25 assessments for that account, newest run first, each with id, runId, score, level, status, completedAt, windowStart, windowEnd, monitor (id, name) and comparable, plus hasMore and nextCursor. History follows the account across every monitor of the organization; comparable marks results that count as an earlier check for this monitor (its own, or a same-depth monitor's from before the account joined). Read an entry with get-monitor-account-report using its monitor.id. The first page also returns signals: one entry per signal sweep that matched the account, newest first, with runId, windowEnd, assessed, searches (type, people, projectSlug), evidence, and matchedBy, even for an account never assessed. The tool does not compute differences or repeated findings; read two assessments with get-monitor-account-report and compare them, naming both windows.

organization_slug.

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.

organization_slug, brief_id (from list-audience-briefs). Optional sections to return only some parts, include_drafts (default true; affects post ideas only), and feed_limit (0–100, default 10; how many top engaged posts to include).

One brief as a readable digest: the headline finding, the engagement analysis (period shifts, theme trends, takeaways, pain points, the audience's own language, top voices), and ranked post ideas with drafts and grounding verdicts. A whole brief is large; pass sections to take only the part that answers the question.

organization_slug, provider (hubspot or attio; the organization must have it connected). Optional property_name reads one field in full — required to get Attio select/status choices, which the full listing omits.

properties[] with name, label, type, the operators the field accepts and, for pick-lists, options[] of { value, label }. A definition with references: "owner" is the field that identifies the CRM user (HubSpot hubspot_owner_id; on Attio only an actor-reference whose name says owner). Read-only and free; no organization data is written.

organization_slug, provider, fields[] — up to five { property, propertyLabel, filterField?, values: [{ value, label }] } taken from list-crm-company-fields; within a field the values OR together, across fields they AND, and an empty list means every company. Attio select/status fields need filterField "option" or "status". Optional owner_field (the field flagged references: "owner") and cursor from a previous page.

One page of up to 100 companies[] with id, name, domain (the website the monitor keys on) and, when owner_field was passed and the CRM resolved it, ownerLabel; plus nextCursor and, on HubSpot's first page, total. Pass nextCursor back as cursor with the same fields for the next page. The fields/owner_field you searched with is exactly what create-monitor accepts as settings.crmSource. Read-only and free.

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.

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.

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.

organization_slug.

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.

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.

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.

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.

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.

organization_slug; active_only defaults to true.

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.

organization_slug, playbook_id.

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

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.

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.

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.

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.

organization_slug and local campaign_id; project_id is optional and is resolved from the campaign when it is omitted. Campaign IDs are unique, and the lookup is scoped to the caller's organization, so a campaign in another organization is reported as not found.

Campaign metadata and engagement, prospect, execution, and pause breakdowns, and, for AI campaigns when metrics load, metrics.pendingApproval (actions waiting for approval) and metrics.funnel (funnel stages with counts and rates). Failure to fetch metrics 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.

organization_slug, project_id, campaign_id (the local id from get-project).

{ localCampaignId, campaignId, name, status: "paused" }. A campaign that is not active is refused with its current status.

organization_slug, project_id, campaign_id.

{ localCampaignId, campaignId, name, status: "active" }. A campaign that is not paused is refused with its current status.

organization_slug, project_id, campaign_id, prospect_ids (local ids from list-prospects).

{ removed, notInCampaign, failed }. People not currently in this campaign are listed in notInCampaign and left alone.

organization_slug, project_id, campaign_id.

{ deleted: true, localCampaignId, name }, or the error when the stop failed.

• Required: organization_slug, name, playbook_id, and either linkedin_urls or project_id + prospect_ids (exactly one source).
• linkedin_urls — LinkedIn profile URLs. A free project named after the campaign is created, the people are added (names read from the URLs), then the campaign launches on it.
• Context: optional goal, company_context, max_prospects, and playbook_version.
• Controls: optional guardrails and approval_settings, set in this call.
• executing_user_email — only for an explicitly requested organization teammate.

Backend campaignId, localCampaignId, projectId, created, mirrored, skippedPeople ({ name, reason }), unresolvedUrls, 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. The backend decides who can be enrolled: anyone already in another active campaign of the same sender (or excluded) is skipped and named with a reason. If everyone is skipped, the empty campaign is deleted and nothing starts (with URLs, the new project still keeps the people). Two rows for the same person in one request are enrolled once. 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.

organization_slug, project_id, local campaign_id, and either prospect_ids or linkedin_urls (added to project_id, the campaign's home project, free, then enrolled); preview and reconcile_only both default to false. project_id is the campaign's home project. prospect_ids may name people from any project in the same organization: the campaign stays where it is, each person stays in their own project, and the campaign is mirrored into each other source project so those people appear in their own project's campaign view.

Preview. With preview: true nobody is enrolled, nothing is linked and no mirror row is created. The backend runs every overlap check and the tool returns wouldAdd, wouldSkip, per-person findings (for example active_campaign, previously_contacted, active_sequence, CRM matches) and named skips, so the user can choose whom to enroll before anything is written. Findings are warnings, not refusals; a normal call still enrolls people who carry them. A preview is only trusted when the backend confirms it: if a response does not echo the dry run, the tool stops there, reports previewConfirmed: false and lists notPreviewedProspectIds, because that batch may have been enrolled for real.

Campaign IDs and name, known counts, skippedPeople, unresolvedUrls, enrollmentCountKnown, confirmed and linked prospect IDs, linkedByProject, mirroredProjectIds, unresolved/local-link-pending/historical/not-attempted IDs, warnings, and nextStep. Only verified current backend members are linked locally. A source project whose mirror or link fails is named in the error and its people stay link-pending; the other projects are still linked. 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.

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.

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.

• Required: organization_slug.
• Scope: optional all_members, member_emails, and backend campaign_id.
• Filters: optional filter_category and action_type. action_type takes precedence over the category.
• Pagination: limit defaults to 100 (maximum 500); offset defaults to 0.
• include_prospect_details and include_timeline — both default to true.
• timeline_limit — optional; caps each history at 1–500 recent actions.

Categories are replies, calls, initial, follow_ups, inmails, comments, likes, connections, stop, and meeting_booked.

A call_phone action asks the rep to phone the person; nothing is sent. The number is prospectData.phone. While it is missing and generatorMetadata.phone_lookup.state is queued or running, Lumnis is still finding it; not_found means no number was found. agentReasoning says why to call now.

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.

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.

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.

For a call, approve means the rep made the call. Put the outcome in notes (spoke, voicemail, no answer, or more detail); the campaign AI reads it when it plans the next step. Skip means don't call now. Put why in reason if the user gives one ("call again in 2 days", "wrong number"); the campaign AI reads it with the playbook to choose the next step. The note and the reason are both optional, and a call can be skipped while Lumnis is still finding the number. Approve a call only after the user says they called.

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

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.

organization_slug, pipeline_id.

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.