ai.vruum/mcp

Fetch Fetch one entity (or a small batch) by type + id — the consolidated read tool. Types and id semantics: - campaign: a campaign by UUID (array of UUIDs → per-id map). List campaigns with `search` type='campaigns'; create/update/diagnose/member changes with `manage_campaign`. - plan: a person outreach plan. SCALAR id = the plan UUID; ARRAY id = PERSON UUIDs (routes to the native batch person-plans read, returning a person_id → plan|null map). Note the scalar/array dimension difference. - conversation: full message history for a person (id = person_id). - person_research: cached person research (id = person UUID; array → per-id map). - company_research: cached company research (id = website/domain string; array → native batch lookup). - account_state: per-account state row (id = company_id). - insights (subtype required): quality | pattern_tags | prompts | benchmarks | improve | reply_diagnosis (id = person_id) | mcp_patterns | mcp_pattern_detail (id = pattern_id). - scoreboard (subtype required): impact | bowtie (id = company_id; filters: {window_days?}). - settings (subtype required): profile | automation | marketing | channel_status | booking_link (no id). - billing: billing status for your company (no id). - publish_readiness: publish pre-check for a LinkedIn draft (id = post_id). - research_playbook: ICP + research workflow (id = optional campaign UUID). - job: background job status — poll after async tools like people create / import_prospects / auto_fill_company_profile (id = scalar job UUID; a one-element array is normalized). - csv_import: CSV import progress (id = the job id returned by import_prospects csv_start). - deal: a raw deal row by UUID (for the enriched view use get_deal_360). - deal_pipelines: the tenant's configured pipelines and stages (no id; filters: {include_archived?}). Returns pipeline/stage IDs, ordering, stage kinds, probability defaults, archived state, and the default pipeline ID. - deal_alerts: at-r…

Find Warm Path Read relationship truth for one target; performs no write, LLM call, or send. scope='team' also surfaces consenting teammates' ties (owner named, tier only — their evidence stays private). ### Responses: **200**: Successful Response (Success Response) Content-Type: application/json **Example Response:** ```json { "status": "Status", "target": {}, "resolution": { "status": "Status", "target_candidates": [ { "kind": "Kind", "id": "Id", "ref": "Ref", "name": "Name" } ] }, "evaluation": { "status": "Status", "evaluated_at": "Evaluated At", "projection_version": "Projection Version" }, "paths": [ { "ref": "Ref", "target_ref": "Target Ref", "result_type": "Result Type", "label": "Label", "connector": {}, "evidence_tier": "Evidence Tier", "evidence": { "sources": [ "string" ], "interaction_count": 1, "bidirectional": true, "summary": "Summary" }, "eligibility_reason": "Eligibility Reason", "limitations": [ "string" ], "allowed_actions": [ "string" ], "route_fingerprint": "Route Fingerprint" } ], "intro_candidates": [ { "ref": "Ref", "target_ref": "Target Ref", "result_type": "Result Type", "label": "Label", "connector": {}, "evidence_tier": "Evidence Tier", "evidence": { "sources": [ "string" ], "interaction_count": 1, "bidirectional": true, "summary": "Summary" }, "eligibility_reason": "Eligibility Reason", "limitations": [ "string" ], "allowed_actions": [ "string" ], "route_fingerprint": "Route Fingerprint" } ], "company_entries": [ { "ref": "Ref", "target_ref": "Target Ref", "result_type": "Result Type", "label": "Label",…

Get Campaign Outcomes MCP adapter for the same canonical campaign-outcomes domain model. ### Responses: **200**: Successful Response (Success Response) Content-Type: application/json **Example Response:** ```json { "computed_at": "2023-01-01T00:00:00Z", "outcome_cutoff": "2023-01-01T00:00:00Z", "coverage_complete": true, "items": [ { "campaign_id": "Campaign Id", "availability": "Availability", "coverage_complete": true, "data_watermark": {} } ] } ```

