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.
• "campaigns" — guidance for setting up campaigns: how many, which playbook, and who is copied on emails.
• "linkedin_network" — guidance for finding people through LinkedIn connections and asking for an intro.
• "account_focus" — guidance for finding one team, function or product at a named company.

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, comparing two saved assessments by hand, and the questions a monitor cannot answer. The LinkedIn network guide covers whose network to search, how close to look, reading introducers, and asking for an intro. 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; optional executing_user_email for another member of the organization.

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. Each inbox has a mailboxId and its email address. Lumnis creates the mailboxId, so it works the same for every provider. 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 gives the current step, a percent from the steps finished, and a 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–5000). 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.

For linkedin_network, leave out connections_of to search the user's own network. network_distance accepts 1, 2, and 3 and defaults to [2]: 1 is people the user knows, 2 is people the user's connections know, and 3 is further out. To search someone else's network, put their LinkedIn profile URLs in connections_of. Each must be the user's direct connection; anyone else is skipped. There, network_distance accepts only 1 or 2: 2 is people they know that the user does not, and 1 is people both know. target_accounts takes company names, websites, or LinkedIn company URLs, and returns only people now at those companies.

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.

People found through a LinkedIn network search can also carry cameThrough, the names of the people they are connected to, and introducers, the people who can introduce the user to them.

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, plus cameThrough and introducers where available. 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.

organization_slug and people (1–50), each with name, company, and optional title.

results, one per row in the order given. Each has a status (matched, not_found, or error) and up to three candidates with their LinkedIn URL, name, current title, and current company. A match is a possible identity, not a confirmed person, so ask the user to choose when it is unclear. Nothing is saved or researched, and no credits are charged. Do not repeat a timed-out lookup automatically. To save a confirmed person, use add-prospects-to-project.

organization_slug, then one of two forms.

• New search: request_id, account, and criteria_definitions, with optional titles, criteria_classification, max_candidates_per_account, and limit_per_account. request_id is a UUID you make. Reuse it on any retry, because a new ID starts new paid work.
• Read a search: response_id alone, from the responseId a new search returns.

account needs an id, a name, and a domain or linkedinUrl. Titles only narrow discovery.

Ranked people with criterion scores, evidence, and accepted, unresolved, or rejected status. A new search costs 10 credits, so confirm the account and criteria first. Reading a search is free. selected: true means a recommended committee member, not verified eligibility. A finished search can still be partial, so check result.outcome and coverage before calling the committee complete. Nothing is saved, and no monitor changes.

