Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

spotify_episodes_search

Search Spotify podcast episodes by term, with pagination via offset and limit (1–50), returning titles, URIs, descriptions, publishers, images, and Spotify URLs.

Instructions

Search Spotify episodes. Searches Spotify podcast episodes for the search term q, paged with offset (default 0) and limit (1 to 50). Each episode has its title, URI, description, publisher, images and Spotify URL. Episode matches appear under both results and episodes. A missing q returns 400.

Input Schema

NameRequiredDescriptionDefault
qYesSearch term
limitNoResult limit, clamped to 1-50
offsetNoSearch offset

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses pagination defaults, the 1-50 clamp, the returned episode fields, the fact that matches appear under both `results` and `episodes`, and that a missing `q` yields a 400. It omits auth needs and rate limits, but covers the essentials for a read-only search.

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-loads purpose in the first sentence and packs pagination, return shape, aliasing, and error behavior into four more without filler. Slightly dense but every sentence 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?

No output schema and no annotations exist, so the description must carry everything. It describes result fields, pagination bounds, response aliasing, and the error case, which is enough to invoke correctly; only auth and total-count/pagination-termination details are absent.

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 three parameters. The description adds only the offset default (0) and the missing-`q` error, both minor beyond the schema, so the baseline 3 is appropriate.

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+resource ('Search Spotify episodes') and clarifies it searches podcast episodes by term. Clear on its own, but it never differentiates from the many nearby siblings like spotify_podcasts_search or spotify_podcasts_show_episodes, so an agent must infer the boundary.

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 and no named alternatives. It doesn't explain when to prefer this over spotify_podcasts_search (which searches shows) or spotify_podcasts_show_episodes (episodes of one show), leaving the routing decision to inference.

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