Vaaya MCP server

Vaaya's consultant. Describe ANY external capability you or the user might want — generate an image/video, search or scrape the web, run code in a sandbox, send/receive email, enrich a contact — and it helps figure out the best way, teaching the user what Vaaya can do. It is CONVERSATIONAL and remembers prior turns. It returns: mode='converse' (a reply to RELAY to the user verbatim — questions, options, ideas; get the user's response and call consult again with it, so the conversation continues), mode='call' (an ordered list of calls to run via `use`, with a message explaining the preferred choice + alternatives + why; multi-step results may contain placeholders like '<from step 1: sandbox_id>' — run earlier steps first and substitute), or mode='unsupported'. Every reply includes `suggestions` (2-3 things to do next) — surface these to the user. AFTER you run a `call` result's calls via `use`, call consult ONE more time with a short note on the outcome (what was produced / any failures) — it returns result-aware, Vaaya-grounded next steps to offer the user (the `call` result's `after_running` field reminds you). Call consult whenever you hit a capability gap or the user wants to know what's possible. It does NOT execute or bill — you run returned calls via `use`. ALWAYS show the user consult's `message` and `suggestions` and let them steer.

Close an E2B sandbox session and stop its billing. Pass the `session_id`. Captures the final metered uptime cost and releases the hold. ALWAYS call this when finished with a session — an open session keeps billing per second of uptime. Safe to call repeatedly (idempotent).

Act on a signal finding — the exit from discovery into the lead repository (VAA-100). action='find_people' (default) runs a paid Exa search (≤5¢) for decision-makers at the finding's company and upserts them into `gtm_leads` with source 'signal' and the signal headline as their hook/why; action='dismiss' marks the finding handled without spending. Both stamp acted_at so a finding is handled once (a second find_people returns already_acted). Pass `finding_id` (from `worker_findings` or the Workers page's buying-signals feed) and optionally `roles` to steer who to look for (default founder/CEO/CTO/Head-of/VP). Returns { ok, action, found, added, charged_cents }.

Approve a pending reply draft as-is and send it. Pass `message_id` (from gtm_replies). Sends from the user's own account; bills the send.

Reject a pending reply draft — discard it without sending. Pass `message_id`.

Fetch the status + output of an async job started by `use` (e.g. a video render). Pass the `job_id` that `use` returned with `{ async: true }`. Returns `{ status, result?, progress?, charged_cents }`: `running` (still working — when the job reports it, `progress` carries `{ phase, percent, rendered_frames, total_frames, eta_sec }` and `hint` is a one-line summary like "rendering 42% (380/900 frames, ~120s left)", so you can tell real progress from a hang; wait a bit and call again), `succeeded` (`result` holds the output, e.g. the video URL; the call is charged now), or `failed`/`cancelled` (no charge; on `failed`, read `error` AND `hint` — `hint` carries the service's usage notes, which usually explain how to fix the call). Safe to call repeatedly — it never starts new work or double-charges. ALWAYS use this to retrieve an async result instead of re-running `use` (re-running starts a new paid job).

Manage the user's campaign-free lead repository (people to reach out to — prospects, candidates, targets, investors; differently tagged for different uses). action='add' upserts people you already have (paste a list); each person = { first_name, last_name, title, company, email, linkedin_url, why_prioritized?, hook?, source? }; deduped per person within the user's scope so re-adding updates, never duplicates. action='list' returns leads (optional `q` search, `tag_id`/`segment_id` membership filter, `limit`). action='get' returns one lead by `id`, with its tags and any inbound reply conversations linked to them. action='tag' applies labels: { id | ids:[…], tags:["founder","warm-intro"] } (bulk-capable; creates missing tags, idempotent). action='untag' removes a label: { id | ids:[…], tag_id }. To DISCOVER new people via paid search, use `gtm_leads_find`; to group leads, use `gtm_segments`.

Attach, list and detach per-lead multimodal assets (a personalized research PDF, intro video, voice note, one-pager) — stored durably and retrievable per lead, reusable across segments. action='attach' links an artifact you already produced to a lead: { lead_id, artifact_id, role } where role ∈ research_pdf|intro_video|voice_note|one_pager|image|other (you can only attach your own artifacts). action='list' returns a lead's assets with presigned URLs (in-flight renders show as 'pending'): { lead_id }. action='detach': { lead_id, asset_id }. To GENERATE a new asset (paid), use `gtm_asset_produce`.

Program the GTM scheduler — durable, multi-step jobs that run on a thin server tick even when no agent is connected (multi-day workflows, standing watches, refreshes). action='schedule' creates one: { name, steps:[...], max_cost_cents?, related_segment_id?, related_lead_id?, start_at? }. Each step is either { type:'service', service, action, params, max_price_cents? } (a paid/free dispatcher call — poll signals, enrich, find) or { type:'reasoning', goal } (a bounded brain-grounded generation that records a decision). Steps run in order; a failed step or the budget cap PAUSES the job. Jobs NEVER send — manual-first holds. action='list' / 'get' { id } / 'cancel' { id }.

List recent worker findings (newest first), optionally for one worker. Read-only, free. Pass optional `worker_id` and `limit` (default 50).

Run all your ACTIVE workers immediately instead of waiting for the next scheduled tick (spends from your balance under the workers daily budget). Returns a summary { workers, newFindings, spentCents }.

Public onboarding hint for an agent whose user isn't linked to Vaaya yet. Returns where the human should go to connect (and sign up if new). Call this when vaaya_test_connection reports needs_auth, or any tool returns unauthorized, then relay the instructions to the user.

Run a command or code in an open E2B sandbox session (started by `use` with action `create_session`, which returns a `session_id`). Pass `session_id` plus either `command` (a shell command) or `code` (+ optional `language`: python/javascript/bash). Returns stdout/stderr/exit_code (or the code result). The sandbox stays alive — and billed per second of uptime — until you `close` it; re-running reuses the SAME box, so filesystem + process state persist between calls. ALWAYS `close` when done.

DISCOVER new ICP-fit people via paid Exa search and add them to the campaign-free lead repository (NOT a campaign). Bills per search. Pass `job_titles` (required — one search per title, up to 5) plus optional `seniority`, `industries`, `headcount`, `person_locations`, `company_locations`, and `max_fetch` (default 25). Returns { found, added, charged_cents }. The added people land in `gtm_leads` for review.

Produce a per-lead asset via a paid vendor call (e.g. a personalized intro video, voice note, image), then attach it to the lead. First `consult` to get the exact { service, action, params } for the media you want; pass them here plus `lead_id` and `role`. Bills through the wallet like any `use` call. Async renders (video) return { async:true, job_id } and the asset shows as 'pending' until the render lands (it reconciles automatically); sync renders attach immediately.

Act on the user's OWN connected calendar / CRM / spreadsheet (via Composio hosted auth). Pass `action`: 'book' (create a calendar event, 1¢), 'crm_log' (write a HubSpot note, free), or 'sheet_push' (update a Google Sheet, free) + `params` { arguments: <the tool's input>, tool_slug?: <override the default tool> }. If the account isn't connected it returns `not_connected` with a `connect_url` to send the user. Defaults: book→GOOGLECALENDAR_CREATE_EVENT, crm_log→HUBSPOT_CREATE_NOTE, sheet_push→GOOGLESHEETS_BATCH_UPDATE.

