Wistia MCP Server

Create Folder Sharing

create_folder_sharing

Destructive

Creates a new sharing entry for a Wistia folder so you can grant a person access by email and set permissions like upload or download.

Instructions

Creates a new sharing object for a folder by specifying the email of the person to share with and other optional parameters.

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

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.
`payload`	No	Complete JSON request body instead of body flags. Supports current nested customization, caption and nullable values.
`sharing`	No
`folder_id`	Yes	Hashed ID of the folder to be shared
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedv3.0.0Oct 7, 2026

addedInput schema / $defs

Added value: +{
+  "sharing": {
+    "properties": {
+      "canDownload": {
+        "description": "Whether the user is allowed to download files from the folder. Defaults to false.",
+        "type": "boolean"
+      },
+      "canShare": {
+        "description": "Whether the user is allowed to share the folder with others. Defaults to false.",
+        "type": "boolean"
+      },
+      "canUpload": {
+        "description": "Whether the user is allowed to upload files to the folder. Defaults to false.",
+        "type": "boolean"
+      },
+      "requirePassword": {
+        "description": "A flag indicating whether or not a password is required. Defaults to true.",
+        "type": "boolean"
+      },
+      "sendEmailNotification": {
+        "deprecated": true,
+        "description": "Deprecated! Email notifications are always sent now.",
+        "enum": [
+          "0",
+          "1"
+        ],
+        "type": "string"
+      },
+      "with": {
+        "description": "The email address of the person with whom you want to share the folder.",
+        "format": "email",
+        "type": "string"
+      }
+    },
+    "required": [
+      "with"
+    ],
+    "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 / sharing / $ref
```
Added value: +"#/$defs/sharing"
```

removedInput schema / properties / payload / properties / sharing / properties

Removed value: -{
-  "canDownload": {
-    "description": "Whether the user is allowed to download files from the folder. Defaults to false.",
-    "type": "boolean"
-  },
-  "canShare": {
-    "description": "Whether the user is allowed to share the folder with others. Defaults to false.",
-    "type": "boolean"
-  },
-  "canUpload": {
-    "description": "Whether the user is allowed to upload files to the folder. Defaults to false.",
-    "type": "boolean"
-  },
-  "requirePassword": {
-    "description": "A flag indicating whether or not a password is required. Defaults to true.",
-    "type": "boolean"
-  },
-  "sendEmailNotification": {
-    "deprecated": true,
-    "description": "Deprecated! Email notifications are always sent now.",
-    "enum": [
-      "0",
-      "1"
-    ],
-    "type": "string"
-  },
-  "with": {
-    "description": "The email address of the person with whom you want to share the folder.",
-    "format": "email",
-    "type": "string"
-  }
-}

removedInput schema / properties / payload / properties / sharing / required
```
Removed value: -[
-  "with"
-]
```
removedInput schema / properties / payload / properties / sharing / type
```
Removed value: -"object"
```
removedInput schema / properties / payload / properties / sharing / unevaluatedProperties
```
Removed value: -false
```
addedInput schema / properties / sharing / $ref
```
Added value: +"#/$defs/sharing"
```

removedInput schema / properties / sharing / properties

Removed value: -{
-  "canDownload": {
-    "description": "Whether the user is allowed to download files from the folder. Defaults to false.",
-    "type": "boolean"
-  },
-  "canShare": {
-    "description": "Whether the user is allowed to share the folder with others. Defaults to false.",
-    "type": "boolean"
-  },
-  "canUpload": {
-    "description": "Whether the user is allowed to upload files to the folder. Defaults to false.",
-    "type": "boolean"
-  },
-  "requirePassword": {
-    "description": "A flag indicating whether or not a password is required. Defaults to true.",
-    "type": "boolean"
-  },
-  "sendEmailNotification": {
-    "deprecated": true,
-    "description": "Deprecated! Email notifications are always sent now.",
-    "enum": [
-      "0",
-      "1"
-    ],
-    "type": "string"
-  },
-  "with": {
-    "description": "The email address of the person with whom you want to share the folder.",
-    "format": "email",
-    "type": "string"
-  }
-}

removedInput schema / properties / sharing / required
```
Removed value: -[
-  "with"
-]
```
removedInput schema / properties / sharing / type
```
Removed value: -"object"
```
removedInput schema / properties / sharing / unevaluatedProperties
```
Removed value: -false
```

First observedv2.0.0Oct 2, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, openWorldHint=true, and non-idempotence, so the safety profile is covered. The description adds genuinely useful context beyond that: the exact permission scopes needed, the delegate-to-contact authorization path, and the side-effect warning that it 'May share access, notify people or incur provider charges.' This is more than the annotations alone convey.

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 opening sentence is front-loaded with verb, resource, and key parameter, and the permission/confirm warnings are relevant rather than filler. The fenced permission block is bulky relative to a short prose description, but it carries actionable authorization information.

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 destructive mutation with nested request bodies and no output schema, the description supplies the auth requirements, the confirm gate, and the side-effect profile an agent needs before calling. Return-value documentation is unnecessary since no output schema exists. It is close to complete for its complexity.

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 83%, so the schema already documents the sharing fields, folder_id, and body alternatives. The description reinforces the email parameter and notes 'other optional parameters' but adds no syntax, defaults, or format detail beyond what the schema provides. 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 ('Creates a new sharing object for a folder') plus the primary parameter (the email of the person to share with). An agent can distinguish it from sibling tools like update_folder_sharing and delete_folder_sharing by the creation semantics, though the description never names those siblings explicitly.

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?

Usage context is implied by naming the required permission scopes and the confirm=true requirement, but there is no explicit guidance on when to prefer this over update_folder_sharing or delete_folder_sharing, nor any when-not condition. The prerequisites are stated but the routing guidance is left to inference.

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

Deploy Server