# Vaaya — full MCP tool reference for agents

> One MCP server, pay-per-call, no API keys. Remote: https://vaaya.ai/mcp
> (Streamable HTTP, OAuth 2.1 + dynamic client registration, anonymous
> tools/list). Stdio: `npx -y @vaaya/mcp`. Official registry: ai.vaaya/mcp.

## What agents do with Vaaya

Generate images & video (Nano Banana Pro 2, GPT Image 2, Seedream, Kling,
Seedance), produce narrated product demo videos from a raw screen capture,
search the web (Exa, Parallel), scrape at scale (Firecrawl), run deep/market/
competitive research with cited sources, find & enrich sales leads with
verified contacts, watch the web on a schedule (pricing, jobs, news, signals),
execute code in sandboxes (Modal), automate browsers (Browserbase), send &
receive email (AgentMail), and persist memory (mem0/Zep/Letta).

## Usage pattern

1. Call `consult` with a plain-English intent. It returns the exact
   `use(service, action, params, max_cost_cents)` call(s) to run.
2. Execute with `use`. Billed only on success; `max_cost_cents` is a hard
   spend ceiling. Async jobs return a job_id — poll with `result`.
3. Never invent service/action names; always route through `consult`.

## Tools (34)

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

No parameters.

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

No parameters.

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

Parameters:
- `intent` (string, required) — Plain-English description of what you want, or your answer to a previous clarify question. Be concrete — include the prompt text, URL, budget, or target the task implies.

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

Parameters:
- `service` (string, required) — Service identifier, taken verbatim from the call `consult` returned.
- `action` (string, required) — Action within the service (e.g. "search", "generate", "create_session"), taken from the call `consult` returned.
- `params` (object, required) — Parameters from the call `consult` returned, validated against the service's registered schema.
- `max_cost_cents` (number, required) — Hard ceiling in cents on what you will be charged. `use` refuses if the registry price exceeds this. Pick at least 2× the listed price so retries work.
- `intent` (string) — Optional: the one-line `why` from the consult call you're running (or the user's goal for it). Used only for internal transaction visibility — it never affects validation, billing, or execution. Pass it through when you have it.

### 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` (`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).

Parameters:
- `job_id` (string, required) — The job_id returned by an async `use` call.

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

Parameters:
- `session_id` (string, required) — The session_id returned by create_session.
- `command` (string) — Shell command to run in the sandbox.
- `code` (string) — Code to execute (alternative to `command`).
- `language` (string) — Language for `code`: python (default), javascript, or bash.

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

Parameters:
- `session_id` (string, required) — The session_id to close.

### 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 active intent; action='list_intents' returns intent history.

Parameters:
- `action` (string) — What to do. Defaults to 'get'.
- `kind` (string) — set_intent: what the user is doing. Defaults to 'sell'.
- `market` (string) — set_intent: the target market/audience in plain English.
- `angle` (string) — set_intent: the core positioning/angle for this outreach.
- `goal` (string) — set_intent: the outcome the user wants.

### 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 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`.

Parameters:
- `action` (string) — Defaults to 'list'.
- `people` (array) — add: the people to upsert.
- `q` (string) — list: free-text filter.
- `tag_id` (string) — list: only leads with this tag.
- `segment_id` (string) — list: only leads in this segment.
- `limit` (number) — list: max rows (default 200, max 1000).
- `id` (string) — get/tag/untag: the lead id.
- `ids` (array) — tag/untag: MANY lead ids at once (bulk; use instead of `id`).
- `tags` (array) — tag: label names to apply.

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

Parameters:
- `job_titles` (array, required) — ICP job titles (required).
- `seniority` (array) — Seniority filters, e.g. ["vp", "director", "c_suite"].
- `industries` (array) — Industry filters, e.g. ["saas", "fintech"].
- `headcount` (array) — Company size ranges, e.g. ["11-50", "51-200"].
- `person_locations` (array) — Where the person is located, e.g. ["san francisco", "united kingdom"].
- `company_locations` (array) — Where the company is headquartered.
- `max_fetch` (number) — Max people to fetch (default 25).

