Crawlora MCP

youtube_search

Read-only

Search public YouTube videos by query and supported filters. Use youtube_channel_search when results must be limited to one channel.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "youtube_search"
  }
}

Input Schema

Name	Required	Description
`Type`	No	Result type filter. Allowed values: video, shorts, channel, playlist, movie.
`Query`	No	Primary YouTube search query (required unless search_query is set).
`Params`	No	Raw protobuf-encoded filter string; ignored when named filters (type, sort_by, upload_date, duration, features) are present.
`Region`	No	Two-letter YouTube region code, default US.
`SortBy`	No	Sort order. Allowed values: relevance, upload_date, view_count, popularity, rating.
`Duration`	No	Video-duration filter. Allowed values: under_3_minutes, three_to_20_minutes, over_20_minutes, under_3, three_to_20, over_20, short, medium, long. The short, medium, and long labels preserve their previous encodings.
`Features`	No	Comma-separated feature filters, e.g. hd,subtitles. Allowed values: live, 4k, hd, subtitles, cc, creative_commons, 360, vr180, 3d, hdr, location, purchased.
`Language`	No	YouTube interface language, default en.
`UploadDate`	No	Upload-date filter. Allowed values: last_hour, today, this_week, this_month, this_year.
`SearchQuery`	No	Alias for q; must match q when both are provided.
`ContinuationToken`	No	Continuation token from a previous response to fetch the next page; cannot be combined with type, sort_by, upload_date, duration, features, or params.

Output Schema

Name	Required	Description	Default
`data`	Yes	The tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 5, 2026

TDQS

A4/5.0

Behavior3/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 open-world behavior are covered. The description adds the 'public' restriction (it searches public videos, not private ones), which is useful, but says nothing about pagination behavior, ordering, or result-count limits that an agent would want. With annotations carrying the safety profile, a 3 is appropriate.

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?

Two tight sentences with no filler, and the core purpose is front-loaded ahead of the sibling-routing hint. Every clause earns its place.

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 and all parameters are described in the schema, so the description need not cover return values. It is sufficient for an agent to call the tool correctly, though it omits any note on pagination expectations despite the continuation-token parameter.

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% across all 11 parameters, so enums, defaults, aliases and the continuation-token conflict rule are all documented in the schema. The description only says 'by query and supported filters', adding no syntax or constraint detail beyond the schema. Baseline 3 when the schema does the heavy lifting.

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 (search) plus resource (public YouTube videos) with scoping ('by query and supported filters') and explicitly names the sibling it is not (youtube_channel_search). An agent can distinguish it from youtube_video, youtube_channel_videos and youtube_channel_search without opening schemas.

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 a clear routing rule: use youtube_channel_search when results must be limited to one channel. That routes the main ambiguity well, but it states no other when-not conditions (e.g., single-video lookup vs. search) and no prerequisites for pagination.

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

All Crawlora MCP 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.

Resources

Need Help?