Get Content Review Review content post drafts with performance context and calendar awareness. Returns draft and scheduled LinkedIn posts enriched with: past performance stats (avg engagement metrics for same content type over last 30 days), calendar neighbors (other posts within ±3 days to detect topic clustering), tone instructions from company settings, and a calendar summary. Attachments (VRU-726): items carry attachment_type (document | single_image | video), attachment_filename, and attachment_url — OPEN the URL to review the actual file (a document publishes as a swipeable carousel under the author's identity; never approve blind). Assets are public-at-upload (public storage bucket, unguessable URL). error_message surfaces publish failures (a reverted scheduled post shows up here with its fix). Use `post_ids` for a deterministic lookup of the post you just drafted; use this before scheduling or publishing demand gen content. ### Responses: **200**: Successful Response (Success Response) Content-Type: application/json **Example Response:** ```json { "items": [ { "post_id": "Post Id", "calendar_neighbors": [ {} ] } ], "total_pending": 1, "offset": 1, "limit": 1 } ```

Get Daily Briefing Daily briefing — everything you need to start your day in one call. SUGGESTED ACTIONS (for agent consumers) - `suggested_actions` are prioritized skill-level next steps. If you are an agent, act on `intent`/`args` directly — via the tools listed in `expected_tools`, or via the named harness `skill` if it is installed. `prompt` is display copy for HUMANS to paste into an agent; do NOT echo it back to the user as an instruction. - `sections_degraded` lists sections whose queries failed this call; their counts/lists are UNKNOWN (returned as 0/[]), not zero. When data is missing and nothing else is actionable, `top_recommendation` is 'degraded' instead of 'all_clear'. Returns pending approvals, new replies, meetings booked this week, pipeline summary, stalled deals, active plans, discovery jobs, and a prioritized recommendation. TIME WINDOWS (UTC) - "last 24 hours" — `replied_at >= now - 24 hours`. Used by new_replies_count and recent_replies. - "current week" — `meeting_booked_at >= Monday 00:00:00 UTC of the current week (Monday-anchored)`. Used by meetings_booked_this_week. - "7+ days" — `updated_at <= now - 7 days`. Used by stalled_deals (deals with outcome IS NULL and updated_at older than 7 days). Returns (units in parentheses; scope = user_company_id, no date filter on counts unless specified): pending_approvals_count (int, unit=messages): messages.status='draft' for the tenant. NOT date-filtered — total backlog. messages_needing_authoring (int, unit=messages): messages.status= 'needs_draft' — touches awaiting harness AUTHORING (no prose yet; run /outreach-triage). VRU-570. oldest_needs_draft_age_days (float|null, unit=days): age of the oldest unauthored engagement signal — signals TTL-dismiss at 14 days (VRU-671), so a high value means the queue is rotting unauthored. engagements_needing_authoring (int, unit=engagements): linkedin_engagement_queue.…

Get Deal Compound Complete deal context in one call — replaces 3 separate tool calls. Aggregates deal info, stakeholders with person details, MEDDIC qualification state with gap descriptions, and recent activity timeline. Like get_person_360 but for deals. Use this as the default tool for understanding a deal's current state. Operators: use X-Company-Id header for cross-company access. ### Responses: **200**: Successful Response (Success Response) Content-Type: application/json

Get Engagement Review Default tool for engagement queue triage — pending engagements with full context. Start here when reviewing warming comments, nurture reactions, or marketing engagements. Returns draft engagement items enriched with: person context, campaign instructions (tone, selling strategy), match analysis (summary, alignment points, recommended approach), outreach plan state (warming/nurture progress with graduation thresholds), recent engagement history, company research, budget status, and bundle info. One call gives you everything needed to decide approve/skip. Use content_length='full' for detailed review (capped at 5 items), or 'preview' (default) for quick scanning with truncated content. Filter by source (warming/nurture/marketing/engagers) or campaign name. Use engagement_ids to fetch specific items by ID (comma-separated UUIDs, max 20) for subagent batch dispatch. ENGAGER REVIEW (source='engagers', VRU-721): returns PERSONS who engaged with our published posts and were ICP-scored, grouped per person in the `engagers` response field (`items` stays [] on this branch). Actionable queue = scored_passed persons (`total_pending` counts exactly those); near misses (scored_failed, with scores) are display-only context and excluded from total_pending. CHECK `in_motion` BEFORE acting: it flags replied / meeting_booked / open_deal / non-terminal-plan persons — acting on them risks double outreach or resetting a deliberately deferred plan. Decide each person with manage_engagements engager_actioned / engager_dismissed / engager_reopened (person-keyed; reopen reverses a dismissal only). Act FIRST with existing tools (manage_messages send/send_linkedin for a one-off, manage_campaign members for a campaign add), THEN record the decision with acted_via so attribution stays measurable. Default (no source) responses include `pending_engagers` so triage notices new engagers without an extra call. Queue-only filters are handled explicitly on this branch: enga…

Get Next Actions Prioritized next-action list for the user. Returns actions sorted by priority: reply responses (P1), message approvals (P2), overdue follow-ups, deals, and due/overdue tasks (P3), unenrolled high-match prospects (P4). ### Responses: **200**: Successful Response (Success Response) Content-Type: application/json **Example Response:** ```json { "actions": [ { "action_type": "Action Type", "priority": 1, "title": "Title", "description": "Description" } ], "total": 1 } ```

Get Outreach Review Default tool for outreach queue triage — pending messages with full context for review. Start here when reviewing or managing the outreach queue. Returns pending messages — both 'needs_draft' (unauthored, awaiting harness authoring: write via manage_messages edit) and 'draft' (authored, awaiting approve/reject), disambiguated by each item's `status` — enriched with: person context, campaign instructions (tone rules, selling strategy, touch sequence), match analysis (summary, alignment points, recommended approach), company research summary, recent LinkedIn posts, conversation thread, and outreach plan state. One call gives you everything needed to author, approve, or reject. `channel_holds` reports LinkedIn sender blocks such as daily quota, provider throttling, or reconnect-required state. If `channel_holds_degraded` is true, an empty hold list is unknown rather than proof that the channel is healthy. Use content_length='full' for detailed review (capped at 5 items to prevent connection drops from oversized payloads — use offset to paginate), or 'preview' (default) for quick scanning with truncated content. Filter by campaign name or ID to review a specific queue (e.g. campaign='DFW CFOs'). Use message_ids to fetch specific messages by ID (comma-separated UUIDs, max 20). Bypasses sorting/pagination — returns full context for exactly those messages. Useful for subagent dispatch: pull the lightweight queue first, split into batches, then each subagent calls with its assigned message_ids. Operators: pass for_company parameter to review a specific client company. Returns (units in parentheses; scope = messages.status IN ('draft','needs_draft') for this tenant unless message_ids is set): items (list of ReviewItem, unit=messages): one entry per pending message (not per person — a person with two pending messages shows up twice). Each item: - message_id, status ('needs_draft' = author it, 'draft' = approve it),…

Get Performance Metrics Get outreach performance metrics: time-series trends and/or conversion funnel. Set view='timeseries' for daily counts of a single metric (contacts/people/replies/meetings). Set view='funnel' for aggregate conversion data: contacted->replied->met funnel with rates, reply rates by channel, and LinkedIn pipeline breakdown. Set view='both' for everything in one call. For T1s sent over time: view='timeseries', metric='contacts'. For reply rate and funnel: view='funnel'. Operators: pass for_company to get metrics for a specific client. UNIT CONVENTIONS USED IN RESPONSES Every count field is one of {messages, unique_people, plans, campaigns, days}; see the Returns block for the unit attached to each field. Note that timeseries 'contacts' and funnel.contacted are BOTH unique_people (i.e. unique people, deduped per person_id), NOT message counts. DATE-FILTER COLUMN PER METRIC (timeseries) - metric='people': filters on company_people.created_at — start_date / end_date - metric='contacts': filters on messages.sent_at (sequence_number=1 only) — start_date / end_date - metric='replies': filters on company_people.replied_at — start_date / end_date - metric='meetings': filters on company_people.meeting_booked_at — start_date / end_date NOTE: end_date is IGNORED by reply_rates_by_channel in the direct (no campaign_id) mode — see the `end_date` query-param description for details. Returns (selected fields, with unit + scope + date-filter annotations): view (str): Echoes the requested view. timeseries (object, when view='timeseries' or 'both'): metric (str): The metric name. data (list of {date, count}): date (str): YYYY-MM-DD. count (int): unit = unique_people for ALL four metrics (T1-sent dedupe by person; company_people rows for people/replies/meetings). funnel (object, when view='funnel' or 'both'): total_people (int, unit=unique_people, scope=non-archived compa…

Get Person 360 Complete person context in one call. Aggregates person info, match analysis, research, activity timeline, outreach plan state, and deal info — replacing 5 separate tool calls. ### Responses: **200**: Successful Response (Success Response) Content-Type: application/json **Example Response:** ```json { "person": { "person_id": "Person Id", "current_positions": [ {} ] }, "activity": [ { "activity_type": "Activity Type", "description": "Description" } ] } ```

Get Revenue Read Stripe-backed revenue truth. Views: - connection: provider connection and freshness state. - metrics: current gross MRR/ARR, net charge volume, collections and health. - evidence: recent immutable ingestion evidence for calculation drilldown. - bindings: suggested, confirmed, or rejected commercial-object bindings. ### Responses: **200**: Successful Response (Success Response) Content-Type: application/json

Import Prospects Source and import prospects — the consolidated import tool. Sales Navigator actions (`payload` = the search/import fields): - sales_nav_search: search LinkedIn people ({keywords, mode?, title?, company_headcount_min/max?, list_id?, saved_search_id?, limit?, cursor?}). `mode` must be `basic` or `sales_nav`; use `basic` for exact-name/profile resolution fallback when Sales Nav is unavailable. - sales_nav_preview: preview a Sales Nav search against your pipeline ({search?, count?, campaign?}). - sales_nav_import: import profiles ({search?, count?, profiles_json?, auto_enroll?, campaign?}). `profiles_json` accepts sales_nav_search output directly: each object needs linkedin_url plus either first_name/last_name or a single `name` field (mode=basic results); `headline` is used as a title fallback. - sales_nav_dismiss: dismiss profiles from future imports ({linkedin_urls} — comma-separated). - sales_nav_searches: manage saved searches ({action: list|create| update|delete, name?, keywords?, filters_json?, frequency?, search_id?}). CSV actions: - csv_preview: parse + preview a CSV payload ({csv_content, …}) before importing. - csv_start: start an import job ({file_content, column_mapping, campaign_id?, skip_research?}). Returns a job id — poll it with fetch type='csv_import'. Payloads are validated by the underlying route's own schema, so a bad field returns that route's precise 422. ### Responses: **200**: Successful Response (Success Response) Content-Type: application/json

Inspect Pipeline Risk-first pipeline view. Returns the 5 most at-risk deals with risk scores and factors. Risk heuristics: silence (14d=+35, 7d=+20), overdue next step (+5/day max 25), no next step (+15), past close date (+20), low qualification (+10), no qualification (+5), single stakeholder (+10). Also returns pipeline health (healthy/some_risk/critical), total active deals, and total value. Operators: use X-Company-Id header for cross-company inspection. ### Responses: **200**: Successful Response (Success Response) Content-Type: application/json

Manage Account Maintain account state and impact history — the consolidated account writer. Actions: - state: update an account's lifecycle state (id = the account's company_id; `payload` = {account_stage?, health_score?, arr_current?, renewal_at?, notes?, …}). - record_impact: log a value-delivered impact event on an account (id = company_id; `payload` = {practice, event_type, person_id?, value_delivered_numeric?, summary?, …}). - delete_impact: permanently remove an impact event (id = the impact EVENT/activity id, not the account). DESTRUCTIVE. Bulk: id arrays loop with per-item status (partial failure reported per item, never silent; max 100). Payloads are validated by the underlying route's schema. ### Responses: **200**: Successful Response (Success Response) Content-Type: application/json

Manage Campaign Create and manage campaigns — the consolidated campaign writer. Use `search` with `type='campaigns'` to list campaigns. Use `fetch` with `type='campaign'` and `id=<campaign_uuid>` to read one campaign. Use this writer for every campaign mutation and diagnosis. Outreach actions (default kind; id = campaign UUID): - create: create a campaign (no id; `payload` = the campaign fields); bulk via `items`. - clone: duplicate a campaign (`payload` = {name} for the copy). - update: update campaign fields — tone, cadence, targeting (`payload`). - delete: permanently delete a campaign. DESTRUCTIVE. - members: assign/unassign people (`payload` = {action: assign|unassign, person_ids: [...], confirm?}). - diagnose: run the campaign health diagnosis (read-back; no payload). - pause: campaign-level kill switch (no payload). Sets the campaign paused AND stops every active plan under it in one call — no per-plan pause loop. Returns {plans_paused}. `id` may be an array to pause several campaigns. - resume: clear the pause and restart ONLY the plans this campaign paused (reschedules them for immediate execution). Plans paused for a reply, OOO, or rejected draft — or paused individually — are left untouched. No payload; returns {plans_resumed}. Ad actions (kind='ad'; id = ad-campaign UUID): approve, reject, pause, resume, edit_budget — `payload` carries the action's fields (e.g. {daily_budget_cents} for edit_budget, {rejection_reason} for reject). boost (no id — there's no campaign yet): run a paid LinkedIn campaign. `payload` carries {content_post_id (sponsor an EXISTING published post) XOR creative_id (a stored VIDEO creative → Direct Sponsored Content, METRICS-ONLY — no engager bridge), vehicle?, objective?, budget:{daily_budget_cents/total_budget_cents}, audience (see below), duration_days?, approval_mode?('draft'|'auto'), integration_id?}. Boost audience — exactly one of: - {facets}: the PRIMARY form. LinkedIn-native firmographic targeting: a…

