Wistia MCP Server

Order Extended Audio Description

order_extended_audio_description

Destructive

Request extended audio descriptions for a Wistia media item. Paid accounts only; confirmation required and charges apply.

Instructions

Orders an extended audio description for a media. The request will charge the credit card on the account when the order is ready. Only accounts on paid plans with the order_audio_descriptions feature can use this endpoint. 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": "order_extended_audio_description"
  }
}

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.
`enabled`	No	Whether the extended audio description should be automatically enabled once the order is complete.
`payload`	No	Complete JSON request body instead of body flags. Supports current nested customization, caption and nullable values.
`media_id`	No	The hashed id of the media to order the extended audio description for.
`ai_enabled`	No	Whether to use AI-generated audio descriptions (cheaper) or human-generated (higher quality). AI is only available for English orders.
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`ietf_language_tag`	No
`order_instructions`	No	Optional instructions for the audio description provider.

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedv3.0.0Oct 7, 2026

addedInput schema / $defs

Added value: +{
+  "ietf_language_tag": {
+    "default": "eng",
+    "description": "IETF language tag for the audio description. Defaults to `eng` (English).\nNon-English orders must set `ai_enabled: false` — AI-generated audio\ndescriptions are only available in English.\n\nSpanish (`es-419`) orders are only accepted when the source media is\ntagged as a Spanish-language variant or has no detected language\n(e.g. silent videos). Spanish orders against a media in another\nlanguage return `400`.\n",
+    "enum": [
+      "eng",
+      "es-419"
+    ],
+    "type": "string"
+  }
+}

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 / ietf_language_tag / $ref
```
Added value: +"#/$defs/ietf_language_tag"
```
removedInput schema / properties / ietf_language_tag / default
```
Removed value: -"eng"
```

removedInput schema / properties / ietf_language_tag / description

Removed value: -"IETF language tag for the audio description. Defaults to `eng` (English).\nNon-English orders must set `ai_enabled: false` — AI-generated audio\ndescriptions are only available in English.\n\nSpanish (`es-419`) orders are only accepted when the source media is\ntagged as a Spanish-language variant or has no detected language\n(e.g. silent videos). Spanish orders against a media in another\nlanguage return `400`.\n"

removedInput schema / properties / ietf_language_tag / enum
```
Removed value: -[
-  "eng",
-  "es-419"
-]
```
removedInput schema / properties / ietf_language_tag / type
```
Removed value: -"string"
```
addedInput schema / properties / payload / properties / ietf_language_tag / $ref
```
Added value: +"#/$defs/ietf_language_tag"
```
removedInput schema / properties / payload / properties / ietf_language_tag / default
```
Removed value: -"eng"
```

removedInput schema / properties / payload / properties / ietf_language_tag / description

Removed value: -"IETF language tag for the audio description. Defaults to `eng` (English).\nNon-English orders must set `ai_enabled: false` — AI-generated audio\ndescriptions are only available in English.\n\nSpanish (`es-419`) orders are only accepted when the source media is\ntagged as a Spanish-language variant or has no detected language\n(e.g. silent videos). Spanish orders against a media in another\nlanguage return `400`.\n"

removedInput schema / properties / payload / properties / ietf_language_tag / enum
```
Removed value: -[
-  "eng",
-  "es-419"
-]
```
removedInput schema / properties / payload / properties / ietf_language_tag / type
```
Removed value: -"string"
```

First observedv2.0.0Oct 2, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already flag destructive, non-idempotent, open-world behavior, so the bar is lower; the description adds real value by disclosing that the credit card is charged when the order is ready (delayed cost), the paid-plan/feature gate, and the confirm=true mutation guard. It does not explain cancellation, refunds, or how the resulting order is tracked.

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?

Four short sentences, front-loaded with the operation and its consequences, with no filler. The closing line ('May share access, notify people or incur provider charges') is somewhat boilerplate and could be tightened.

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?

For a 9-parameter tool with nested objects and no output schema, the description covers preconditions, cost, and confirmation well. It omits what the call returns (e.g., an order identifier) and how to follow up via get_order_status, which is a mild gap but not blocking.

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 89%, so the schema already documents media_id, ai_enabled, ietf_language_tag, order_instructions, payload, and payload_file. The description only reinforces confirm=true and adds no syntax, mutual-exclusion, or defaulting detail beyond it, so baseline 3 applies.

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 ('Orders') and resource ('extended audio description for a media'), which cleanly separates it from sibling reads/deletes such as get_media_extended_audio_description and delete_media_extended_audio_description. An agent can identify the operation without opening the schema.

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 gives clear preconditions (paid plan with the `order_audio_descriptions` feature, confirm=true) but no guidance on when to prefer this over alternatives or what to do if the plan/feature check fails. Usage context is implied rather than routed.

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

Deploy Server