Place and manage voice AI phone calls, and read the assistant, phone number, squad, tool and file catalogs behind them, on Vapi.
Vapi ships in the w6w first-party pack. It declares 18 actions, 2 health checks, and the host runs its code in a sandbox that never sees the credential.
io.w6w.vapiVapi is voice-AI infrastructure: assistants (a transcriber + LLM + voice pipeline) are configured once in the Vapi dashboard or API, then driven over phone or web calls. The unit this app moves around is the call — created against an existing Assistant, Squad or Workflow, plus the catalogs (assistants, phone numbers, squads, tools, files) a workflow needs to pick from before placing one.
This app deliberately does not create or update Assistants, Squads or Tools: each is a deeply nested, polymorphic configuration object (a transcriber, a model, a voice provider, a compliance plan, and — for Tools — one of twelve unrelated shapes from a plain webhook to a Bash sandbox), the kind of object meant to be authored once in the dashboard and then referenced by id, not re-typed into a workflow form. What the app does cover in full is the operational surface: start a call against any of those, list and inspect calls, rename or delete a call’s stored data, and read every catalog by id.
Health checks track Vapi’s own status page (a genuine Better Stack page at status.vapi.ai, not the Statuspage-shaped decoy at vapi.statuspage.io) alongside the derived credential-liveness check; there is no documented usage/quota endpoint or rate-limit header on this API, so quota is declared unavailable rather than guessed.
Three routes to the same 18 actions. The Workflow tab is generated from Vapi's own manifest and carries its real ids, so it is copy-pasteable; the Code and CLI examples are the same call for any action on any app, so every app-specific value in them is a blank you fill in.
call-create Start a call (web or phone) against an existing Assistant, Squad or Workflow.
call-delete Erase a call's stored recordings, transcript and artifacts. Does NOT end a live call.
call-update Set a call's own-reference name. This is the only field Vapi allows updating.
file-list List uploaded files for a given purpose. Purpose is required by the vendor API.
phone-number-list List phone numbers, page by page (this endpoint does not paginate by date range).
squad-list List Squads — named groups of Assistants that hand off calls between themselves.
tool-list List the Tools (functions, API requests, transfers, …) configured in this project.
A workflow step names the app and the action, and the editor fills in the
connection when you pick one. This is the Step shape from the
workflow spec, carrying Vapi's real ids.
{
"manifestVersion": "2",
"name": "vapi-example",
"steps": [
{
"id": "assistant-get",
"uses": {
"app": "io.w6w.vapi",
"action": "assistant-get",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"id": "<id>"
}
}
]
}assistant-get assistant-list call-create call-get call-list +13 more actions available
Every app-specific value here is a blank you have to fill in. An
app action is reached through the connection that authenticates it, so the
address is a connection id, not the app id — and connections belong to your account,
so a public page cannot know yours. Create one for Vapi, then fill in
the three blanks: conn_YOUR_CONNECTION_ID, the action key, and the
parameters that action declares. The call itself is real — the shape is transcribed
from the studio's own snippet builder, which prints the same kind of blanks — but
nothing in it is specific to Vapi. The Workflow tab is where this app's
real ids are.
npm install @w6w/sdkyarn add @w6w/sdkpnpm add @w6w/sdkdeno add npm:@w6w/sdkimport { W6wClient, isActionRun } from "@w6w/sdk";
// Reads W6W_BASE_URL and W6W_TOKEN from the environment when omitted.
const client = new W6wClient();
const envelope = await client.run({
urn: "conn_YOUR_CONNECTION_ID",
action: "assistant-get",
payload: {
id: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value); npm install -g @w6w/cli w6w run conn_YOUR_CONNECTION_ID --action assistant-get --payload '{"id":"<value>"}' Give an AI agent Vapi — without giving it Vapi's credentials. One MCP endpoint exposes every app, function and workflow the caller is entitled to, as tools it can discover and run. Access is granted per team while we onboard.
One tool call{
"name": "w6w_invoke",
"arguments": {
"ref": "app:io.w6w.vapi#assistant-get",
"input": {
"id": "<id>"
}
}
}
Every tool names its target with a single ref. The
app: form above doesn't name a connection at all — the
host resolves which of the caller's Vapi connections to sign
with, and refuses rather than guesses when the answer is ambiguous.
The token is attached host-side, at the moment of the call. It is never a tool argument, never in the model's context, and never in a transcript — so a prompt injection has nothing to exfiltrate.
Tools are derived per end user from what that person has actually connected and is entitled to — not one shared bot identity carrying the union of everyone's access.
Multi-step work runs on the workflow engine and returns a run handle the agent can poll — retries, branching and state survive the conversation that started them.
Vapi's declared health checks are on the surface too, so an agent can tell "the vendor is down" from "your credential expired" before it burns a retry on either.
The MCP surface is part of the hosted platform. Vapi itself is MIT, and the runtime that executes it is source-available (FSL).
Vapi declares its own checks, so its health is a property of the app rather than something the host guesses at.
Resource status from status.vapi.ai (Better Stack): Vapi's own API/dashboard/auth/SIP/carrier legs, plus the upstream model and voice providers it depends on.