Inventory of the user's sending surfaces: `connected` (their own LinkedIn/email accounts), `provisioned` (Vaaya-managed prewarmed mailboxes with warmup_day + daily_cap; empty until mailbox provisioning ships), and `connect_url` (send the user here to link an inbox). Use before planning email volume: connected inboxes ≈ 20-30 sends/day each; provisioned boxes carry their own daily_cap. Read-only, free.

Round-trip ping that confirms the agent → Vaaya connection and whether the user is linked. Returns { ok:true, userId, scope, version, server_time } when linked, or { ok:false, needs_auth:true, verification_uri, signup_uri, instructions } when not linked yet — relay that to the user so they can connect (and sign up if new).

Execute a single call that `consult` handed you, and bill on success. Used for any external capability (image/video/audio generation, web search, scraping, email, document parsing, code sandbox, browser automation, embeddings, etc.). The server validates params against a registered schema and proxies to the upstream — you never pass URLs or API keys. Always get the exact (service, action, params, max_cost_cents) from `consult` first — don't guess them.

Read or update the user's GTM brain — the campaign-free source of truth for who they're reaching and what they're selling. action='get' returns identity/value-prop, the default ICP/audience, pain/proof/voice/guardrails, the active intent, and the lead count. action='set_intent' declares what the user is DOING — kind ('sell'|'recruit'|'fundraise'|'job_hunt'|'custom'), market, angle, goal — which grounds messaging later; this is campaign-free (no outreach happens). action='get_intent' returns the active intent; action='list_intents' returns intent history.

