Skip to main content
Glama
thenavidm

Wistia MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Update Lead Capture Customizations

update_lead_capture_customizations
Destructive

Configure a single lead-capture provider for a video, mapping it to the correct plugin. Only the selected provider changes; other settings remain untouched.

Instructions

Configures a single lead-capture provider for the video, mapping it to the appropriate underlying plugin. Only the selected provider is changed.

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.
enabledNoWhether the selected provider is turned on. Defaults to true.
payloadNoComplete JSON request body instead of body flags. Supports current nested customization, caption and nullable values.
media_idYesThe hashed ID of the video to be customized.
providerNoWhich lead-capture mechanism to configure.
settingsNo
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. Changed12 schema fields changedv3.0.0
    • addedInput schema / $defs
      Added value: +{
+  "settings": {
+    "description": "Provider-specific settings. Only the fields relevant to the chosen provider are used.",
+    "properties": {
+      "allowSkip": {
+        "description": "Whether the viewer may skip the form.",
+        "type": "boolean"
+      },
+      "backgroundColor": {
+        "description": "Background color of the form as a hex string.",
+        "type": "string"
+      },
+      "displayMode": {
+        "description": "(Wistia Form) How the form is displayed.",
+        "type": "string"
+      },
+      "formId": {
+        "description": "(HubSpot/Marketo/Pardot) The external form identifier.",
+        "type": "string"
+      },
+      "hashedId": {
+        "description": "(Wistia Form) The hashed ID of the Wistia form to embed.",
+        "type": "string"
+      },
+      "portalId": {
+        "description": "(HubSpot) The HubSpot portal/account identifier.",
+        "type": "string"
+      },
+      "showLogo": {
+        "description": "(Wistia Form) Whether to show the Wistia logo on the form.",
+        "type": "boolean"
+      },
+      "time": {
+        "description": "When the form appears: \"start\"/\"before\", a number of seconds, or \"end\".",
+        "type": "string"
+      }
+    },
+    "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 / payload / properties / settings / $ref
      Added value: +"#/$defs/settings"
    • removedInput schema / properties / payload / properties / settings / description
      Removed value: -"Provider-specific settings. Only the fields relevant to the chosen provider are used."
    • removedInput schema / properties / payload / properties / settings / properties
      Removed value: -{
-  "allowSkip": {
-    "description": "Whether the viewer may skip the form.",
-    "type": "boolean"
-  },
-  "backgroundColor": {
-    "description": "Background color of the form as a hex string.",
-    "type": "string"
-  },
-  "displayMode": {
-    "description": "(Wistia Form) How the form is displayed.",
-    "type": "string"
-  },
-  "formId": {
-    "description": "(HubSpot/Marketo/Pardot) The external form identifier.",
-    "type": "string"
-  },
-  "hashedId": {
-    "description": "(Wistia Form) The hashed ID of the Wistia form to embed.",
-    "type": "string"
-  },
-  "portalId": {
-    "description": "(HubSpot) The HubSpot portal/account identifier.",
-    "type": "string"
-  },
-  "showLogo": {
-    "description": "(Wistia Form) Whether to show the Wistia logo on the form.",
-    "type": "boolean"
-  },
-  "time": {
-    "description": "When the form appears: \"start\"/\"before\", a number of seconds, or \"end\".",
-    "type": "string"
-  }
-}
    • removedInput schema / properties / payload / properties / settings / type
      Removed value: -"object"
    • removedInput schema / properties / payload / properties / settings / unevaluatedProperties
      Removed value: -false
    • addedInput schema / properties / settings / $ref
      Added value: +"#/$defs/settings"
    • removedInput schema / properties / settings / description
      Removed value: -"Provider-specific settings. Only the fields relevant to the chosen provider are used."
    • removedInput schema / properties / settings / properties
      Removed value: -{
-  "allowSkip": {
-    "description": "Whether the viewer may skip the form.",
-    "type": "boolean"
-  },
-  "backgroundColor": {
-    "description": "Background color of the form as a hex string.",
-    "type": "string"
-  },
-  "displayMode": {
-    "description": "(Wistia Form) How the form is displayed.",
-    "type": "string"
-  },
-  "formId": {
-    "description": "(HubSpot/Marketo/Pardot) The external form identifier.",
-    "type": "string"
-  },
-  "hashedId": {
-    "description": "(Wistia Form) The hashed ID of the Wistia form to embed.",
-    "type": "string"
-  },
-  "portalId": {
-    "description": "(HubSpot) The HubSpot portal/account identifier.",
-    "type": "string"
-  },
-  "showLogo": {
-    "description": "(Wistia Form) Whether to show the Wistia logo on the form.",
-    "type": "boolean"
-  },
-  "time": {
-    "description": "When the form appears: \"start\"/\"before\", a number of seconds, or \"end\".",
-    "type": "string"
-  }
-}
    • removedInput schema / properties / settings / type
      Removed value: -"object"
    • removedInput schema / properties / settings / unevaluatedProperties
      Removed value: -false
  2. First observedv2.0.0

TDQS

A3.7/5.0
Behavior4/5

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

Goes well beyond annotations (destructiveHint=true, idempotentHint=false) by disclosing permission requirements, delegation-token authorization semantics, the confirm=true gate, and that the call 'may share access, notify people or incur provider charges.' These are meaningful side-effect disclosures for a mutation. It does not describe reversibility or provider-specific failure behavior, keeping it short of 5.

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?

Purpose is front-loaded, then permissions and confirm requirements follow in scannable blocks. Slightly verbose with duplicated permission prose, but no wasted filler sentences.

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 nested-object mutation with no output schema, the description supplies the essential operational context: auth scope, confirm gate, side-effect warnings, and single-provider scope. It leaves provider-specific setting behavior to the schema, which is reasonable given 88% coverage.

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 88%, so the schema already documents parameters such as provider, settings, and media_id. The description adds only the 'single provider / only the selected provider is changed' nuance, which is tangential rather than clarifying param syntax, so the baseline 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?

States a specific verb and resource: 'Configures a single lead-capture provider for the video, mapping it to the appropriate underlying plugin.' The scope qualifier 'Only the selected provider is changed' separates it from bulk customization siblings like update_customizations, though it does not name a sibling tool directly.

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?

Provides concrete preconditions: required API token permissions, the delegation-token alternative, and 'Requires confirm=true for the requested mutation.' However, it never states when to use this versus get_lead_capture_customizations or create/update_customizations, so the when-to-use routing is only implied.

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