Skip to main content
Glama
chrischall

vibo-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

vibo_reorder_songs

Reorder songs in a section by moving chosen tracks to a specified position or the top, with host permission checks and a confirmation prompt.

Instructions

Reorder songs within a section: move sourceSongIds (in the given order) to directly after targetSongId, or to the top when it is omitted. Checks the ids against the section and, for a host, that the DJ allows hosts to order this section's songs. That setting is OFF for every section a host creates and only the DJ can turn it on, so a host usually cannot reorder songs in sections they added. Sends one reorderSongsBatch call per song that actually moves. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE).

Input Schema

NameRequiredDescriptionDefault
eventIdYesEvent id.
sectionIdYesSection id.
confirmTokenNoONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 "confirmation-required" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation.
targetSongIdNoplace the moved songs directly after this song _id; omit for the top
sourceSongIdsYesSong _ids from vibo_get_section_songs, in the order they should end up.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.4.0
    • changedInput schema / properties / sourceSongIds / description
      Previous value: -"Song _ids from vibo_get_section_songs."New value: +"Song _ids from vibo_get_section_songs, in the order they should end up."
    • changedInput schema / properties / targetSongId / description
      Previous value: -"place the moved songs after this song _id; omit for start"New value: +"place the moved songs directly after this song _id; omit for the top"
  2. Changed2 schema fields changedv2.3.1
    • removedInput schema / properties / confirm
      Removed value: -{
-  "description": "Must be true to proceed. Without this, the tool returns a preview.",
-  "type": "boolean"
-}
    • addedInput schema / properties / confirmToken
      Added value: +{
+  "description": "ONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 \"confirmation-required\" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation.",
+  "type": "string"
+}
  3. Changed1 schema field changedv2.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  4. Addedv1.5.3
  5. Removedv1.4.3
  6. First observedv1.3.1

TDQS

A4.4/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: the DJ-permission check and its default-off state, that one reorderSongsBatch call is sent per song that actually moves, and a full two-phase confirmation protocol (elicitation prompt, or preview + confirmToken fallback governed by MCP_CONFIRM_MODE). Annotations only say non-readonly, non-destructive, open-world; the description carries the real operational burden.

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?

Front-loaded with the core move semantics, then prerequisites, then the confirmation protocol. Six sentences is on the long side, but each conveys distinct, decision-relevant information and little is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutating, permission-gated tool with no output schema, the description covers what an agent needs: preconditions, per-song batching, the confirmation/confirmToken handshake, and the shape of the phase-1 response. Nothing material is left unexplained.

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 100%, so the schema already documents all five parameters in detail (including confirmToken usage and sourceSongIds ordering). The description restates the ordering and top-placement semantics but adds no syntax or format detail beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Reorder songs within a section') and then defines the exact semantics: move sourceSongIds in given order to directly after targetSongId, or to the top when omitted. This lets an agent distinguish it from the sibling vibo_move_song by scope ('within a section').

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?

Gives strong operational context: permission preconditions (host reorder only allowed when the DJ enables it, off by default for host-created sections) and a mandatory confirmation step. It never explicitly names an alternative sibling (e.g. vibo_move_song) for cross-section moves, so it stops short of full when/when-not routing.

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