Wistia MCP Server

Copy Folder

copy_folder

Destructive

Copies a folder with all media and subfolders as an async background job, optionally assigning a new owner. Does not copy sharing permissions.

Instructions

This copies a folder (previously called project) and all its media and subfolders asynchronously in a background job.

This method does not copy the folder’s sharing information (i.e. users that could see the old folder will not automatically be able to see the new one).

For the request you can specify the owner of a new folder by passing an optional parameter. The person you specify must be a Manager in the account.

The body of the response will contain an object representing the background job that was created.

Requires api token with one of the following permissions

Read, update & delete anything

Tokens with the "Act with a team member's permissions" permission (all:delegate_to_contact_permissions scope) can also be used. Requests made with such a token are authorized using the permissions of the contact assigned to the token. Requires confirm=true for the requested mutation. May share access, notify people or incur provider charges.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Folder Hashed ID
`account`	No	Named private Wistia account; selects credentials, not a remote account ID.
`confirm`	No	Must be true for the specific user-requested write.
`payload`	No	Complete JSON request body instead of body flags. Supports current nested customization, caption and nullable values.
`adminEmail`	No	The email address of the account Manager that will be the owner of the new folder. Defaults to the Account Owner if invalid or omitted.
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.0Oct 2, 2026

TDQS

A4.2/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial context beyond the annotations: it runs asynchronously as a background job, sharing/permission info is deliberately not carried over to the new folder, the response returns a job object, and the required token scopes are spelled out. These are exactly the behavioral facts an agent needs for a destructive, non-idempotent write.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action and the background-job nature before the caveats, and every paragraph carries relevant information. The trailing permissions block is somewhat boilerplate but still actionable for an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent mutation with no output schema, the description covers async behavior, what is not copied, response shape, confirmation requirement, and authorization. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds the useful constraint that the adminEmail target must be an account Manager, but the default behavior for invalid/omitted values is already stated in the schema, so added value is marginal.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('copies a folder ... and all its media and subfolders') and clarifies scope with the rename note ('previously called project'). This clearly distinguishes it from sibling media-copy tools like copy_media and bulk_copy_media.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains the owner/Manager constraint and the confirm=true requirement, which implies the intended call context, but never states when to use copy_folder versus alternatives such as copy_media or move_media, and gives no exclusions. Usage is implied rather than explicitly routed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server