Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

spotify_profiles_search

Search Spotify profiles by term and return matching results without requiring Spotify bearer or client tokens.

Instructions

Search Spotify profiles. Returns Spotify profile search results for a search term. Caller-supplied Spotify bearer or client tokens are not required.

Input Schema

NameRequiredDescriptionDefault
qYesSearch term
limitNoProfile result limit, clamped to 1-50
offsetNoSearch offset
include_authorsNoInclude authors
include_audiobooksNoInclude audiobook context where available
include_pre_releasesNoInclude pre-release results
number_of_top_resultsNoTop result limit, clamped to 1-50
include_album_pre_releasesNoInclude album pre-release results
include_episode_content_ratings_v2NoInclude Spotify episode content ratings v2

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.1/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It usefully discloses that caller-supplied bearer/client tokens are not required (auth context), but omits pagination behavior, result shape, and rate/limit characteristics for a search endpoint.

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

Conciseness3/5

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

Three short sentences, but the first two are redundant ('Search Spotify profiles' vs 'Returns Spotify profile search results for a search term'). The auth note is the only non-repetitive content and should have been front-loaded.

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?

With no output schema, no annotations, and nine parameters, the description is thin; it never explains the paginated result set implied by limit/offset or the meaning of the many include_* toggles. It covers the core action and auth but leaves meaningful gaps.

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%, so all nine parameters are already documented in the schema (including the 1-50 clamps). The description adds no parameter-level meaning beyond the schema, so 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 ('Search') and resource ('Spotify profiles'), which distinguishes it from the many other spotify_*_search siblings by resource type. It does not explicitly name the alternatives, so it stops short of a 5.

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?

The description says results are returned 'for a search term' but gives no when-to-use guidance or exclusions relative to siblings like spotify_profile (single profile fetch) or spotify_search (broad search). Nothing helps an agent choose between this and adjacent tools.

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