Crawlora MCP

Official

Overview Schema Source Related Servers Discussions Admin

bandcamp_discover

Browse and paginate Bandcamp Discover albums by tags, physical format, sort, time window, or place, returning artist, price, release date, cover art, and a next cursor.

Instructions

Browse Bandcamp Discover. Pages through Bandcamp Discover albums. Filter by one to five tags (genres from bandcamp_filters, subgenres from bandcamp_related_tags), physical format (vinyl, CD, cassette), sort (best-selling, new arrivals, random), a time window, and a GeoNames place id. Each album carries artist, location, price, release date, track count, duration, cover art and any physical formats. Page with the returned next_cursor.

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": "bandcamp_discover"
  }
}

Input Schema

Name	Required	Description
`size`	No	Albums per page
`sort`	No	Sort order
`tags`	No	Comma-separated tag slugs, up to 5, all of which an album must carry
`cursor`	No	next_cursor from the previous page
`format`	No	Physical format
`geoname_id`	No	GeoNames place id
`time_facet`	No	Time-window id from bandcamp_filters

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.17.20Nov 12, 2026

TDQS

A3.7/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 behavioral burden and does well: it discloses the pagination model ('Page with the returned next_cursor') and enumerates the per-album payload (artist, location, price, release date, track count, duration, cover art, physical formats), which is valuable since no output schema exists. Gaps remain around default page size, whether results beyond the first page are stable, and any rate or auth considerations.

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 definition is front-loaded with purpose, then filters, then return shape, then paging, which is the right order for an agent reading it. The only waste is mild redundancy between 'Browse Bandcamp Discover' and 'Pages through Bandcamp Discover albums', which say nearly the same thing.

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?

For a 7-parameter browsing tool with no annotations and no output schema, the description covers the essential mechanics: filter dimensions, return payload, and pagination. It still leaves the agent guessing about default page size, maximum size, and how to behave when filters yield nothing, which matters for a discovery tool with all-optional parameters.

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 baseline is 3, but the description adds real meaning beyond the schema: it explains that tags are genre slugs sourced from bandcamp_filters or subgenre slugs from bandcamp_related_tags, that the time window comes from bandcamp_filters, and that the cursor value is the returned next_cursor. The sort and format enumerations are simply restated from the schema.

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?

The description opens with a specific verb and resource ('Browse Bandcamp Discover', 'Pages through Bandcamp Discover albums') and then enumerates the available filters, so the agent knows exactly what the tool retrieves. It partially differentiates from siblings by naming bandcamp_filters and bandcamp_related_tags as the sources for tag values, though it never contrasts itself with bandcamp_search or bandcamp_artist explicitly.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: the agent can infer this is for filtered browsing, and the definition usefully points to bandcamp_filters and bandcamp_related_tags as prerequisites for valid tag and time-window values. However, there is no explicit when-to-use-this-versus-search guidance or any stated exclusion, so the agent must infer the choice between browsing and searching.

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

Deploy Server