Retrieve album details from the stats.fm catalog by providing the album ID. Choose concise, detailed, or raw JSON output to get the information you need.
Look up an album in the stats.fm catalog by id
| Name | Required | Description | Default |
|---|---|---|---|
| album_id | Yes | stats.fm album id | |
| response_format | No | 'concise' = human prose, 'detailed' = more fields in prose, 'json' = raw API object | concise |
Changes observed during successful MCP inspections.
v1.29.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Look up an album' and gives no information about whether this is a read-only operation, how the catalog lookup differs from API album metadata, what the response format is, or whether it requires any special privileges. The response_format parameter hints at output behavior, but the description itself discloses little beyond the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no wasted words. It front-loads the verb and object. Slightly more context about response formats could improve it, but for its length it is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, yet the description does not explain what 'look up' returns in practice, how the catalog context differs from other album endpoints, or which sibling alternatives might suit richer needs. Given the large sibling set and the existence of similar tools, this is incomplete for an agent to reliably select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: album_id is described as 'stats.fm album id' and response_format has enum values with a default and meaning. The description adds no additional parameter meaning beyond what the schema already provides. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Look up') and resource ('album in the stats.fm catalog by id'). It clearly indicates the action and target. However, it doesn't explicitly differentiate from siblings like statsfm_catalog_track, get_album, or catalog_batch_lookup, so it loses a point for lack of sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_album, statsfm_album_stats, or catalog_batch_lookup. With a very large sibling list containing several album-related tools, the agent is left to infer usage from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.