vaaya

How to connect

• vaaya_test_connection

  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).

• vaaya_onboard

  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.

• consult

  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)

• use

  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.

• result

  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`

• session

  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.

• close

  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).

• gtm_brain

  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

• gtm_leads

  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 filt

• gtm_leads_find

  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.

• gtm_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

• gtm_message

  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 — prospect

• gtm_asset

  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_

• gtm_asset_produce

  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.

• gtm_lead_enrich

  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

• gtm_recall

  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 }.

• gtm_job

  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 tha

• gtm_composio

  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→GOOG

• gtm_signal_create

  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 dashb

• gtm_signal_act

  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 Worker

• gtm_automation

  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'

• gtm_mailboxes

  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.

• gtm_replies

  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.

• gtm_reply_approve

  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.

• gtm_reply_edit

  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.

• gtm_reply_reject

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

• brain_push

  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

• worker_create

  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: `na

• worker_list

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

• worker_findings

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

• worker_pause

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

• worker_resume

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

• worker_delete

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

• worker_run_now

  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 }.

Related servers