Dynamoi

Update Smart Link Release Settings

dynamoi_update_smart_link_release_settings

DestructiveIdempotent

Use this when the user wants to change one Smart Link's release video or catalog destination visibility. Pass the read version as expectedVersion. Set any of customDescription, youtubeUrl or serviceOverrides; omitted fields preserve stored values and null explicitly clears supported fields. Public availability is artist-wide in the dashboard; this tool does not publish or unpublish individual links. Confirm the requested settings before calling. The result includes the saved releaseSettings readback; after an ambiguous failure, read it with dynamoi_get_smart_link (playLinkId; see releaseSettings) before retrying. A description or video change may queue background rendering.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "playLinkId": "<playLinkId>"
    },
    "name": "dynamoi_update_smart_link_release_settings"
  }
}

Input Schema

Name	Required	Description	Default
`playLinkId`	Yes
`youtubeUrl`	No
`clientRequestId`	No
`expectedVersion`	No
`serviceOverrides`	No
`customDescription`	No
`expectedUpdatedAt`	No
`userIntentSummary`	No

Output Schema

Name	Required	Description	Default
`code`	No
`data`	No
`kind`	No
`field`	No
`status`	Yes
`draftId`	No
`message`	No
`retryable`	No
`nextAction`	No
`failureStage`	No
`prerequisite`	No
`screeningResult`	No
`retryAfterSeconds`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 2, 2026

TDQS

A4.1/5.0

Behavior5/5

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

With destructiveHint=true already declared, the description explains exactly what is destructive: omitted fields preserve stored values while null explicitly clears supported fields. It also documents optimistic concurrency via expectedVersion, that the result is a readback of saved releaseSettings, the recovery path after an ambiguous failure, and that a change may queue background rendering.

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 trigger condition is front-loaded and each sentence carries distinct information: field semantics, scope caveat, confirmation step, failure recovery, side effects. It is dense and slightly packed, but nothing is redundant padding.

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?

An output schema exists, so the readback need not be detailed, and the description still points at dynamoi_get_smart_link for verification. Remaining gaps are minor: no statement of permission requirements and no guidance on expectedUpdatedAt versus expectedVersion, which appear to be two separate concurrency tokens.

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 0%, so the description carries the burden and does explain the patch semantics for customDescription/youtubeUrl/serviceOverrides and how expectedVersion must be supplied. It says nothing about playLinkId, clientRequestId, expectedUpdatedAt, or userIntentSummary, leaving half of the 8 parameters undocumented anywhere.

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?

Names a specific verb and resource and narrows the scope to release video / catalog destination visibility on a single Smart Link, which separates it from the broader dynamoi_update_smart_link and the description/artist-hub variants. It does not explicitly name those siblings, so an agent must infer the boundary rather than be told.

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?

"Use this when the user wants to change..." gives a clear trigger, and "this tool does not publish or unpublish individual links" plus "Confirm the requested settings before calling" add an exclusion and a pre-call check. It stops short of naming which tool does handle artist-wide publishing, leaving that inference to the agent.

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

All Dynamoi tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.