Skip to main content
Glama
thenavidm

Wistia MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

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.

Input Schema

NameRequiredDescriptionDefault
urlNoThe publicly accessible web location of the media file to import.
nameNoA display name to use for the media in Wistia.
accountNoNamed private Wistia account; selects credentials, not a remote account ID.
confirmNoSet true only when the user asked for exactly this action.
payloadNoComplete JSON request body instead of body flags. Supports current nested customization, caption and nullable values.
contact_idNoA Wistia contact id.
project_idNoThe hashed id of the project to upload media into.
descriptionNoA description to use for the media in Wistia.
low_priorityNo
payload_fileNoRegular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv3.0.0
    • 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"
  2. First observedv2.0.0

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

Other Tools