Skip to main content
Glama
thenavidm

Wistia MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List Media Extended Audio Descriptions

list_media_extended_audio_descriptions
Read-onlyIdempotent

List all extended audio descriptions for a Wistia account, with sorting, filtering by hashed IDs, and page or cursor pagination.

Instructions

Lists all extended audio descriptions belonging to the account. Supports pagination and sorting. Read-only account operation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoThe page number to retrieve. This cannot be combined with `cursor`, pagination.
cursorNoIf `cursor[enabled]` is set to 1 then cursor pagination is enabled and the first set of records are fetched up to the `per_page`. Cursor pagination will also be turned on if `cursor[before]` or `cursor[after]` are set. Records returned will have a `cursor` property set which can be used to fetch more records in the same `sort_by` ordering. The cursor value of the last record can be used to fetch records after the current result set and the cursor of the first record can be used to fetch records before the result set. NOTE: a cursor value is only valid if the `sort_by` value hasn't changed from the last fetch. For example, you cannot fetch using `sort_by` id and then pass that cursor value to a `sort_by` name.
accountNoNamed private Wistia account; selects credentials, not a remote account ID.
sort_byNoField to order by. The default is id.
per_pageNoThe number of medias per page. Use this for both offset pagination and cursor pagination.
all_pagesNoRead bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
max_itemsNoMaximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
hashed_idsNoFilter extended audio descriptions to only those matching these hashed ids.
sort_directionNoDirection to order by. (0 = desc, 1 = asc; default is 1)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, and the sentence "Read-only account operation" merely restates them without adding context. Nothing is disclosed about quota consumption during paginated reads, behavior of all_pages/max_items, or rate limits, so the description adds essentially nothing behavioral beyond the structured fields.

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?

Three short sentences, front-loaded with what the tool lists, and zero filler. The final "Read-only account operation" sentence is largely redundant with the readOnlyHint annotation, a minor waste in an otherwise tight definition.

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 zero-required, nine-parameter list tool with a nested cursor object and no output schema, the description is minimally adequate: schema covers parameters thoroughly, but it omits the mutual exclusivity of page vs cursor, the default sort field and direction, and the quota cost of all_pages that an agent calling this repeatedly would want flagged. Nothing essential is missing, but the guidance layer is thin.

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%, so all nine parameters including the nested cursor object, sort_by/sort_direction enums, hashed_ids filter, and the all_pages/max_items quota semantics are already documented in the schema. The description's "supports pagination and sorting" adds no syntax or meaning beyond that, so the baseline of 3 applies.

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?

"Lists all extended audio descriptions belonging to the account" gives a clear verb plus resource and scope, which distinguishes it from the singular get_/delete_ extended-audio-description siblings. It does not name any sibling or contrast itself with list_captions, but an agent can infer the resource 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 Guidelines2/5

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

The description never states when to choose this tool over get_media_extended_audio_description, delete_media_extended_audio_description, or order_extended_audio_description. Beyond the implied list-vs-retrieve distinction, no conditions, prerequisites, or alternatives are given.

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