Skip to main content
Glama
chrischall

vibo-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

vibo_get_playlist_songs

Read-only

List the tracks in a connected Spotify or Apple Music playlist by playlist ID and source, with paging options.

Instructions

List the tracks in one of your connected-service playlists.

Input Schema

NameRequiredDescriptionDefault
skipNoNumber of items to skip, for paging (default 0).
viewNoResponse shape: "compact" (default) drops fields the response already carries elsewhere; "full" returns every field this server understands. compact strips image/avatar URLs from the response; "full" returns Vibo's payload untouched. No field projection: this server has no verified record of which Vibo fields matter, and inventing one would risk dropping a field a caller needs.
limitNoMax items to return (default 20).
sourceYesStreaming source — must be connected to your Vibo account.
playlistIdYesPlaylist id from vibo_get_playlists.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.4.5
    • addedInput schema / properties / view
      Added value: +{
+  "description": "Response shape: \"compact\" (default) drops fields the response already carries elsewhere; \"full\" returns every field this server understands. compact strips image/avatar URLs from the response; \"full\" returns Vibo's payload untouched. No field projection: this server has no verified record of which Vibo fields matter, and inventing one would risk dropping a field a caller needs.",
+  "enum": [
+    "compact",
+    "full"
+  ],
+  "type": "string"
+}
  2. 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"
  3. Addedv1.5.1
  4. Removedv1.4.3
  5. First observedv1.3.1

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-service access are covered. The description adds only 'connected-service' as context and says nothing about paging defaults, response shape, rate limits, or auth requirements beyond what the schema and annotations already supply.

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?

One sentence, front-loaded with the verb and resource, zero filler. It is efficient, though the brevity edges toward under-specification rather than true conciseness.

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

Completeness3/5

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

Five parameters with two required and no output schema, but the 100% schema coverage handles parameter documentation and the view/skip/limit descriptions explain return shaping. The description still omits usage context and streamed-source behavior, leaving the definition minimum-viable rather than complete.

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 100%, including detailed docs for source, view, limit, skip, and playlistId, so the baseline is 3. The description adds no parameter-level meaning beyond its phrase 'connected-service playlists', which loosely maps to the source enum already documented in the schema.

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 (list) and resource (tracks in a connected-service playlist), which is distinguishable from vibo_get_playlists (returns playlists, not tracks) and vibo_get_section_songs (section-scoped). It does not, however, name or contrast itself with 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 Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, no prerequisites, and no routing between this tool and alternatives like vibo_get_section_songs or vibo_search_songs. The hint that playlistId comes from vibo_get_playlists lives in the schema, not the description.

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