Work a Front shared inbox — find conversations, reply, comment, tag, assign, snooze, and keep the contacts behind them current.
Front ships in the w6w first-party pack. It declares 30 actions, 2 health checks, and the host runs its code in a sandbox that never sees the credential.
io.w6w.frontFront centers a team’s shared inbox — every channel a customer might reach out through, routed into one place — and this app works that inbox from a workflow: find and search conversations, reply to the customer or add an internal comment for the team, tag, assign and snooze conversations, and keep the contact record behind each one current.
Replying and commenting are deliberately separate actions, because Front keeps the customer conversation and the team’s internal discussion in the same thread, and getting them confused sends internal notes to a customer. Tags and followers can be added or removed without touching the rest of a conversation’s state, and updates only replace what’s explicitly changed rather than defaulting to a full overwrite.
Beyond conversations, this app lists inboxes, channels, teammates and tags, and reads or writes contact records and their notes — enough to run a support or shared-inbox workflow end to end without leaving Front’s own conversation model behind.
Three routes to the same 30 actions. The Workflow tab is generated from Front'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.
channel-list The channels messages can be sent from — address, type and id. Send Message needs one of these ids.
contact-conversation-list Every conversation with one person, across all their handles and channels. Accepts an `alt:email:…` alias, so an address is enough.
contact-create Create a contact. At least one handle is required — without one, Front cannot match the next message to this person and will make a second contact.
contact-get One contact by id — or by handle, using an `alt:email:…` / `alt:phone:…` alias, which is the only way to look a person up by address.
contact-list Contacts, optionally only those changed inside a time window — the incremental-sync filter, since Front offers no name or email filter here.
contact-note-add Attach a note to the person, visible beside every conversation they open — unlike a comment, which stays on one thread.
contact-update Change a contact's name, description, links, lists or custom fields. Handles are not editable here — they are identities, added and removed individually.
conversation-assign Give a conversation to a teammate, or unassign it. Accepts a teammate id or an `alt:email:…` alias.
conversation-comment-add Post an internal note on a conversation. The team sees it; the customer never does — unlike Reply, which sends.
conversation-comment-list The internal comments on a conversation — what the team said, not the customer.
conversation-create An internal thread — a discussion or a task. Comment-only: no customer is on it and no message can be sent into it. Use Send Message to start a customer conversation.
conversation-event-list What happened to a conversation and when — assignments, tags, archives, reopens. The history the conversation object does not keep.
conversation-follower-add Subscribe teammates to a conversation's activity without giving it to them — the non-destructive half of an escalation.
conversation-get One conversation's status, assignee, tags, recipient and custom fields. Messages are a separate call.
conversation-list Conversations across the company, newest activity first. Filter by status — open work is `assigned` plus `unassigned`, which are two statuses rather than one.
conversation-message-list The customer-visible messages on a conversation. Internal comments are a separate collection — List Comments reads those.
conversation-reply Send a message into an existing conversation. Front archives on reply by default — this action does not, and always says which it means.
conversation-search Front's search syntax — `is:open`, `tag:`, `from:`, `inbox:`, free text. Rate limited at 40% of the company's allowance, so search once and page rather than searching per row.
conversation-snooze Take a conversation out of the queue until a stated time — or, with no time, put it back now. The reminder belongs to a teammate, whom Front requires you to name.
conversation-tag-add Add one or more existing tags, leaving the conversation's other tags alone. Ids, not names — List Tags maps between them.
conversation-tag-remove Take one or more tags off a conversation, leaving the others in place.
conversation-update Change a conversation's status, inbox, assignee or custom fields. Tags are deliberately not here — Front's tag field replaces the whole set, so use Add/Remove Tag instead.
inbox-conversation-list One inbox's queue, filtered by status at Front rather than after the fact — the cheap way to ask 'what is unassigned in Support'.
inbox-list The shared inboxes this token can see, with the ids other actions ask for. An inbox holds channels; it is not one itself.
message-send Send a new outbound message through a channel, starting a conversation. Recipients are handles (address, phone number), not contact ids.
status-list Named ticket statuses and their ids, for companies with ticketing enabled. Empty when it is not — which is an answer, not a failure.
tag-list The company's tags, mapping names to the ids Add/Remove Tags need. Company tags only — not one teammate's private labels.
teammate-list The company's teammates and their ids — including who is available, which is what stops a round-robin assigning to somebody who is away.
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 Front's real ids.
{
"manifestVersion": "2",
"name": "front-example",
"steps": [
{
"id": "contact-conversation-list",
"uses": {
"app": "io.w6w.front",
"action": "contact-conversation-list",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"contactId": "<contactId>"
}
}
]
}contact-conversation-list channel-list contact-create contact-get contact-list +25 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 Front, 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 Front. 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: "contact-conversation-list",
payload: {
contactId: "<value>",
// statuses: "<value>",
// returnAll: "<value>",
// limit: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value); npm install -g @w6w/cli w6w run conn_YOUR_CONNECTION_ID --action contact-conversation-list --payload '{"contactId":"<value>"}' Give an AI agent Front — without giving it Front'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.front#contact-conversation-list",
"input": {
"contactId": "<contactId>"
}
}
}
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 Front 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.
Front'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. Front itself is MIT, and the runtime that executes it is source-available (FSL).
Front declares its own checks, so its health is a property of the app rather than something the host guesses at.
Front's Statuspage, split in two: the API components this app calls, and the message channels a reply goes out through — a dead channel is a partial failure, not an outage.
Front's per-minute allowance and the 10-minute burst bucket behind it, read from the rate-limit headers on a scope-free GET /me.