Wistia MCP Server

Upload or Import Media

upload_media

Destructive

Upload local media files or import media from a web URL into Wistia using multipart or URL-encoded requests.

Instructions

Endpoint to upload media files from a local system or import from a web URL.

Use multipart/form-data with a file parameter to upload from local system
Use application/x-www-form-urlencoded with a url parameter to import from web URL Requires confirm=true for the requested mutation. May share access, notify people or incur provider charges.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "upload_media"
  }
}

Input Schema

Name	Required	Description
`url`	No	The publicly accessible web location of the media file to import.
`name`	No	A display name to use for the media in Wistia.
`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.
`contact_id`	No	A Wistia contact id.
`project_id`	No	The hashed id of the project to upload media into.
`description`	No	A description to use for the media in Wistia.
`low_priority`	No
`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.

Changed8 schema fields changedv3.0.0Oct 7, 2026

addedInput schema / $defs

Added value: +{
+  "low_priority": {
+    "description": "Inform the encoding service that this upload can be considered lower priority than others. This is especially useful for platform customers doing bulk uploads or migrations. Setting this to \"false\" has no effect.",
+    "type": "boolean"
+  }
+}

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."

addedInput schema / properties / low_priority / $ref
```
Added value: +"#/$defs/low_priority"
```

removedInput schema / properties / low_priority / description

Removed value: -"Inform the encoding service that this upload can be considered lower priority than others. This is especially useful for platform customers doing bulk uploads or migrations. Setting this to \"false\" has no effect."

removedInput schema / properties / low_priority / type
```
Removed value: -"boolean"
```
addedInput schema / properties / payload / properties / low_priority / $ref
```
Added value: +"#/$defs/low_priority"
```

removedInput schema / properties / payload / properties / low_priority / description

Removed value: -"Inform the encoding service that this upload can be considered lower priority than others. This is especially useful for platform customers doing bulk uploads or migrations. Setting this to \"false\" has no effect."

removedInput schema / properties / payload / properties / low_priority / type
```
Removed value: -"boolean"
```

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 destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is known. The description adds real value on top by disclosing the confirm=true gate and non-obvious side effects ('may share access, notify people or incur provider charges'), which an agent could not infer from the annotations alone.

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?

The definition is short, bulleted and front-loads the two operating modes before the confirm/side-effect caveat. 'Endpoint to...' is mild throat-clearing and the final sentence packs three distinct warnings together, but nothing is padded or redundant.

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

Completeness3/5

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

For a 10-parameter, destructive, non-idempotent mutation with nested objects and no output schema, the description covers the essential confirm gate and side effects but omits key operational detail that only lives in the schema, such as the mutual exclusivity of payload, payload_file and body flags. It also leaves the overlap with upload_media_file/import_media_from_url unresolved, so it is adequate but incomplete.

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 90%, so the schema already documents the ten parameters (url, payload, payload_file, name, project_id, etc.) and the baseline is 3. The description's parameter content is actually slightly off-schema: it tells the agent to use 'a file parameter' with multipart/form-data, but no such parameter exists in the input schema, so it adds no reliable meaning beyond what the schema provides.

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

Purpose4/5

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

The description states a specific verb and resource ('upload media files from a local system or import from a web URL') and clearly splits the tool into two modes. It does not, however, differentiate itself from the very closely related siblings 'upload_media_file' and 'import_media_from_url', which each appear to cover one of these modes, so an agent cannot tell why it should pick this tool over them.

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

Usage Guidelines4/5

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

It gives concrete mode-selection guidance: multipart/form-data with a file for local uploads, x-www-form-urlencoded with a url for web imports, plus a hard precondition (confirm=true) for the mutation. There is no 'when not to use' guidance and no routing against the overlapping sibling tools, so it stops short of a 5.

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

Deploy Server