Skip to main content
Glama
chrischall

vibo-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

vibo_search_songs

Read-only

Search for songs to add to an event section by querying ' - ', using quality verdicts to confirm original recordings and avoid covers or re-uploads.

Instructions

Search for songs to add to a section. ALWAYS query as " - " with a space-hyphen-space separator (e.g. "Ed Sheeran - Thinking Out Loud"). Vibo's default 'searchField' index is a loose text match over a catalog full of YouTube covers, karaoke tracks and re-uploads: the hyphenated form resolves to the official recording, while the same words unhyphenated rank covers and re-uploads above it (measured live — "Chris Stapleton - Tennessee Whiskey" returned only the official master; without the hyphen, none of the nine results was the original). Each result carries a quality verdict (likely-original / uncertain / likely-not-original) plus warnings — check it before adding, and never add a likely-not-original result without saying so. source 'spotify' searches your connected Spotify (a structured catalog, so the hyphen matters less). Returns songUrl/viboSongId/title/artist for vibo_add_song_to_section.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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 results (default 20).
queryYesSong to search for, as "<Artist> - <Title>" (space-hyphen-space). Use the artist's own stylization — the index does not fold variants together, and "Dan + Shay - Speechless" returns the official master while "Dan and Shay - Speechless" returns covers and live cuts without it. Artist alone returns only a short popularity-ranked subset of their catalog, so a specific track may be missing entirely. If the hyphenated query looks wrong, retry as "<Title> - <Artist>", then the title alone filtered by artist.
sourceNoSearch source (default 'searchField').
eventIdYesEvent id (search is scoped to an event/section).
sectionIdYesSection id the search is for.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.8.0
    • 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. Addedv1.5.3
  3. Removedv1.4.3
  4. First observedv1.3.1

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description reveals substantial non-obvious behavior: the searchField index is a loose text match over a catalog polluted with covers and karaoke tracks, the hyphenated form changes ranking outcomes (backed by a measured live result), results carry quality verdicts, and there is an explicit safety rule about never silently adding likely-not-original results. This is exactly the behavioral context annotations cannot 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 description is dense — roughly 160 words — but every sentence earns its place: the ALWAYS rule is front-loaded, the empirical anecdote justifies an otherwise suspiciously strong directive, and the quality-verdict warning addresses a real safety concern. Slightly long for a search tool, but none of the content is filler.

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?

There is no output schema, yet the description handles the burden: it states the returned fields (songUrl/viboSongId/title/artist), the quality verdicts on results, the source-specific behavior, and the downstream consumer (vibo_add_song_to_section). For a 6-parameter search tool this is complete — nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/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 every parameter, placing the baseline at 3. The description adds value on top: it elevates the query parameter's format to an 'ALWAYS' rule with empirical evidence the schema lacks, explains why the source parameter matters (structured Spotify vs loose searchField index), and links the query outcome to downstream safety checks. This is meaningful enrichment rather than mere restatement.

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?

The description opens with a specific verb+resource: 'Search for songs to add to a section.' It is immediately distinguishable from siblings like vibo_add_song_to_section (which adds rather than searches) and vibo_list_section_songs/vibo_get_section_songs (which list existing state rather than search). The scope is clear and the tool's role in the workflow is named.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

Usage guidance is exceptionally explicit: the ALWAYS rule for query formatting is stated first, with a concrete example, empirical justification, and the specific failure mode it prevents. It also gives fallback strategies ('retry as "<Title> - <Artist>"' then title-only), and a source-selection rule (spotify vs searchField), so an agent knows exactly when and how to invoke the tool.

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