Skip to main content
Glama
thenavidm

Wistia MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Create Expiring Access Token

create_expiring_access_token
Destructive

Create expiring Wistia access tokens for iframe embeds and REST API requests, specifying scopes, expiration, and object-level authorizations.

Instructions

šŸš« Alert
This API is still under development and can change at any time.

This endpoint is for creating expiring access tokens which can be used for some iframe embeds and, when granted the all:delegate_to_contact_permissions scope, for REST API requests authorized by the token's authorizations.

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. Requires confirm=true for the requested mutation. May share access, notify people or incur provider charges.

Input Schema

NameRequiredDescriptionDefault
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.
payload_fileNoRegular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
secret_result_fileYesNew private local result file, saved with exclusive creation and mode 0600. Parent must be owner-only on POSIX. No credentials are returned to the AI client.
expiring_access_tokenNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv3.0.0
    • addedInput schema / $defs
      Added value: +{
+  "expiring_access_token": {
+    "properties": {
+      "authorizations": {
+        "description": "a list of authorizations the token will have",
+        "items": {
+          "properties": {
+            "id": {
+              "description": "The id of the object the permissions are being performed on: the hashed id of a `media` or `folder`, or the numeric `id` of the `account` (as returned by `GET /modern/account`), which must be the token's own account.",
+              "type": "string"
+            },
+            "permissions": {
+              "description": "The permissions granted on the object. `media` supports `show`, `update`, `destroy` and `edit-transcripts`; `folder` supports `show`, `update` and `destroy`; `account` supports `create-folders`. Any permission implicitly allows viewing the object; all other permissions must be declared explicitly. A rule naming a `folder` also covers its subfolders: any permission lists and shows them, and `update` creates, renames and deletes them.",
+              "items": {
+                "type": "string"
+              },
+              "type": "array"
+            },
+            "type": {
+              "description": "The type of object the permission is being performed on. Supports `media`, `folder` and `account`.",
+              "enum": [
+                "media",
+                "folder",
+                "account"
+              ],
+              "type": "string"
+            }
+          },
+          "required": [
+            "type",
+            "id",
+            "permissions"
+          ],
+          "type": "object",
+          "unevaluatedProperties": false
+        },
+        "type": "array"
+      },
+      "expires_at": {
+        "description": "an ISO8601 string of when the token will expire, defaults to two days from creation",
+        "format": "date-time",
+        "type": "string"
+      },
+      "scopes": {
+        "default": [
+          "graphql:all"
+        ],
+        "description": "The scopes the token will be granted. `graphql:all` allows GraphQL requests (e.g. the embedded transcript editor) and `all:delegate_to_contact_permissions` allows REST API requests authorized by the token's authorizations. Defaults to `[\"graphql:all\"]` when omitted.",
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      }
+    },
+    "type": "object",
+    "unevaluatedProperties": false
+  }
+}
    • 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 / expiring_access_token / $ref
      Added value: +"#/$defs/expiring_access_token"
    • removedInput schema / properties / expiring_access_token / properties
      Removed value: -{
-  "authorizations": {
-    "description": "a list of authorizations the token will have",
-    "items": {
-      "properties": {
-        "id": {
-          "description": "The id of the object the permissions are being performed on: the hashed id of a `media` or `folder`, or the numeric `id` of the `account` (as returned by `GET /modern/account`), which must be the token's own account.",
-          "type": "string"
-        },
-        "permissions": {
-          "description": "The permissions granted on the object. `media` supports `show`, `update`, `destroy` and `edit-transcripts`; `folder` supports `show`, `update` and `destroy`; `account` supports `create-folders`. Any permission implicitly allows viewing the object; all other permissions must be declared explicitly. A rule naming a `folder` also covers its subfolders: any permission lists and shows them, and `update` creates, renames and deletes them.",
-          "items": {
-            "type": "string"
-          },
-          "type": "array"
-        },
-        "type": {
-          "description": "The type of object the permission is being performed on. Supports `media`, `folder` and `account`.",
-          "enum": [
-            "media",
-            "folder",
-            "account"
-          ],
-          "type": "string"
-        }
-      },
-      "required": [
-        "type",
-        "id",
-        "permissions"
-      ],
-      "type": "object",
-      "unevaluatedProperties": false
-    },
-    "type": "array"
-  },
-  "expires_at": {
-    "description": "an ISO8601 string of when the token will expire, defaults to two days from creation",
-    "format": "date-time",
-    "type": "string"
-  },
-  "scopes": {
-    "default": [
-      "graphql:all"
-    ],
-    "description": "The scopes the token will be granted. `graphql:all` allows GraphQL requests (e.g. the embedded transcript editor) and `all:delegate_to_contact_permissions` allows REST API requests authorized by the token's authorizations. Defaults to `[\"graphql:all\"]` when omitted.",
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  }
-}
    • removedInput schema / properties / expiring_access_token / type
      Removed value: -"object"
    • removedInput schema / properties / expiring_access_token / unevaluatedProperties
      Removed value: -false
    • addedInput schema / properties / payload / properties / expiring_access_token / $ref
      Added value: +"#/$defs/expiring_access_token"
    • removedInput schema / properties / payload / properties / expiring_access_token / properties
      Removed value: -{
-  "authorizations": {
-    "description": "a list of authorizations the token will have",
-    "items": {
-      "properties": {
-        "id": {
-          "description": "The id of the object the permissions are being performed on: the hashed id of a `media` or `folder`, or the numeric `id` of the `account` (as returned by `GET /modern/account`), which must be the token's own account.",
-          "type": "string"
-        },
-        "permissions": {
-          "description": "The permissions granted on the object. `media` supports `show`, `update`, `destroy` and `edit-transcripts`; `folder` supports `show`, `update` and `destroy`; `account` supports `create-folders`. Any permission implicitly allows viewing the object; all other permissions must be declared explicitly. A rule naming a `folder` also covers its subfolders: any permission lists and shows them, and `update` creates, renames and deletes them.",
-          "items": {
-            "type": "string"
-          },
-          "type": "array"
-        },
-        "type": {
-          "description": "The type of object the permission is being performed on. Supports `media`, `folder` and `account`.",
-          "enum": [
-            "media",
-            "folder",
-            "account"
-          ],
-          "type": "string"
-        }
-      },
-      "required": [
-        "type",
-        "id",
-        "permissions"
-      ],
-      "type": "object",
-      "unevaluatedProperties": false
-    },
-    "type": "array"
-  },
-  "expires_at": {
-    "description": "an ISO8601 string of when the token will expire, defaults to two days from creation",
-    "format": "date-time",
-    "type": "string"
-  },
-  "scopes": {
-    "default": [
-      "graphql:all"
-    ],
-    "description": "The scopes the token will be granted. `graphql:all` allows GraphQL requests (e.g. the embedded transcript editor) and `all:delegate_to_contact_permissions` allows REST API requests authorized by the token's authorizations. Defaults to `[\"graphql:all\"]` when omitted.",
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  }
-}
    • removedInput schema / properties / payload / properties / expiring_access_token / type
      Removed value: -"object"
    • removedInput schema / properties / payload / properties / expiring_access_token / unevaluatedProperties
      Removed value: -false
  2. First observedv2.0.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already flag destructive=true, idempotent=false, openWorld=true, so the safety profile is covered. The description adds meaningful context beyond that: a development-stability warning, the confirm=true requirement for the mutation, side-effect risk ('may share access, notify people or incur provider charges'), and scope-granted delegation semantics.

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 most critical caveat (under development) is front-loaded, and the permission/confirm/charge notes are grouped at the end. It is verbose in places but every section ā€“ stability, purpose, permissions, side effects ā€“ carries information an agent needs.

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 6-parameter mutation with nested authorizations and no output schema, the description covers purpose, permissions, delegation rules, the confirm gate, and side effects. The secret_result_file mechanics are left to the schema, which documents them adequately, so the description is complete enough without being exhaustive.

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 coverage is 83%, so the schema already documents nearly every parameter in depth (scopes, expires_at, authorizations, payload, secret_result_file). The description only restates the delegate scope briefly and adds no syntax or format beyond the schema, which is the expected baseline-3 behavior.

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?

States a specific verb and resource ('creating expiring access tokens') and explains the two use cases (iframe embeds, REST API requests authorized by the token's authorizations). No sibling tool in the list competes with token creation, so sibling differentiation is largely moot; clarity is high but not exceptional.

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?

Clearly explains when this token type is applicable (iframe embeds; REST requests when the delegate scope is granted) and lists the required caller permissions. It stops short of naming exclusions or an alternative token mechanism, so it is strong context without explicit when-not guidance.

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