• 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 (one or more, 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 (one or more; there is no upper limit). 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 and project_id.

introducers[], each with name, linkedinUrl, peopleFound, peopleIds, tickedPeopleIds, and link (null when none was made): id, url (null unless live), live, mine, ownerName, expiresAt, answeredAt, and people[] with ticked on anyone the introducer knows. Read only.

organization_slug, project_id, introducer_linkedin_url, and prospect_ids (at least one).

linkId, url, mine, ownerName, expiresAt, total, added, alreadyOn, skipped, and message, the suggested text to send. It makes a link if there is no live one, otherwise it adds to that link and the URL stays the same. It never replaces anyone. Only people found through this introducer are added; anyone else comes back in skipped. A new link lasts 30 days. If a teammate owns the live link, nobody is added and message is null.

organization_slug, project_id, link_id, and prospect_ids.

removed, kept, skipped (not on the link), and total. Only the person who made the link can remove people. Someone the introducer already ticked stays and comes back in kept, because the tick is their answer. The last person can't be removed, because an empty link means everyone found through the introducer: turn the link off instead. A link for everyone becomes a fixed list after a removal, so people found later aren't added.

organization_slug, project_id, and link_id.

turnedOff and linkId. The URL stops working for good. The introducer's ticks and any drafted emails stay. Any teammate can do this.

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. While a part runs, its progress gives the current step and a percent from the steps finished, and progressSummary describes both parts in one line. 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. competitors, engagement_activities, and exec_titles are refused. Use the reviewed roles and criteria instead.

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 finds the committee with live company search and the reviewed criteria. It does not collect engagement, hiring, or job-change signals, and required post or web evidence stays unresolved. 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. A running run also carries progress: the current step and a percent from the steps finished. 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. Each settings.competitors entry must be a website, not a company name. Leave out settings.competitorTitles to use the default titles; send [] for no titles.

Optional settings.crmSource (provider, fields, ownerField — the same object search-crm-companies takes) keeps the list up to date: before each scheduled run the search is rerun and new matches are added. Mark the members you fetched from that search with crmManaged: true. A complete refresh removes those accounts when they stop matching. Accounts added by hand and past reports stay.

Optional settings.crmWriteField (provider, label) writes each finished account's "Why now" and a link to its report to a CRM company field after every run, replacing the last value. The field is found by label or API name, or created as multi-line text. Omit it to write nothing.

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 job signal or high intent search costs 1 credit per person, paid before any assessment. With at least one named competitor, the two competitor searches come from the organization's shared weekly search and are free, so the defaults cost 500 credits a run. With no named competitors, the monitor runs those two searches itself at the same price, 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. Adding an account that was removed restores it. These accounts are not removed by a CRM refresh.

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.intentScoringInstructions replaces the scoring guide (null clears it). changes.nextRunAt sets when the next scheduled run starts, with its offset, in the future and at most 365 days ahead; later runs repeat every intervalDays from it. changes.committeeRoles and changes.committeeNotes guide only accounts whose committee has not been searched yet, and only when the monitor has no saved committee criteria. changes.crmWriteField picks the CRM field written after each run; null stops writing, and the field and its text stay in the CRM. 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. A failed assessment, or a finished one with no usable score, is retried with its original inputs. A scored assessment is re-run with the current monitor settings over the same window, and is charged like a new one. Each account allows up to 3 retries or re-runs. 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 weekly email of the latest scheduled or Run now run 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. It writes a fresh summary, so it can take a few minutes. 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, url (the monitor's page in Lumnis), and latestRun with its status, evidence window, and progress. 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, monitorUrl, plus bounded progressItems (still running or not scored) and awaitingMembers (never assessed). Each item carries rank, priority, score, level, topReason, ownerLabel, tier, state, completedAt, targetAccountId, url, and the assessment id. rank is a global ordinal over the whole run and does not change with filters. rank: null means unranked. state is the page's label for an account that is not scored, such as Failed or Needs committee. 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.

monitor also holds the weekly email settings (digestEnabled, digestRecipients, digestInstructions), crmWriteField, and crmWriteStatus, one plain line on the latest CRM write. hasLatestEmail: true means a scheduled or Run now run has finished, so there is an email to test or send.

For a monitor with signalSearch, the response also carries signalRunBudget (searchCredits, assessCount, assessCredits, total), the same figures the dashboard shows. searchCredits leaves out the monitor's own competitor searches when it has no named competitors, so add those when you quote a cost. Rows can also say why a search selected the account: signals, evidence, matchedBy, and runWindowEnd. latestSignalRun is the newest sweep. A run with status searching lists each search in signal.searches[] with its status, its current step while running, 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, and its open searches count as failed. 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 sections names the parts to return whole, with evidence ids: verdict, whyNow, nextStep, news, hiring, committee, signals, and report. Optional include adds evidence (every cited record, which is large) or markdown (the same as the report section). Optional evidence_ids returns just the records behind one section, signal, or finding.

Always assessmentId, account, window, whyNow, followUps (next questions to offer), and reportUrl. With no sections, a short summary: the verdict, why now, the next step, and news, hiring, and committee findings as dated lines. A section with nothing in it reads "No information found". The score shows how strongly this period's activity matches the scoring guide. It does not measure how complete the data is. 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, activeInWindow, summary, reasoning, and groups of dated claims with evidence ids), the full peopleIndex (name, title, url, activeInWindow) 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 reads "No information found". That means 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, 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. Mark members you fetch from this search with crmManaged: true. Read-only and free.

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). Sections are theRead, howAttentionMoved, themeTrends, takeaways, painPoints, openOpportunities, topVoices, postIdeas, topPosts, competitors, and seeds.

briefId, status, and the requested sections when ready; otherwise progress or error information. A brief is 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. Competitor and seed sections depend on what that run requested. feed_limit caps a preview, not a pageable archive of every collected post. A whole brief is large; pass sections to take only the part that answers the question.

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. emailMailboxId is the saved inbox, and null means automatic distribution. emailInboxPolicyUnavailable means the saved inbox could not be read. 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, playbook_version, and crm_company_fields (CRM company field names the AI reads, from list-crm-company-fields).
• Controls: optional guardrails and approval_settings, set in this call.
• guardrails.person_intelligence — researches each person before outreach. Off by default. Costs 7 credits per person; people already researched are free, and a failed report is refunded. Each person's next message waits for their report; replies never wait.
• guardrails.cc_emails — addresses copied on every email the campaign sends.
• executing_user_email — only for an explicitly requested organization teammate.
• email_mailbox_id — optional exact mailboxId from list-email-inboxes for the same sender. Omit it for automatic distribution.

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.

With email_mailbox_id, every email uses that inbox, waits, or pauses for repair; it never switches address. The inbox cannot change after creation, so a different inbox needs a new campaign. The result returns the saved emailMailboxId, and nothing is enrolled or started if it does not match.

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. personIntelligenceReused counts people whose existing report was attached for free. 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. guardrails.person_intelligence turns person research on or off; turning it on mid-campaign also researches, and charges for, people already contacted. guardrails.cc_emails replaces the CC list, and [] turns CC off. Optional crm_company_fields replaces the CRM company fields the AI reads, and [] clears them.

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, complete, and meeting_booked. complete means planned outreach is finished; approving it sends nothing.

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. generatorMetadata.callBrief, when present, is short call prep: who, topics, opener, avoid, and reasoning. Show it to the user before they call. A topic marked as an internal source is context for the rep, not something to say to the person.

Pending-approval actions, totalMatched, and the result window. Each action has prospectLocation and prospectTimezone, or null when unknown. Email cards also have recipientEmail and ccEmails, the exact addresses approving sends to and copies. 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. Email approvals can also include recipient_email, which changes who it goes to, including later emails to that person, and cc_emails, which sets who is copied on this email only. [] copies no one. Pass them only when the user asks to change the To or CC.

bulk per-sender group results, individual results, and a summary. Subject, recipient, and CC 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.