Skip to main content
Glama
hlights33

discogs-mcp

by hlights33
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

sync_release_details

Fetches tracklist and country details for cached Discogs releases missing them, running in background and resumable if interrupted.

Instructions

Fetch full release detail (tracklist, country) for cached releases that lack it.

    Costs one API request per release (Discogs allows 60/min), so by default it runs in
    the background and returns immediately; check progress with sync_status. It is
    resumable: re-running continues where it stopped. Leaves headroom in the rate limit
    for other tools.

Input Schema

NameRequiredDescriptionDefault
backgroundNo
max_releasesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Adds real behavior beyond the sparse annotations: one API request per release, a 60/min provider limit, background-by-default semantics, resumability, and rate-limit headroom reservation. Minor tension with openWorldHint=false since the tool explicitly calls the external Discogs API, but the annotation may be intended for the closed local cache it writes.

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?

Four short sentences, front-loaded with what it fetches and what it costs, with no filler. Slightly fragmented by line breaks, but every sentence carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema is needed since the description names the fetched fields and points to sync_status for progress. For a resumable, rate-limited background sync the description covers the behavior an agent needs before invoking it.

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 0%, so the description must carry both parameters. It explains the background default well, but max_releases is never mentioned or given units/bounds, so the description only partially compensates for the undocumented schema.

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+resource ('Fetch full release detail') plus the exact scope that separates it from get_release: 'for cached releases that lack it'. The parenthetical enumerates the added fields (tracklist, country), so an agent can tell it apart from the other release-fetching siblings.

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 clear operational context: default is background execution and progress is checked via sync_status, plus it is resumable. It never explicitly says when NOT to call it (e.g., vs get_release for a single release), so it falls short of full when/when-not guidance.

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