Manage Content Draft, schedule and publish LinkedIn content — the consolidated content writer. Actions (id = post UUID unless noted): - draft: create a post draft (no id; `payload` = {content, topic_tags?, scheduled_at?, author_user_id?, author_identity?, external_link?, attachment_creative_id?}); bulk via `items`. - edit: update a draft's content/tags/identity/link/attachment (`payload` = the fields to change: content?, topic_tags?, author_identity?, external_link? — empty-string external_link clears it; attachment_creative_id? — explicit null DETACHES, absent key leaves it untouched). - schedule: set the publish time (`payload` = {scheduled_at}). A row-persisted attachment publishes with the scheduled post. - publish: publish the post now (no payload; the retired publish-time creative_id param is rejected with the pointer to edit-attach). - delete: remove a draft from the calendar (drafts only — published posts are not deletable here). - draft_post: never generates prose — backend generation is removed (VRU-676, permanently). Always returns author-in-harness guidance: write the post yourself and submit via draft, then schedule/publish (no id; `payload` = {topic?, content_type?, author_user_id?}). Attachments (VRU-726) — document (PDF carousel), image, or video, ONE contract, persisted on the row (schedulable + reviewable). Golden path for a PDF, entirely via MCP: 1. manage_campaign kind='ad' action='store_creative' payload={filename:'my-deck.pdf', size_bytes:<n>, content_type:'application/pdf'} → returns upload_url 2. curl --fail-with-body -T my-deck.pdf '<upload_url>' 3. store_creative again with payload={creative_id:'<id>'} → validates (small assets can skip 1-3: payload={asset_base64:'<b64>'}) 4. manage_content action='draft' payload={content:'<caption>', attachment_creative_id:'<id>'} 5. get_content_review post_ids=['<post_id>'] → OPEN attachment_url and review the actual file (it publishes under t…