### 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' 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.

Parameters:
- `action` (string) — Defaults to 'list'.
- `name` (string) — define: the segment name.
- `angle` (string) — define: the per-segment messaging angle.
- `goal` (string) — define: the segment goal.
- `intent_id` (string) — define: optional linked intent id.
- `channel` (string) — define: the segment's hard channel — 'linkedin' means invite + note; 'mixed' clears it. Omit to leave unchanged.
- `segment_id` (string) — add_leads/remove_lead/coverage: the segment id.
- `id` (string) — get: the segment id.
- `lead_ids` (array) — add_leads: lead ids to link.
- `lead_id` (string) — remove_lead: the lead id to unlink.

### 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 — 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.

Parameters:
- `action` (string) — Defaults to 'list'.
- `lead_id` (string) — draft/store/list: the lead.
- `segment_id` (string) — draft/store: optional segment for the angle.
- `channel` (string) — draft/store: defaults to 'email'.
- `subject` (string) — store/edit: email subject line.
- `body` (string) — store/edit: the message body.
- `id` (string) — get/approve/edit/mark_sent: the message id.
- `via` (string) — mark_sent: how it was sent (e.g. "gmail", "linkedin").

### 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_id }. action='detach': { lead_id, asset_id }. To GENERATE a new asset (paid), use `gtm_asset_produce`.

Parameters:
- `action` (string) — Defaults to 'list'.
- `lead_id` (string) — the lead.
- `artifact_id` (string) — attach: the vaaya artifact id.
- `role` (string) — attach: the asset role. Defaults to 'other'.
- `asset_id` (string) — detach: the lead_asset id.

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

Parameters:
- `lead_id` (string, required) — the lead to attach to.
- `service` (string, required) — the vendor service (from consult), e.g. "fal".
- `action` (string, required) — the vendor action (from consult).
- `params` (object) — the vendor params (from consult).
- `role` (string) — the asset role. Defaults to 'other'.
- `max_cost_cents` (number) — spend cap for this produce.

### 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 handle), call use({service:'nyne', action:'person-enrich'}) directly and poll nyne:result.

Parameters:
- `lead_id` (string, required) — the lead to enrich.
- `max_cost_cents` (number) — spend cap (default 5 = Prospeo only; 70 runs the full Prospeo→Nyne→Apollo ladder).

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

Parameters:
- `query` (string, required) — what you want to recall.

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

Parameters:
- `action` (string) — Defaults to 'list'.
- `name` (string) — schedule: a human label.
- `steps` (array) — schedule: the ordered steps.
- `max_cost_cents` (number) — schedule: total spend cap for the job (default 300).
- `related_segment_id` (string) — schedule: link the job to a segment (optional).
- `related_lead_id` (string) — schedule: link the job to a lead (optional).
- `id` (string) — get/cancel: the job id.

### 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→GOOGLESHEETS_BATCH_UPDATE.

Parameters:
- `action` (string, required) — Which capability to invoke.
- `params` (object) — Composio tool input: { arguments, tool_slug? }.

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

Parameters:
- `query` (string, required) — Plain-English ICP / what to watch for.
- `signal_types` (array) — Which buying-signal types to watch for (default: all).

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

Parameters:
- `finding_id` (string, required) — The worker finding to act on.
- `action` (string) — 'find_people' (default) finds decision-makers at the company; 'dismiss' marks handled without spending.
- `roles` (array) — find_people: roles to look for at the company.

### 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' = 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`).