Draft, store, version and approve outbound messages in the reusable message bank — MANUAL-FIRST: this tool NEVER sends. action='draft' generates a personalized message for a lead, grounded in the brain (voice/pain/proof/guardrails) + the active intent + an optional segment angle: { lead_id, segment_id?, channel } where channel ∈ email|linkedin_note|linkedin_inmail (linkedin_inmail = a Sales Navigator InMail — needs an InMail-capable seat, carries a subject; there is NO cold-DM channel — prospects aren't 1st-degree connections). If the segment has a channel SET (its hard setting), drafting uses THAT channel regardless of the one passed — a LinkedIn segment never grows email drafts. Stored as a new draft version. action='store' saves your own copy: { lead_id?, segment_id?, channel?, subject?, body }. action='edit' creates a NEW version (history preserved): { id, body, subject? }. action='approve': { id }. action='list' returns every version for a lead: { lead_id }. action='get': { id }. action='mark_sent' RECORDS that the human sent it (no provider call): { id, via? }. To actually send, the user sends manually from their own account.

Ask the GTM brain what it knows. Fuses semantically-recalled facts (chosen messaging angles, sent messages, enriched leads — everything the brain has learned) with matching leads and segments. Use it to ground your next move: 'what do we know about X', 'who in fintech haven't I contacted', 'which segments cover founders'. Pass { query }. Returns { facts, leads, segments }.

Group campaign-free leads into OPTIONAL segments — each carries its own messaging angle/goal (and, later, a schedule). The same lead can sit in many segments with no duplication. action='define' creates-or-updates a segment by name: { name, angle?, goal?, intent_id?, channel? }. `channel` is the segment's HARD channel setting — once set, EVERY draft for the segment uses it (the UI shows it on the segment page under Positioning): 'email' | 'linkedin' (= invite + note) | 'linkedin_inmail' | 'mixed' to clear it. action='add_leads' links leads: { segment_id, lead_ids:[...] } (idempotent). action='remove_lead': { segment_id, lead_id }. action='list' returns segments with member counts. action='get': { id }. action='coverage': { segment_id } returns readiness buckets (members / drafted / approved / sent / with assets). Segments are NOT campaigns and never send anything by themselves — an explicit gtm_automation message_auto_send rule (opt-in) is the only way a segment's APPROVED messages go out automatically.

Reveal a lead's contact info and write it onto the lead — a three-rung ladder, each rung only when the cap covers it: Prospeo (verified email by linkedin_url, 5¢, free on a miss) → Nyne (55¢ — full profile with emails AND phone from any identifier) → Apollo (10¢ final backup). Pass { lead_id, max_cost_cents: 70 } for the full ladder. Bills through the wallet. Returns { ok, email, phone?, charged_cents }. For a reverse lookup on someone who is NOT a lead yet (a bare email / phone number / social handle), call use({service:'nyne', action:'person-enrich'}) directly and poll nyne:result.

Create a standing SIGNAL WATCH: a plain-English ICP query Vaaya polls (~every 6h via Exa) for fresh buying signals — funding, hiring, launches, leadership changes, press. e.g. 'HVAC companies founded in Los Angeles' or 'seed-stage B2B SaaS that just raised'. Pass `query` (required) and optional `signal_types` (subset of funding|hiring|launch|leadership|press; default all). This is a thin alias of `worker_create` with kind:'signal' — the watch is a 'signal worker' and appears on the Workers dashboard (the one watching surface), where each company can be worked into outreach by hand. Returns { ok }. Creating a watch is free; polling spends from the user's balance under the workers daily budget.

List the prospect-reply drafts awaiting your approval (newest first). Each row carries `leadId`/`leadName` when the sender matches a lead in the repository (see gtm_leads). Free.

Add a fact to the COMPANY brain — the shared org knowledge graph every teammate's agent reads. Use when the user explicitly wants to save/remember something for their whole company/team (e.g. "save that Acme uses Salesforce to the company brain"). The fact is added DIRECTLY and immediately (no approval step). Only works for an active member of a company brain (a company-email-domain user who hasn't been removed); others get an error. Personal facts are captured automatically by `consult` — only use `brain_push` for deliberate company-wide knowledge. Pass `fact`. Free; returns { ok, message } or { ok:false, error }.

Pause a worker so it stops running. Pass `worker_id`. Free.

Manage the user's OPT-IN autopilot rules (VAA-105). With NO rules, nothing ever auto-sends — creating a rule is the user explicitly turning automation on for a flow they know works, so only do it when they clearly ask. Kinds: 'reply_auto_send' (a classified inbound reply matching `intent_classes` at ≥ `min_confidence` — default 0.8 — is approved + sent instead of held in the inbox) and 'message_auto_send' (an APPROVED message for a member of `segment_id` on `channel` — 'email' or 'linkedin_note' = LinkedIn invite+note — sends automatically on approval). Every rule has a `daily_cap` (default 10); the send paths' gates (throttle, wallet, GTM_ENABLED) still apply, sends bill the user like manual ones, and each auto-send is logged to the brain. action='create'|'list'|'pause'|'resume'|'delete' (pause/resume/delete take `rule_id`).

Edit a pending reply draft and send the edited text. Pass `message_id` and `text`. Sends from the user's own account and bills the send.

List your workers with kind, status, cadence, last run, and finding counts. Read-only, free.

Delete a worker and its findings. Pass `worker_id`. Free.

Create a WORKER: a standing job Vaaya runs on a schedule to watch the web and surface only what's NEW or changed, then notify. General-purpose — use it for anything that needs a constant eye on the internet. Each worker is named by its `kind`: a signaling system → 'signal worker', a job hunt → 'job search worker', anything else → 'custom worker'. Pass `query` (plain-English: what to watch for), `cadence` (how often), and `kind` (signal|job_search|research|custom — drives the name). Optional: `name` (override the auto name), `sources` (array of URLs — give URLs to watch those exact pages for changes; omit to do a recency web search), and `notify_slack_webhook` (a Slack incoming-webhook URL to ping with new findings). Findings appear on the Workers dashboard, deduped so you only hear about each thing once. Creating is free; each scheduled run spends from the user's balance under their workers daily budget. Returns { ok, worker_id }.

Resume a paused worker. Pass `worker_id`. Free.