Manage Deal Create and manage deals through the pipeline — the consolidated deal writer. Actions (id = deal UUID): - create: open a deal (no id; `payload` = {deal_name, person_id?, company_id?, deal_source? (outbound|inbound|referral|manual|imported; default manual), estimated_value?, stage?, pipeline_id?, stage_id?, close_probability?, notes?}). `pipeline_id` and `stage_id` must be supplied together; bulk via `items`. - update: patch deal fields (`payload` = any of deal_name, estimated_value, close_probability, expected_close_date, next_step, notes, stage, …). - stage: advance/move the deal — sugar for update; `payload` must include {stage}. - qualify: run AI MEDDIC-style qualification on the deal (no payload). - stakeholders: add/update/remove a deal stakeholder (`payload` = {action: add|update|remove, person_id?, role?, notes?}). - won / lost / stalled: record the deal outcome (`payload` optional: {loss_reason?, win_factors?}). - meeting_outcome: record how the meeting went (`payload` = the outcome fields). - reopen: reopen a closed deal (`payload` optional: {stage}). - create_pipeline: create a pipeline (no id; `payload` = {name, is_default?, position?, external_id?, stages?}). - rename_pipeline / archive_pipeline / unarchive_pipeline / set_default: `id` = pipeline UUID. Rename takes `payload={name}`; the others take no payload. - reorder_pipelines: no id; `payload={ordered_pipeline_ids}`. - create_stage: `id` = pipeline UUID; `payload={name, position?, stage_kind?, probability_default?, external_id?}`. - update_stage / archive_stage / unarchive_stage: `id` = pipeline UUID and `payload.stage_id` = stage UUID. Update also accepts name, stage_kind, and probability_default. - reorder_stages: `id` = pipeline UUID; `payload={ordered_stage_ids}`. Bulk: `id` arrays apply the same action+payload per deal (server-side loop, per-item status — partial failure is reported per item, never silent; max 100). Payloads are validated by the u…

