Wistia MCP Server

Bulk Copy Media

bulk_copy_media

Destructive

Copies multiple Wistia media items to a destination folder asynchronously without altering the originals.

Instructions

This method accepts a list of medias to copy to a destination folder. It processes requests asynchronously and will return a background_job_status object rather than the typical Media response object.

Each media will be duplicated and the copy will be placed in the specified destination folder. The original media files will not be affected.

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.

An expiring access token created with the all:delegate_to_contact_permissions scope and an authorization granting the update permission on the destination folder can also be used; only the media the token's authorizations name are copied. Requires confirm=true for the requested mutation. May share access, notify people or incur provider charges.

Input Schema

Name	Required	Description
`account`	No	Named private Wistia account; selects credentials, not a remote account ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports current nested customization, caption and nullable values.
`folder_id`	No	The hashed ID of the destination folder where the copies will be placed.
`hashed_ids`	No	An array of the media hashed IDs to be copied.
`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.

Changed1 schema field changedv3.0.0Oct 7, 2026

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

First observedv2.0.0Oct 2, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the safety profile is covered. The description adds meaningful behavior: asynchronous processing, a background_job_status return instead of the typical Media object, and that originals are untouched. The generic 'share access/notify/incur charges' boilerplate and the tension with destructiveHint=true for a copy keep it from a 5.

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

Conciseness3/5

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

Purpose, async behavior and return type are well front-loaded in the first paragraph. The multi-paragraph token/permission section with code blocks is verbose boilerplate that inflates the definition without improving invocation decisions.

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

Completeness4/5

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

No output schema exists, and the description helpfully specifies the return is a background_job_status object rather than a Media object, covering the main gap. Permission and confirmation requirements are stated; only edge cases like partial failure, batch limits, and idempotency remain unaddressed.

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 description coverage is 100% and all six parameters are documented, so the baseline is 3. The description restates intent (list of medias to a destination folder, confirm=true) but adds no format, ordering, payload-vs-body-flag interaction, or limit details beyond the schema.

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 (copy), resource (medias), and scope (a list, i.e. bulk) in the first sentence, which implicitly distinguishes it from the single-item copy_media sibling. An agent can tell what it does immediately.

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?

The description gives prerequisites (permissions required, confirm=true required), which is useful usage context. However, it never states when to choose this over copy_media or move_media, nor any when-not condition, so alternative selection is left to inference.

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

Deploy Server