Parameters:
- `action` (string) — Defaults to 'list'.
- `kind` (string) — create: 'reply_auto_send' auto-sends matching classified inbound replies; 'message_auto_send' auto-sends approved segment messages.
- `intent_classes` (array) — reply rules: which intents may auto-send (e.g. interested, meeting_request).
- `min_confidence` (number) — reply rules: classifier floor (default 0.8).
- `segment_id` (string) — message rules: only members of this segment.
- `channel` (string) — message rules: which channel auto-sends.
- `daily_cap` (number) — Max auto-sends per day (default 10).
- `rule_id` (string) — pause/resume/delete: the rule.

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

No parameters.

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

No parameters.

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

Parameters:
- `message_id` (string, required) — The pending draft message id.

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

Parameters:
- `message_id` (string, required) — The pending draft message id.
- `text` (string, required) — The replacement reply text to send.

### gtm_reply_reject

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

Parameters:
- `message_id` (string, required) — The pending draft 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 use `brain_push` for deliberate company-wide knowledge. Pass `fact`. Free; returns { ok, message } or { ok:false, error }.

Parameters:
- `fact` (string, required) — A self-contained statement to add to the company brain.

### 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: `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 }.

Parameters:
- `query` (string, required) — Plain-English description of what to watch for.
- `cadence` (string, required) — How often to run. Default every_6h. Sub-30m cadences (every_5m/every_15m) only tick that fast when the Fly reconciler poll is enabled; otherwise they run on the 30m cron.
- `kind` (string) — Task type; names the worker '<kind> worker'. signal=funding/hiring/launch triggers, job_search=watch roles, research=async deep-research (parallel/task), custom=free-form (default).
- `name` (string) — Optional name override (default '<kind> worker').
- `sources` (array) — Optional URLs to watch for changes. Omit to do a recency web search.
- `signal_types` (array) — For kind:signal only — which buying-signal types to watch (default all).
- `notify_slack_webhook` (string) — Optional Slack incoming-webhook URL to ping with new findings.
- `notify_email` (string) — Optional email address to send new-finding digests to (in addition to / instead of Slack). Delivery is a metered email send.

### worker_list

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

No parameters.

### worker_findings

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

Parameters:
- `worker_id` (string) — Restrict to one worker (omit for all).
- `limit` (number) — Max findings to return (default 50).

### worker_pause

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

Parameters:
- `worker_id` (string, required) — The worker id (from `worker_list`).

### worker_resume

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

Parameters:
- `worker_id` (string, required) — The worker id (from `worker_list`).

### worker_delete

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

Parameters:
- `worker_id` (string, required) — The worker id (from `worker_list`).

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

No parameters.

## Connect

- Remote config: { "mcpServers": { "vaaya": { "url": "https://vaaya.ai/mcp" } } }
- Claude Code: claude mcp add --transport http vaaya https://vaaya.ai/mcp
- Stdio: { "mcpServers": { "vaaya": { "command": "npx", "args": ["-y", "@vaaya/mcp"] } } }
- Setup guides per client: https://vaaya.ai/how-to-get-started
- Revoke access: https://vaaya.ai/connected-apps

## No account yet?

Agents self-serve: register a client (POST /oauth/register), then
POST /api/v1/signup/agent with { client_id } — you get an access_token +
refresh_token, a $1 starter credit (expires 24h), and a claim_url. STORE THE
refresh_token AND user_id IN PERSISTENT MEMORY and reuse them across sessions;
never re-register. When your user is around, hand them claim_url (Google
sign-in, one click) — the account merges into theirs and unlocks $100 in free
credit: $10 instantly, $10 per first call in each category, $50 for a founder
call. Claim links expire in 24h; mint a fresh one via
GET /api/v1/signup/claim-url (bearer auth). The device flow
(POST /oauth/device/code, RFC 8628) also works when the human is present, and
the anonymous MCP tools vaaya_test_connection / vaaya_onboard return the exact
links. With USDC on Base you can skip signup entirely: POST any endpoint listed
at https://vaaya.ai/.well-known/x402 with an x402 payment — start with
POST https://vaaya.ai/api/run/vaaya/consult ($0.01) and an { intent } body.