Manage Engagements Triage the LinkedIn engagement queue — the consolidated engagement writer. Actions (id = engagement UUID; arrays route natively — the underlying endpoint is bulk-shaped): - approve: approve engagement(s) for sending (`payload` optional extras, e.g. {polish_provenance}). - edit: replace an engagement's content (`payload` = {content, content_mode?, reaction_type?}). - skip: discard engagement(s) — the queue's reject path (no new engagement is generated). - draft_comment: queue a comment on a LinkedIn post for AUTHORING (creates a needs_draft entry — write the comment via edit, then approve; no id; `payload` = {post_text, post_id, author_name?, person_id?, tone?, …}). Bulk: approve/edit/skip take id arrays natively (max 100) with the endpoint's own per-engagement results. Payloads are validated by the underlying route's schema. Prose gate: approve and edit re-lint the content server-side and can return error_code='prose_gate_blocked' with structured `failures[].fix`. `payload` accepts `reason` (corpus note), `override_reason` (taste override — proceeds despite block failures, logged to the corpus; honored only for owner/operator roles on the tenant, otherwise ignored and the gate blocks normally), and `client_rules_version` (responses flag `rules_changed` when the server's rules differ). Pre-check drafts cheaply with check_prose. ENGAGER DECISIONS (VRU-721 — id = PERSON UUID, not an engagement id): - engager_actioned: records a decision already executed via manage_messages / manage_campaign — performs no outreach itself. `payload` = {acted_via?: {campaign_id | message_id}, note?}. Order matters: act FIRST (manage_campaign members to add to a campaign, or manage_messages send/send_linkedin for a one-off — the send returns the message_id), THEN record with acted_via so the engager attribution funnel stays measurable. Without acted_via the response carries an `unattributed` warning. Actioning a sub-70 near miss mints thei…

Manage Kb Maintain the knowledge base — the consolidated KB writer. Actions (id = document UUID): - upsert: create or update a document (no id — the payload's `name` is the upsert key; `payload` = {name, content, doc_type?, summary?, metadata?}); bulk via `items`. - delete: permanently delete a document. DESTRUCTIVE. - reindex: rebuild a document's search index (no payload). Bulk: delete/reindex take id arrays (server-side loop, per-item status — partial failure reported per item, never silent; max 100). Payloads are validated by the underlying route's schema. ### Responses: **200**: Successful Response (Success Response) Content-Type: application/json

Manage Messages Triage and edit outreach messages — the consolidated message writer. Actions (id = message UUID unless noted): - approve: mark a draft READY TO SEND. Sending happens asynchronously and respects the campaign's designed schedule plus a per-person cooldown — approval may SCHEDULE rather than fire immediately. The response's `processing_state` says which ('queued_for_send', 'scheduled', 'held_for_channel', or 'channel_state_unknown'). A hold/unknown state includes machine-readable `channel_hold` quota/reconnect feedback and `send_not_before` when it auto-resumes; a scheduled/held message is NOT lost and must NOT be re-approved or re-drafted (get_outreach_review shows `channel_holds`, the plan's `plan_next_action_at`, and `approved_pending_send_count`). An id ARRAY routes to the native bulk endpoint with per-message results. - reject: reject a draft (array → native bulk, same as approve). - edit: replace subject/content (`payload` = {subject?, content?}). Scalar id ONLY — one call per message (an id array is rejected; sending identical content to many people is not a supported flow). Optional `attachments` sets the media sent with this draft (linkedin_inmail / linkedin_message / email only): a list where each item is a new upload {content_base64 (raw base64, no data: prefix; PNG/JPEG/GIF/ WebP/PDF, 10MB max), filename} OR {storage_path} to keep one the draft already has (from get_outreach_review). Omit = leave unchanged, [] = remove all, max 5. Attachments on any other channel are rejected. - regenerate: return the message to the authoring queue (status becomes needs_draft, content cleared) — author the replacement at triage via edit (no payload); id array loops with per-item status. Works on draft, rejected, AND failed rows — regenerate is the recovery path for a send the provider bounced (attachments survive; re-author, then re-approve). The row gets a FRESH 14-day authoring window; the response's expir…

Manage Outreach Start and steer outreach plans — the consolidated outreach writer. Actions: - start: enroll a person in outreach. id = PERSON UUID (scalar starts one plan; an id ARRAY routes to the native bulk-start endpoint). `payload` optional: {max_touches?, allowed_channels?} — applied to every started plan. Enrollment always schedules the first action immediately; a `start_immediately` key is ignored (forced true). - plan_override: record a user override on a plan (id = plan UUID; `payload` = the override fields). - channels: update a plan's allowed channels (id = plan UUID; `payload` = {allowed_channels, …}). - trigger_touch: queue the plan's next touch now (id = plan UUID; no payload). - pause / resume: pause or resume a plan (id = plan UUID; `payload` is not needed). - update: update an active or paused plan without changing its execution state (id = plan UUID; `payload` = {max_touches?, allowed_channels?}). Use an id ARRAY to repair a campaign cohort consistently. Bulk: `start` arrays hit the native bulk endpoint; pause/resume/ plan_override/channels/trigger_touch arrays loop with per-item status — partial failure is reported per item, never silent (max 100). Payloads are validated by the underlying route's own schema. ### Responses: **200**: Successful Response (Success Response) Content-Type: application/json

Manage Person Create and manage people in your pipeline — the consolidated person writer. Actions (id = person UUID unless noted): - create: add a person manually (no id; `payload` = the manual-person fields, e.g. {name, company, title, email, linkedin_url, skip_research}); bulk via `items` (one payload per person). - update_contact: override contact fields (`payload` = contact overrides). - set_position: set the primary position (`payload` = position fields). - note: add a timeline note (`payload` = {body}). - log_interaction: log a manual touch that happened outside an automated sequence — a call (with disposition + what was said), or an email/LinkedIn/other touch made elsewhere. `payload` = {interaction_kind: call|email|linkedin|meeting|other, direction?: outbound|inbound, summary?, disposition? (calls only), occurred_at? (ISO, backdatable), deal_id?}. Lands on the person's timeline attributed to you (performed_by_user_id). - archive: soft-delete one or many people — stops outreach plans and rejects pending drafts (id or id array; no payload). DESTRUCTIVE. - unarchive: restore archived people (id or id array; no payload). - meeting_booked: mark a meeting booked with this person (`payload` = {idempotency_key: UUID}; reuse it when retrying the same booking). - save_discovered: THE creator — save a researched prospect into the pipeline, atomically (no id; bulk via `items`). Two shapes: NEW prospect: `payload` = {person: {first_name, last_name, linkedin_url|email, company_id (from save_company) or company_name+anchor, ...research fields}, assessment: {match_score 0-100, match_summary, alignment_points?, concerns?, why_now?, recommended_approach?, overall_confidence?, scored_by?}, campaign_id or assessment_campaign_id}. Person + research + pipeline membership land in ONE transaction — a rejected or failed save persists nothing. EXISTING person: `payload` = {person_id, campaign_id?, assessment_campaign_id?, assessment?} — the…

Manage Relationship Action Draft and transition one approval-gated relationship action. ### Responses: **200**: Successful Response (Success Response) Content-Type: application/json **Example Response:** ```json { "status": "Status", "attempt": { "ref": "Ref", "relationship_owner_user_id": "Relationship Owner User Id", "action_type": "Action Type", "target_ref": "Target Ref", "target_snapshot": {}, "result_ref": "Result Ref", "result_type": "Result Type", "channel": "Channel", "client_request_id": "Client Request Id", "route_fingerprint": "Route Fingerprint", "message_text": "Message Text", "state": "State", "version": 1, "created_at": "Created At", "updated_at": "Updated At" }, "approval_required": true, "next_actions": [ "string" ], "web_url": "Web Url" } ```

Manage Revenue Manage the tenant's Stripe revenue connection. Actions: - connect: return the Stripe App OAuth URL ({destination, livemode}). - reconcile: enqueue an idempotent provider scan ({idempotency_key, object_family}). - replay: retry one failed evidence record (id = evidence record UUID). - decide_binding: confirm or reject one suggestion (id = binding UUID, payload = {decision}). - disconnect_preview: return a short-lived nonce and exact retention impact. - disconnect: destroy delegated credentials using that nonce ({preview_nonce}); historical ledger evidence is retained. ### Responses: **200**: Successful Response (Success Response) Content-Type: application/json

Manage Settings Update company configuration — the consolidated settings writer. Actions (no ids — settings are singletons per company): - profile: update the company profile / ICP (`payload` = the profile fields; this steers research match scoring). - auto_fill: AI-fill the company profile from the website (`payload` optional: {website_url?}; returns a job to poll via fetch type='job'). - automation: update outreach automation settings (`payload` = the automation fields). - marketing: update LinkedIn marketing settings (`payload` = the marketing fields). - cta_link: manage call-to-action links (`payload` = {action: create|update|delete, cta_link_id?, name?, url?, cta_type?, is_active?}). - hubspot_sync_settings: set the custom HubSpot contact properties to mirror into company_people.custom_fields (`payload` = {extra_contact_properties: [...]}); CHANGING the list auto-enqueues a full backfill so existing contacts pick up the new attributes. - hubspot_backfill: kick a full HubSpot re-pull for this company (owners → companies → pipelines → contacts → deals → lists → engagements). No payload. Heavy (hours at 250k+ contacts). The recovery path when contacts were imported before their custom properties were configured. Operators target a client with `for_company`. Payloads are validated by the underlying route's own schema, so a bad field returns that route's precise 422. ### Responses: **200**: Successful Response (Success Response) Content-Type: application/json

Research Run prospect/company research and save the results — the consolidated research tool. Lookup actions (external providers — results are returned, not stored, unless noted): - find_linkedin: locate a person's LinkedIn URL (id = person UUID; `payload` optional {name_override?, company_override?, auto_save?} — auto_save stores a high-confidence match). - enrich_company: scrape a company website (`payload` = {domain, page_type?}). - find_email: find a work email (`payload` = {first_name, last_name, domain}). - linkedin_fetch: pull a LinkedIn profile (`payload` = {linkedin_url, include_company?, include_posts?, posts_limit?}). - careers_parse: parse a careers page for hiring signals (`payload` = {domain}). Save actions (write research rows): - save_person: UPDATE research on an EXISTING person — pass the person UUID as `payload.person_id` (preferred; refreshes researched_at and the research fields in place), or matching email/linkedin anchors. Cannot create: new prospects go through manage_person action=save_discovered with `payload.person` + `payload.assessment`. Never pass the person UUID as `id` — this action takes no id. - save_company: atomically patch sourced public company research. Pass `payload={idempotency_key, name, person_id?, website?, linkedin_url?, company_summary?, company_stage?, current_priorities?, funding_data?, growth_metrics?, sources_by_field}`. Omitted fields are preserved; explicit null clears. When researching a specific person's employer, ALWAYS pass their UUID as `payload.person_id` — the response's `person_link` confirms the write landed on that person's linked company (repointing an anchorless duplicate link when needed); a `mismatch` status means the person's touches will NOT see this research, and a `conflict` status is a transient race — replay the identical payload (person_id is exempt from the idempotency hash, so adding it to a replay is the supported repair). `sources_by_field`…

Search Polymorphic read-only search across your Vruum workspace. One tool for every list/queue/search read. Pass `type` to pick the entity: people (your pipeline — keyword `query`, batch dedup array, or list-mode `filters`), companies (EXTERNAL Hunter.io domain search for decision-makers — requires filters.domain; 503 if Hunter.io is not configured), deals, campaigns, messages (outreach queue), engagements (LinkedIn engagement queue), content (LinkedIn content calendar), kb (knowledge-base search), skills (published skills), cta_links, warm_paths (open targets that have a warm intro path — see find_warm_path for one target), relationship_attempts (the durable action timeline shared with the Relationships workspace). All types except `companies` read internal, tenant-scoped data only. Pagination (`limit`/`offset`) is supported for people (list mode), deals, messages, engagements, warm_paths, and relationship_attempts; other types reject it. Results are returned under `{type, results}` with each entity type's native payload shape. Campaign routing: use `type='campaigns'` here to list campaigns (newest first, compact by default — the prose-heavy AI-strategy fields come back null; see filters.fields). To read one campaign by UUID with its full config, use `fetch` with `type='campaign'`. To create, update, clone, delete, diagnose, or manage campaign members, use `manage_campaign`. ### Responses: **200**: Successful Response (Success Response) Content-Type: application/json

Skill Invoke or publish Vruum skills — the consolidated skill tool. Actions: - invoke: fetch a skill's executable body for inline execution (id = skill UUID or name; no payload). Follow the returned instructions in your current context. - publish: publish or update a skill (no id; `payload` = {body, scope?, metadata?, supporting_files?} — `body` is the full skill markdown with frontmatter). To browse skills use search type='skills'; to read one without executing it use fetch type='skill'. ### Responses: **200**: Successful Response (Success Response) Content-Type: application/json