Manage Vimeo videos, folders, showcases, comments and likes — list, edit and delete videos, pull-upload from a URL, organise folders and showcases, and read rate-limit headroom.
Vimeo ships in the w6w first-party pack. It declares 36 actions, 2 health checks, and the host runs its code in a sandbox that never sees the credential.
io.w6w.vimeoVimeo puts a video library within reach of a workflow — pull in a video from a public URL, keep folders and showcases organized, and moderate the comments and likes that come in, all through Vimeo’s own REST API.
Videos can be listed, searched, updated and deleted, and a video can be pulled in directly from a public URL rather than uploaded through this app. Folders and showcases (called projects and albums on the wire) organise a video library: create, rename and delete either, add or remove videos from them one at a time, or replace a showcase’s whole contents in one call when that’s genuinely what’s meant. Comments and replies thread onto a video for moderation or engagement workflows, and likes can be listed, added or removed on behalf of the connected account.
It fits video-library and content-operations workflows — publishing a video pulled from another system, keeping a showcase in sync with a content calendar, or moderating comments as they come in — for a Vimeo account authenticated with a personal access token or a bearer token from any of Vimeo’s own OAuth grants.
Three routes to the same 36 actions. The Workflow tab is generated from Vimeo'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.
folder-delete Delete a folder. By default the videos inside it stay in the account; turn on Delete videos too to remove them as well.
folder-item-list List everything directly inside a folder — videos, subfolders and live events.
folder-video-list List the videos inside a folder, optionally including its subfolders.
folder-video-remove Take one or more videos out of a folder. By default the videos stay in the account.
showcase-update Edit a showcase's name, description, privacy, appearance or custom URL.
showcase-video-add Add one or more videos to a showcase, leaving the videos already in it alone. Adds them one request at a time — Vimeo's bulk endpoint replaces the whole showcase instead.
showcase-video-list List the videos in a showcase, in the showcase's own order if you ask for it.
showcase-video-remove Take one or more videos out of a showcase. The videos themselves stay in the account.
showcase-video-replace Set the showcase's contents to exactly this list of videos. Anything already in it and not listed is removed.
user-update Edit the connected account's profile and the privacy defaults applied to future uploads. Does not change existing videos.
video-upload-pull Create a Vimeo video by having Vimeo pull a video file from a public URL. Returns 201 even for a link that is not a video — check `status` and `upload.status` afterwards.
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 Vimeo's real ids.
{
"manifestVersion": "2",
"name": "vimeo-example",
"steps": [
{
"id": "comment-create",
"uses": {
"app": "io.w6w.vimeo",
"action": "comment-create",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"videoId": "<videoId>",
"text": "<text>"
}
}
]
}comment-create comment-get comment-list comment-reply-create comment-reply-list +31 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 Vimeo, 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 Vimeo. 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: "video-upload-pull",
payload: {
link: "<value>",
// name: "<value>",
// description: "<value>",
// size: "<value>",
// privacyView: "<value>",
// password: "<value>",
// privacyEmbed: "<value>",
// privacyDownload: "<value>",
// privacyComments: "<value>",
// fields: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value); npm install -g @w6w/cli w6w run conn_YOUR_CONNECTION_ID --action video-upload-pull --payload '{"link":"<value>"}' Give an AI agent Vimeo — without giving it Vimeo'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.vimeo#comment-create",
"input": {
"videoId": "<videoId>",
"text": "<text>"
}
}
}
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 Vimeo 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.
Vimeo'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. Vimeo itself is MIT, and the runtime that executes it is source-available (FSL).
Vimeo declares its own checks, so its health is a property of the app rather than something the host guesses at.
Component status from www.vimeostatus.com, Vimeo's Atlassian Statuspage. Reports all 16 published components, including API, Upload and Conversion — the three this app depends on.
Reads X-RateLimit-Limit / -Remaining / -Reset from a filtered GET /me. The figures Vimeo reports already assume field filtering; a caller not using `fields` must halve them.