Skip to main content
Glama
Sign In
yt-audio-mcp

yt-audio-mcp

by DaniilPak
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Search YouTube

search_youtube
Read-only

Search YouTube by text query and return video IDs or URLs to pass to download_mp3 for downloading audio tracks.

Instructions

Search YouTube and return video IDs/URLs that can be passed to download_mp3.

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": {
      "query": "<query>"
    },
    "name": "search_youtube"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
queryYesSearch text, e.g. "artist - song title"

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds value beyond that by disclosing the shape of the result (video IDs/URLs) in the absence of an output schema. It omits result ordering, pagination, and any rate-limit behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with zero filler; the action, the return type, and the downstream consumer all appear immediately.

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?

With no output schema, the description correctly shoulders the return-value explanation (video IDs/URLs). Combined with the annotations and a mostly simple two-parameter schema, this is nearly complete; only limit semantics and empty-result behavior are unaddressed.

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

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%: query is documented with an example format, but limit has no description anywhere. The tool description adds no parameter-level meaning at all, so the agent gets no guidance on what limit controls or what the default of 5 implies.

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 ("Search YouTube") plus the concrete return payload ("video IDs/URLs"). It also names the downstream sibling download_mp3, so an agent can place it in the pipeline without opening any other tool.

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?

The description establishes clear context by saying results "can be passed to download_mp3," which tells the agent this is the search step that precedes downloading. It stops short of explicit when-not guidance or naming list_downloads as an alternative for retrieval of already-downloaded items.

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