Provides 41 read-only tools for interacting with Last.fm, including searching artists, albums, and tracks; retrieving artist, album, and track details; accessing user scrobble history, loved tracks, friends, top artists/tracks/albums/tags, and weekly charts; fetching global, tag, and country charts; obtaining name corrections; and library lookups.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-lastfm Search for the artist 'Mogwai'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for Last.fm — discover artists, albums and tracks, and browse scrobble history and charts.
Website · Documentation
41 read-only tools — search, artist, album/track, user, chart, tag, geo, and library lookups, all backed by the official Last.fm API
Scrobble history at a glance — pull any user's recent tracks, loved tracks, friends, top artists/tracks/albums/tags, and weekly charts over a chosen time period
Global, tag, and country charts — surface what's trending on Last.fm overall, within a tag (e.g. shoegaze), or by country
Name corrections — check Last.fm's canonical-name correction data for misspelled artists and tracks
Just an API key — a single MCP_LASTFM_API_KEY, no OAuth flow or session handshake; set an optional MCP_LASTFM_USERNAME to default the user tools to your own account
Safe by design — read-only throughout; no scrobbling, no writes, nothing that touches a user's Last.fm account
Related MCP server: lastfm-mcp
npm install -g @kud/mcp-lastfmOr install as a Claude plugin from the kud marketplace:
/plugin install lastfm@kudnpm publish is pending — until
@kud/mcp-lastfmlands on the registry, install from source (see Development).
Go to last.fm/api/account/create (you'll need to be signed in to a Last.fm account).
Fill in Application name (e.g. mcp-lastfm) and a short description. Leave Callback URL blank — it's only used for the web login flow, which this read-only server doesn't need.
Submit. Last.fm shows you an API key and a shared secret — you only need the API key. (The shared secret is for signed write calls like scrobbling, which aren't supported here.)
Add it to your MCP client config:
{
"mcpServers": {
"lastfm": {
"command": "mcp-lastfm",
"env": {
"MCP_LASTFM_API_KEY": "your-api-key",
"MCP_LASTFM_USERNAME": "your-lastfm-username"
}
}
}
}Variable | Required | Purpose |
| yes | Authenticates every request |
| no | Default account for the |
Once connected, ask your MCP client things like:
> Search for the artist "Slowdive"
> What are Radiohead's top tracks?
> Show me my recent scrobbles
> What's trending on the shoegaze tag right now?Tool | Description |
| Search for artists by name |
| Search for albums by name |
| Search for tracks by name, optionally scoped to an artist |
Tool | Description |
| Artist bio, listener/play stats, and tags |
| Artists similar to a given one, with match scores |
| An artist's most-played tracks |
| An artist's most-played albums |
| The tags most applied to an artist |
| Last.fm's canonical spelling for a misspelled artist name |
Tool | Description |
| Album info, tracklist, and tags |
| The tags most applied to an album |
| Track info, stats, and tags |
| Tracks similar to a given one |
| The tags most applied to a track |
| Last.fm's canonical spelling for a misspelled track/artist |
Tool | Description |
| A user's profile and listening stats |
| Recent scrobbles, including the currently playing track |
| Most-played artists over a time period |
| Most-played tracks over a time period |
| Most-played albums over a time period |
| Tracks the user has marked as loved |
| The user's Last.fm friends |
| Items the user has tagged with a given tag |
| The user's most-used tags |
| Album play chart for a given week |
| Artist play chart for a given week |
| Track play chart for a given week |
| Available weekly-chart date ranges |
Tool | Description |
| The most popular artists on Last.fm right now |
| The most popular tracks on Last.fm right now |
| The most popular tags on Last.fm right now |
Tool | Description |
| Top artists for a tag |
| Top tracks for a tag |
| A tag's description and usage stats |
| Tags similar to a given one |
| Top albums for a tag |
| The most popular tags globally |
| Available weekly-chart date ranges for a tag |
Tool | Description |
| Top artists in a given country |
| Top tracks in a given country |
Tool | Description |
| Artists in a user's library, with play counts |
git clone https://github.com/kud/mcp-lastfm.git
cd mcp-lastfm
npm install
MCP_LASTFM_API_KEY=your-api-key MCP_LASTFM_USERNAME=your-username npm run devInspect the server interactively with the MCP inspector:
npm run inspect:dev📚 Full documentation → mcp-lastfm/docs
Check Last.fm's correction data for a canonical artist name
| Name | Required | Description | Default |
|---|---|---|---|
| artist | Yes | Artist name to check for a correction |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Basic transparency as a read operation, but no details on what 'correction data' entails (e.g., output format, authentication, rate limits). No annotations present to supplement.
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?
Extremely concise single sentence. Front-loaded with verb and resource. Could include more context without becoming verbose.
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?
No output schema, so the description should indicate what the tool returns. Missing return value information makes it incomplete for a simple check tool.
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% for the single parameter 'artist'. The tool description adds no additional meaning beyond what the schema already provides.
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 clearly states the verb 'Check' and the resource 'correction data for a canonical artist name', distinguishing it from sibling tools like 'correct_track'.
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?
Usage is implied by the resource (artist correction), but no explicit when-to-use or alternatives are given. Sibling differentiation is clear from name, but no additional guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check Last.fm's correction data for a canonical track name
| Name | Required | Description | Default |
|---|---|---|---|
| track | Yes | Track name to check for a correction | |
| artist | Yes | Artist name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It implies a read operation but does not disclose any behavioral traits such as side effects, permission requirements, rate limits, or response handling for missing tracks.
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 short sentence with no unnecessary words, achieving conciseness. However, it could be improved by front-loading the core action more effectively.
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?
With no output schema or annotations, the description should explain the return value and behavior more fully. It only mentions 'check' without specifying what the output is or how correction data is presented.
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 coverage is 100% with descriptions for both parameters. The description adds minimal extra meaning beyond the schema, only indicating the purpose of the parameters indirectly. Baseline 3 is appropriate.
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 clearly states the verb 'Check' and the resource 'Last.fm's correction data for a canonical track name'. It specifically mentions tracks, distinguishing from the sibling 'correct_artist' tool.
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?
No guidance on when to use this tool versus alternatives. Does not mention when not to use it or provide context for its application among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed info for an album: tracklist, tags, wiki
| Name | Required | Description | Default |
|---|---|---|---|
| mbid | No | MusicBrainz release ID | |
| album | No | Album name (required unless mbid given) | |
| artist | No | Artist name (required unless mbid given) | |
| autocorrect | No | Correct misspelled artist/album names |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description partially discloses behavior by listing return fields (tracklist, tags, wiki) but omits any side effects, authentication needs, or rate limits. It does not contradict annotations since none exist.
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, front-loaded sentence with no wasted words. Every phrase ('Get detailed info', 'tracklist, tags, wiki') is essential and earns its place.
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?
For a simple retrieval tool with four self-explanatory parameters and no output schema, the description adequately covers what the tool does. A mention of the mbid priority or required combinations could improve it slightly, but it is not deficient.
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%, so the schema already documents all four parameters. The description adds no parameter-specific details beyond the schema; it only states the output types, not parameter roles or constraints.
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 'Get detailed info for an album: tracklist, tags, wiki' uses a specific verb ('Get') and resource ('album'), and lists concrete data components, clearly distinguishing it from siblings like get_artist or get_track.
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 implies usage for retrieving album details but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among the many sibling tools. Its purpose is clear but lacks comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the top tags applied to an album
| Name | Required | Description | Default |
|---|---|---|---|
| mbid | No | MusicBrainz release ID | |
| album | No | Album name (required unless mbid given) | |
| artist | No | Artist name (required unless mbid given) | |
| autocorrect | No | Correct misspelled artist/album names |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'get the top tags' without detailing what 'top tags' means (e.g., sorted by count), whether authentication is needed, rate limits, or any side effects. This is insufficient for a tool that likely performs a data retrieval operation.
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 sentence with no filler, making it very concise. However, it is perhaps too minimal for the complexity of the tool, but conciseness is not the issue; it just lacks depth. The structure is fine.
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?
Given the four parameters and no output schema, the description is incomplete. It does not explain the return format (e.g., list of tag names with counts), pagination, error conditions, or how 'top' is determined. Additional context would be valuable for correct invocation.
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%, so the baseline is 3. The description adds no semantic value beyond the schema; it does not explain terms like 'top tags' or clarify parameter interactions (e.g., mbid vs album+artist). However, the schema itself is clear, so no additional information is strictly necessary.
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 clearly states the verb 'Get' and the specific resource 'top tags applied to an album', making the tool's purpose immediately evident. It distinguishes from sibling tools like get_artist_top_tags (which focuses on artist tags) and get_tag_top_albums (which retrieves albums for a given tag), as it explicitly mentions the album as the target.
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_artist_top_tags, get_tag_top_albums, or get_top_tags. There is no mention of prerequisites, preferred parameter combinations, or scenarios where this tool is most appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed info for an artist: bio, stats, tags, similar artists
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | ISO 639 alpha-2 language code for the bio | |
| mbid | No | MusicBrainz artist ID | |
| artist | No | Artist name (required unless mbid given) | |
| autocorrect | No | Correct misspelled artist names |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose all behavioral traits. It only says 'get detailed info,' implying a read operation, but it does not mention authentication requirements, rate limits, data freshness, or whether the bio is returned in the specified language.
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?
A single sentence that aptly summarizes the tool's purpose. Every word is necessary; no fluff. The key components are front-loaded.
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 description lists the main data types (bio, stats, tags, similar artists) but does not specify the return format or structure. Given the lack of an output schema and many sibling tools, more detail about the response would improve completeness. Adequate for a simple fetch, but gaps exist.
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%, so the schema describes all parameters. The description adds high-level context (bio, stats, tags, similar artists) but does not explain how parameters like 'lang' or 'autocorrect' interact with the output. Baseline of 3 is appropriate.
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 clearly states the tool retrieves detailed artist info including bio, stats, tags, and similar artists. It distinguishes from sibling tools that focus on specific aspects (e.g., get_artist_top_albums). However, it does not explicitly differentiate itself from get_artist_top_tags or get_similar_artists, which are listed as siblings.
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?
No guidance on when to use this tool versus its many siblings (e.g., get_artist_top_albums for top albums only). The description does not specify prerequisites or whether it replaces other tools like get_similar_artists. This leaves ambiguity for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an artist's most popular albums
| Name | Required | Description | Default |
|---|---|---|---|
| mbid | No | MusicBrainz artist ID | |
| page | No | Page number | |
| limit | No | Results per page | |
| artist | No | Artist name (required unless mbid given) | |
| autocorrect | No | Correct misspelled artist names |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states 'most popular albums' without explaining sorting, popularity criteria, authentication needs, rate limits, or side effects. The requirement for 'artist' or 'mbid' is not mentioned, though it appears in the schema.
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 sentence of six words, very concise and to the point. No extraneous information, though it could benefit from more detail without sacrificing conciseness.
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?
Given the 5 parameters (including optional 'artist'/'mbid' and pagination) and no output schema, the description lacks essential context such as return format, pagination behavior, and how popularity is determined. An agent would have insufficient information to use the tool 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%, so the baseline is 3. The description adds no parameter-level information beyond what the schema provides. It does not clarify relationships between parameters (e.g., 'artist' vs 'mbid') or usage conventions.
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 clearly states the tool retrieves 'an artist's most popular albums,' using a specific verb ('Get') and resource ('artist's most popular albums'). It effectively distinguishes from siblings like 'get_artist_top_tracks' and 'get_artist.'
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?
No guidance is provided on when to use this tool versus alternatives such as 'get_album_top_tags' or 'get_artist_top_tracks.' The description does not mention prerequisites, exclusions, or context for choosing this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the top tags applied to an artist
| Name | Required | Description | Default |
|---|---|---|---|
| mbid | No | MusicBrainz artist ID | |
| artist | No | Artist name (required unless mbid given) | |
| autocorrect | No | Correct misspelled artist names |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose behavior beyond 'Get'. No mention of authentication, rate limits, or error scenarios for a read operation.
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?
Single short sentence with zero waste. Front-loaded and efficient.
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?
Low complexity tool but no output schema; description does not clarify return format or what 'top' means. Adequate but not rich.
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 coverage is 100% with descriptions for all 3 parameters. Description adds no extra meaning beyond what is in the schema, meeting the baseline.
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?
Description clearly states 'Get the top tags applied to an artist' – a specific verb and resource. It distinguishes from siblings like get_artist_top_albums and get_top_tags.
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?
No guidance on when to use this tool vs. alternatives such as get_artist_top_albums or get_tag_top_artists. No prerequisites or when-not-to-use hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an artist's most popular tracks
| Name | Required | Description | Default |
|---|---|---|---|
| mbid | No | MusicBrainz artist ID | |
| page | No | Page number | |
| limit | No | Results per page | |
| artist | No | Artist name (required unless mbid given) | |
| autocorrect | No | Correct misspelled artist names |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure, but it provides none beyond the basic action. Details like ordering, pagination behavior, or error handling are absent, leaving the agent to guess.
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 extremely concise—one sentence with no filler. It earns its place without any wasted words.
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?
Despite having 5 parameters and no output schema, the description provides almost no context. It lacks information on output format, ordering, or how parameters interrelate, making it insufficient for the tool's complexity.
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%, so baseline is 3. The description adds no extra meaning to parameters beyond what the schema already provides, neither explaining relationships nor usage nuances.
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 clearly states the action (Get) and resource (artist's most popular tracks), making the purpose obvious. However, it does not differentiate from sibling tools like get_artist_top_albums or get_artist_top_tags, relying solely on the resource name for distinction.
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?
No guidance is provided on when to use this tool versus alternatives, nor any when-not-to or prerequisites. The description is too minimal to help an agent decide contextually.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current global top artists chart
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| limit | No | Results per page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only indicates a read operation ('Get') but lacks details on response format, pagination behavior, data freshness, or any side effects.
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?
A single, efficient sentence that directly communicates the tool's purpose without extraneous information.
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 description is adequate given the simple tool, but lacks details about the chart output structure (e.g., artist names, positions). With no output schema, additional context would improve completeness.
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 coverage is 100% with descriptions for 'page' and 'limit'. The description adds no additional meaning beyond the schema, meeting the baseline but not enhancing understanding.
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 clearly states 'Get the current global top artists chart', specifying a verb and resource. It distinguishes from siblings like 'get_chart_top_tracks' and 'get_geo_top_artists' by focusing on global artists.
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?
No guidance on when to use this tool vs alternatives like 'get_geo_top_artists' or 'get_artist_top_artists'. The description offers no context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current global top tags chart
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| limit | No | Results per page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'Get', implying read-only but does not disclose any behavioral traits like rate limits, caching, pagination behavior, or output format.
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?
Single sentence of 7 words, highly concise and front-loaded. No waste, but could benefit from slight expansion.
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?
Given no output schema and no annotations, the description lacks context about the return value, result structure, or any constraints. For a chart tool, more detail is expected.
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 coverage is 100% with descriptions for both page ('Page number') and limit ('Results per page'). The description adds no extra meaning beyond the schema, so baseline score of 3 applies.
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 clearly states 'Get the current global top tags chart', specifying the verb and resource. It distinguishes from sibling tools like get_top_tags (possibly user-specific) and get_chart_top_artists/tracks.
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?
No guidance on when to use this tool vs alternatives like get_top_tags or get_chart_top_artists. No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current global top tracks chart
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| limit | No | Results per page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states 'current global top tracks chart' but does not mention that the operation is read-only, any rate limits, data freshness, or response structure.
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 sentence with no extraneous words. It is efficient and front-loaded with the essential purpose.
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?
For a simple list tool with no output schema and two optional parameters, the description is minimally viable. However, given the large number of sibling tools, it could benefit from additional context such as the chart's update frequency or scope.
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?
The input schema covers both parameters with descriptions (100% coverage). The description adds no additional meaning beyond what is in the schema, so a baseline score of 3 is appropriate.
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 uses the specific verb 'Get' and clearly identifies the resource as 'current global top tracks chart'. This is distinct from sibling tools like get_chart_top_artists or get_geo_top_tracks, making the tool's purpose unambiguous.
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?
No guidance is provided on when to use this tool versus alternatives. For example, it does not clarify differences from get_geo_top_tracks or when pagination parameters should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the most popular artists for a given country
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| limit | No | Results per page | |
| country | Yes | Country name per ISO 3166-1, e.g. 'United Kingdom' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states 'Get the most popular artists', indicating a read operation, but lacks details on rate limits, authentication, error handling, or what constitutes 'popular'.
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 sentence, which is concise and front-loaded. However, it sacrifices completeness for brevity.
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?
Given no annotations and no output schema, the description should provide more context about the tool's behavior, return format, or expected inputs. The current description is too sparse, leaving significant gaps.
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% with clear descriptions for country, page, and limit. The description adds no additional meaning beyond the schema; baseline is 3.
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 clearly states the verb 'Get' and resource 'most popular artists for a given country', but 'most popular' is ambiguous (not specifying metric). It does not explicitly differentiate from sibling tools like get_chart_top_artists or get_tag_top_artists.
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. There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the most popular tracks for a given country
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| limit | No | Results per page | |
| country | Yes | Country name per ISO 3166-1, e.g. 'United Kingdom' | |
| location | No | Narrow results to a metro area within the country |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits such as authorization requirements, rate limits, or side effects. It provides none, leaving the agent uninformed about potential constraints.
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, efficient sentence with no wasted words. It is front-loaded and to the point.
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 description lacks essential context: no output schema exists, but the description does not explain the return format, pagination behavior (despite page/limit parameters), or any other nuances. It is insufficient for a 4-parameter tool.
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 coverage is 100%, so the schema already describes all parameters. The description adds no additional meaning beyond what the schema provides, meeting the baseline of 3.
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 clearly states the verb ('get'), resource ('most popular tracks'), and scope ('for a given country'), distinguishing it from sibling tools like get_geo_top_artists.
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?
No guidance is provided on when to use this tool vs alternatives like get_chart_top_tracks or search_tracks. No exclusions or context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all the artists in a user's library
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| user | No | Last.fm username; defaults to MCP_LASTFM_USERNAME when set, so it can be omitted for your own account | |
| limit | No | Results per page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description does not disclose behavioral traits such as pagination behavior, rate limits, or authentication requirements beyond what the schema hints at. The schema includes page/limit parameters, but the description adds no context.
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?
Single sentence, concise but not leveraging structure. Could include more context while remaining concise.
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?
No output schema; description incomplete for understanding return format (e.g., list of names vs objects). With moderate complexity and pagination, more detail is needed.
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 covers all three parameters with descriptions. The tool description does not add meaning beyond the schema, so baseline 3 applies.
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 clearly states it gets all artists in a user's library, using a specific verb and resource. It distinguishes from sibling tools like get_chart_top_artists and get_user_top_artists, which focus on top artists rather than the full library.
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?
No guidance on when to use this tool vs alternatives like get_user_top_artists or search_artists. The agent is left to infer the scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get artists similar to a given artist
| Name | Required | Description | Default |
|---|---|---|---|
| mbid | No | MusicBrainz artist ID | |
| limit | No | Results per page | |
| artist | No | Artist name (required unless mbid given) | |
| autocorrect | No | Correct misspelled artist names |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only states the purpose and does not disclose behavioral traits like return format, permission requirements, side effects, or pagination. The description is insufficient.
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 sentence, concise and front-loaded. While brief, it captures the essential purpose without extraneous words. Could be more detailed but remains efficient.
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?
Despite having 4 parameters and no output schema, the description omits how to specify the artist (by mbid or name), the effect of limit, and autocorrect. It is too minimal to fully guide the agent.
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%, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides for parameters like 'mbid', 'limit', 'artist', and 'autocorrect'.
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 the verb 'Get', the resource 'artists', and the condition 'similar to a given artist'. It clearly differentiates from siblings like 'get_artist' (details of a specific artist) and 'search_artists' (search by name).
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_artist_top_artists' or search tools. It does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get tags similar to a given tag
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes | Tag name, e.g. 'shoegaze' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. The description does not disclose any behavioral traits such as pagination, result count, or what 'similar' means. It is a read operation, but this is not explicitly stated.
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 concise sentence that is front-loaded. However, it could be slightly more informative without adding length.
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?
For a simple tool with one parameter and no output schema, the description is adequate but minimal. It does not explain the nature of similarity or provide any extra context that might be helpful.
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 coverage is 100% with one parameter 'tag' well-documented in the schema. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
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 clearly states the verb 'Get' and the resource 'tags similar to a given tag'. It is specific and distinguishes from sibling tools like 'get_tag_info' and 'get_top_tags' which have different purposes.
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?
No explicit guidance on when to use this tool versus alternatives. The usage context is implied by the description, but there are no exclusions or suggestions for other tag-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get tracks similar to a given track
| Name | Required | Description | Default |
|---|---|---|---|
| mbid | No | MusicBrainz track ID | |
| limit | No | Results per page | |
| track | No | Track name (required unless mbid given) | |
| artist | No | Artist name (required unless mbid given) | |
| autocorrect | No | Correct misspelled artist/track names |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only states the basic function without disclosing any behavioral traits such as how similarity is computed, data source, rate limits, or whether the response includes confidence scores. This is insufficient for a recommendation tool.
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 sentence with no wasted words. However, it is slightly too terse; adding a brief note about the dual identification methods would improve conciseness without adding length penalty.
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?
Given the tool has 5 parameters and no output schema, the description is minimally informative. It doesn't explain the alternative ways to specify the track (MBID vs track+artist), nor does it hint at the response structure or pagination behavior (limit parameter). This leaves the agent underinformed.
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?
With 100% schema coverage, all parameters are described in the input schema (e.g., 'mbid: MusicBrainz track ID', 'limit: Results per page'). The description adds no additional semantics beyond what the schema already provides, meeting the baseline for this dimension.
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 'Get tracks similar to a given track' clearly states the action (get) and the resource (tracks similar to a given track). It distinguishes from siblings like 'get_similar_artists' and 'get_similar_tags' which target different entities.
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?
No explicit guidance on when to use this tool versus alternatives. It does not mention the two modes of identifying the track (by MBID or by track/artist name), nor does it clarify scenarios where it is preferable over other tools like 'get_track' or 'get_user_top_tracks'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metadata and wiki for a tag
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes | Tag name, e.g. 'shoegaze' | |
| lang | No | ISO 639 alpha-2 language code for the wiki |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behaviors. It states the tool gets data but does not mention side effects, authentication needs, rate limits, or behavior on missing tags. The implication is read-only, but it is not explicit.
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. It is appropriately short for a simple tool, though it could include more detail without being verbose. Structurally, it is front-loaded with the main action.
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?
No output schema is provided, so the description should explain what the response contains. It mentions 'metadata and wiki' but not the specific fields. It also lacks details on error handling, pagination (if any), or default behavior for the optional lang parameter.
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?
The input schema covers both parameters (tag, lang) with descriptions. The description adds no extra meaning beyond the schema, so baseline 3 applies. It does not explain the relationship between parameters and output.
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 'Get metadata and wiki for a tag' clearly indicates the action and resource. It distinguishes from sibling tools like get_top_tags (which lists top tags) and get_tag_top_albums (which gets albums for a tag) by focusing on metadata and wiki. However, it could be more specific about what 'metadata' includes.
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?
No guidance on when to use this tool versus alternatives like get_similar_tags or get_tag_top_artists. The description does not mention prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the top albums tagged with a given tag
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes | Tag name, e.g. 'shoegaze' | |
| page | No | Page number | |
| limit | No | Results per page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Get the top albums'. It does not disclose any behavioral traits such as read-only nature, pagination defaults, or impact on data.
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 sentence with no unnecessary words. It is front-loaded with the primary action and resource.
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?
For a simple retrieval tool, the description is minimally adequate. However, given no output schema and no annotations, additional context about sorting or pagination behavior would improve completeness.
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 coverage is 100%, with descriptions for all three parameters. The tool description does not add 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves top albums for a given tag. It distinguishes from sibling tools like get_tag_top_artists and get_tag_top_tracks by specifying 'albums'.
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?
No guidance on when to use this tool versus alternatives. It does not mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the top artists tagged with a given tag
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes | Tag name, e.g. 'shoegaze' | |
| page | No | Page number | |
| limit | No | Results per page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It does not disclose any behavioral traits such as pagination, authentication, rate limits, or the meaning of 'top' (e.g., sorted by play count?). This is a significant gap.
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, concise sentence without unnecessary words. It is well-structured and front-loaded.
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?
Given the lack of an output schema, the description should at least hint at the return structure (e.g., list of artist objects). It does not, making it incomplete for an agent to fully understand the tool's output.
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 coverage is 100%, with all three parameters having descriptions. The tool description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
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 clearly states the verb 'Get' and the resource 'top artists tagged with a given tag', distinguishing it from sibling tools like get_tag_top_albums and get_tag_top_tracks.
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 is clear about what the tool does but provides no explicit guidance on when to use it versus alternatives, or when not to use it. However, the purpose is specific enough to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the top tracks tagged with a given tag
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes | Tag name, e.g. 'shoegaze' | |
| page | No | Page number | |
| limit | No | Results per page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic function. It does not disclose pagination, sorting, or any behavioral traits beyond what the schema already offers.
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?
A single sentence that is concise and front-loaded, with no wasted words.
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?
Given the lack of annotations and output schema, the description is too brief. It does not explain important context like required parameters, pagination, or response format.
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 coverage is 100%, and the description adds no extra meaning beyond the schema's own descriptions. Baseline of 3 is appropriate.
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 clearly states the verb 'Get' and the resource 'top tracks' with the scope 'tagged with a given tag'. It effectively distinguishes this tool from siblings like get_tag_top_albums and get_tag_top_artists.
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 implies usage for retrieving top tracks by tag but provides no explicit guidance on when to use or not use this tool versus alternatives like get_chart_top_tracks or get_tag_top_albums.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the list of available weekly chart date ranges for a tag
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes | Tag name, e.g. 'shoegaze' |
Does 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 states the function without disclosing behavioral traits like read-only nature, authentication needs, or error handling for invalid tags.
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?
A single sentence with no redundancy or extraneous words; efficiently communicates the tool's purpose.
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?
For a simple tool with one parameter and no output schema, the description is adequate but lacks detail on the return format (e.g., structure of date ranges). Not incomplete, but not fully informative.
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% with one parameter fully described. The tool description doesn't add additional meaning beyond the schema's example, so baseline 3 applies.
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 clearly states the verb 'get' and the resource 'list of available weekly chart date ranges for a tag', distinguishing it from sibling tools like get_tag_info or get_tag_top_albums.
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 implies usage (when needing date ranges for a tag) but lacks explicit guidance on alternatives or when not to use; no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the top global tags on Last.fm, sorted by popularity
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses basic behavior: it retrieves top global tags sorted by popularity. With no annotations provided, the description carries the full burden, but it lacks details on rate limits, pagination, result size, or output format, making it minimally adequate.
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 sentence that conveys the purpose without any wasted words. It is perfectly concise and front-loaded.
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?
Given no parameters and no output schema, the description provides enough information for a simple list retrieval. It would benefit from mentioning the number of tags returned or any limits, but it is largely complete for its simplicity.
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?
The tool has no parameters, so schema coverage is 100% and the description adds no parameter information. According to guidelines, 0 parameters warrants a baseline of 4, which is appropriate here.
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 clearly states the verb 'Get' and the resource 'top global tags' with sorting by popularity. However, it does not differentiate from the sibling tool 'get_chart_top_tags', which likely has similar functionality, so it falls 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_chart_top_tags' or 'get_tag_info'. The description does not mention context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed info for a track: stats, album, tags, wiki
| Name | Required | Description | Default |
|---|---|---|---|
| mbid | No | MusicBrainz track ID | |
| track | No | Track name (required unless mbid given) | |
| artist | No | Artist name (required unless mbid given) | |
| autocorrect | No | Correct misspelled artist/track names |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It lists categories of returned info but does not explain what 'stats' includes, error behavior, or any read-only guarantee. Adequate but not detailed.
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?
Single sentence that is direct and front-loaded with purpose. No unnecessary words, every part adds value.
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?
Given 4 parameters, no output schema, and a complex domain, the description is too brief. Lacks explanation of parameter interactions, return format, or error handling.
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 coverage is 100%, but description adds no value to parameter understanding beyond listing what info is returned. Doesn't explain autocorrect or interactions between mbid, track, and artist.
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?
Description clearly states verb 'get' and resource 'track', and specifies what info is included (stats, album, tags, wiki). Distinguishes from siblings like get_artist and get_album.
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?
No guidance on when to use this tool vs alternatives like get_similar_tracks or get_track_top_tags. Also no mention of prerequisites (mbid vs track+artist) or when autocorrect is useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the top tags applied to a track
| Name | Required | Description | Default |
|---|---|---|---|
| mbid | No | MusicBrainz track ID | |
| track | No | Track name (required unless mbid given) | |
| artist | No | Artist name (required unless mbid given) | |
| autocorrect | No | Correct misspelled artist/track names |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone must disclose behavior. It only states 'top tags' without explaining how 'top' is determined, what happens if no tags exist, or any limitations. Minimal information beyond the basic operation.
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?
Single sentence, 7 words – very concise. However, it is slightly too minimal; a brief clarification of 'top' would improve without bloating. Still, no wasted words.
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?
Given no output schema and no annotations, the description lacks crucial context: what does the output look like? How many tags? What is 'top' based on? The description is insufficient for an agent to fully understand the tool's behavior.
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%, so parameters are already documented. The description adds no extra meaning about parameter relationships (e.g., mbid vs track+artist), constraints, or formatting. Baseline score of 3 is appropriate.
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 'Get the top tags applied to a track' clearly states the action (Get) and resource (top tags for a track). It distinguishes from sibling tools like get_artist_top_tags or get_album_top_tags by specifying the target entity is a track.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., get_track for general info, get_artist_top_tags for artist tags). Also lacks instructions on how to choose between mbid and track+artist parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a user's Last.fm friends
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| user | No | Last.fm username; defaults to MCP_LASTFM_USERNAME when set, so it can be omitted for your own account | |
| limit | No | Results per page | |
| recenttracks | No | Include each friend's recent listening |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does not state whether the operation is read-only, requires authentication, has rate limits, or pagination behavior. The lack of behavioral disclosure leaves the agent uncertain about side effects.
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 that wastes no words. It is front-loaded with the essential action and resource, making it easy to scan.
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?
Despite 100% schema coverage, the description is too sparse for a tool with no output schema and no annotations. It does not explain the return format, pagination defaults, or how the 'user' parameter defaults to an environment variable, which is critical for correct invocation.
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 coverage is 100%, with all four parameters described in the schema. The description adds no additional parameter meaning beyond what the schema already provides, so it meets the baseline of 3.
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 clearly states the action ('Get') and the resource ('a user's Last.fm friends'). It distinguishes itself from all sibling tools, which cover artists, tracks, tags, and other user data, but none are about friends.
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 among the many siblings. It does not mention prerequisites, default behavior, or cases where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a Last.fm user's profile info
| Name | Required | Description | Default |
|---|---|---|---|
| user | No | Last.fm username; defaults to MCP_LASTFM_USERNAME when set, so it can be omitted for your own account |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It does not mention authentication requirements, error handling (e.g., user not found), response structure, or read-only nature. Only the defaulting behavior is noted.
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, concise sentence that efficiently conveys the tool's purpose. It is front-loaded with the key information, though it could be slightly expanded to include more detail without becoming verbose.
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?
Given the simple tool with one parameter and no output schema, the description is adequate but not fully complete. It would benefit from indicating what fields are returned in the profile info or that the response is a JSON object.
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%, and the description adds meaningful context beyond the schema by explaining the default behavior using the MCP_LASTFM_USERNAME environment variable. This helps the agent understand optionality.
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 clearly states it retrieves a Last.fm user's profile info, using a specific verb-resource pair. It distinguishes from sibling tools like get_user_friends or get_user_loved_tracks by focusing on 'profile info', though it could be more precise about what that includes.
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 schema description provides guidance on when to omit the user parameter (defaults to env variable), which is useful. However, there is no explicit guidance on when to use this tool vs. other user-related tools, nor any exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the tracks a user has loved
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| user | No | Last.fm username; defaults to MCP_LASTFM_USERNAME when set, so it can be omitted for your own account | |
| limit | No | Results per page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It fails to disclose pagination behavior, error handling (e.g., unknown user), or any rate limiting. The description is too sparse for a data retrieval tool.
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?
Extremely concise at 5 words, front-loaded with the key action and resource. No superfluous text, though it borders on under-specification.
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?
Given the 3 parameters and no output schema, the description should cover pagination, authentication context, and what constitutes 'loved' tracks. It does not, leaving the agent with an incomplete picture.
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%, so baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions (e.g., defaults for 'user' are mentioned in the schema, not in the description).
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 clearly states the action ('get') and the resource ('tracks a user has loved'). It distinguishes from siblings like get_user_recent_tracks or get_user_top_tracks by specifying 'loved' tracks.
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?
No guidance on when to use this tool versus alternatives such as get_user_recent_tracks or get_user_top_tracks. The description lacks context on prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get items a user has tagged with a given tag (artists, albums, or tracks)
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes | Tag name, e.g. 'shoegaze' | |
| page | No | Page number | |
| user | No | Last.fm username; defaults to MCP_LASTFM_USERNAME when set, so it can be omitted for your own account | |
| limit | No | Results per page | |
| taggingtype | Yes | Item type to fetch taggings for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read operation but omits details on pagination (page/limit handling), default user behavior, and response format. With no annotations, the burden is on the description, which it fails to meet.
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?
Single sentence, 14 words, efficient and front-loaded. No unnecessary words, but could be slightly expanded without losing conciseness.
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?
With 5 parameters, 2 required, and no output schema, the description is too brief. Missing details on pagination, user context, and response structure, making it incomplete for effective use.
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 coverage is 100%, so baseline is 3. The description adds no extra meaning beyond what the schema provides for parameters like 'tag' and 'taggingtype'. No parameter elaboration.
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 clearly states the tool retrieves items (artists, albums, or tracks) tagged by a user with a specific tag. It aligns with the 'taggingtype' enum and distinguishes from sibling tools like 'get_tag_top_artists' and 'get_user_top_tags', though not explicitly.
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?
No guidance on when to use this tool vs alternatives like 'get_tag_top_artists' or 'get_user_top_tags'. Lacks context on prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a user's recent scrobbles, including the currently playing track
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Unix timestamp — only scrobbles before this | |
| from | No | Unix timestamp — only scrobbles after this | |
| page | No | Page number | |
| user | No | Last.fm username; defaults to MCP_LASTFM_USERNAME when set, so it can be omitted for your own account | |
| limit | No | Results per page | |
| extended | No | Include extended artist/loved data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It mentions including the currently playing track, but lacks details on pagination behavior, authentication requirements, or rate limits. The parameter schema covers pagination, but the description does not add context.
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, front-loaded sentence with no extraneous information. Every word contributes to clarity.
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?
Without an output schema, the description should explain the return structure. It does not describe what the response contains (e.g., track list, metadata, or how to interpret the currently playing track). The tool has 6 parameters and no output schema, leaving significant gaps for an agent.
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%, so the schema already documents all parameters. The tool description does not add any additional meaning beyond the schema descriptions, meeting the baseline of 3.
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 clearly states the tool gets a user's recent scrobbles, including the currently playing track. It distinguishes from sibling tools like get_user_loved_tracks or get_user_top_tracks by specifying 'recent scrobbles'.
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?
No guidance on when to use this tool versus alternatives. The description does not mention when to use other user-specific track tools, such as get_user_loved_tracks or get_user_top_tracks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a user's most-played albums over a time period
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| user | No | Last.fm username; defaults to MCP_LASTFM_USERNAME when set, so it can be omitted for your own account | |
| limit | No | Results per page | |
| period | No | Time range for aggregated stats | overall |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits such as read-only nature, rate limits, pagination, error handling, or ordering. Given the lack of annotations, the description carries full burden but is insufficient.
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?
Single sentence of 8 words, front-loaded with essential information. No redundancy; every word contributes to clarity.
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?
Given no output schema and no annotations, the description should provide more context about pagination, default behavior, and response structure. It is adequate for a simple tool but leaves gaps.
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%, so baseline is 3. The description adds no additional meaning beyond the schema; it does not explain parameter interdependence or special behaviors. Adequate but no extra value.
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 clearly states the action ('Get'), the resource ('user's most-played albums'), and the scope ('over a time period'). It effectively distinguishes from sibling tools like 'get_user_top_artists' or 'get_user_top_tracks'.
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 implies usage when needing top albums, but provides no explicit guidance on when to use this tool versus alternatives, nor any when-not scenarios. With many sibling tools, explicit guidelines would improve usability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a user's most-played artists over a time period
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| user | No | Last.fm username; defaults to MCP_LASTFM_USERNAME when set, so it can be omitted for your own account | |
| limit | No | Results per page | |
| period | No | Time range for aggregated stats | overall |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the basic operation, omitting behavioral traits like read-only status, authentication requirements, or rate limits. While the name 'get' implies a read operation, more explicit disclosure is needed.
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?
A single sentence efficiently conveys the tool's purpose with no redundant information. However, it is overly brief, lacking any structuring or use of front-loading to highlight key information.
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 description is minimal and adequate for a simple retrieval tool, but it does not explain output format, pagination behavior, or ordering of results. Given the absence of an output schema, more context would be beneficial for effective use.
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 coverage is 100% with all parameters described in the schema. The tool description adds no additional meaning beyond the schema's parameter descriptions, so baseline score of 3 is appropriate.
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?
Description clearly states 'Get a user's most-played artists over a time period', specifying the verb (Get), resource (user's top artists), and scope (over a time period). This distinguishes it from sibling tools like get_user_top_albums or get_user_top_tracks.
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?
No guidance on when to use this tool versus alternatives such as get_user_top_albums or get_user_top_tracks. The description simply states what it does, without providing context for selection criteria or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the tags a user applies most often
| Name | Required | Description | Default |
|---|---|---|---|
| user | No | Last.fm username; defaults to MCP_LASTFM_USERNAME when set, so it can be omitted for your own account | |
| limit | No | Results per page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; the description carries full burden. It does not disclose what 'most often' means (e.g., frequency vs. recency), ordering, or authentication requirements. The minimal description leaves agent uncertainty.
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 short sentence, which is concise but does not earn its place by adding value beyond the name. It lacks structure and key details.
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?
No output schema, so description should explain return format (e.g., list of tags with counts). It does not. Also fails to mention prerequisites like public user data, making it incomplete for accurate agent use.
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 coverage is 100% (both parameters have descriptions). The tool description adds no additional parameter context beyond the schema, so baseline score 3 is appropriate.
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 clearly states the verb ('get') and resource ('tags a user applies most often'). It distinguishes from global top tags and tag-specific tools, but could be more explicit about the user-specific scope compared to similar user tag tools.
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?
No guidelines on when to use this tool versus alternatives like get_top_tags or get_user_personal_tags. No exclusions or prerequisites mentioned, which is a gap given the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a user's most-played tracks over a time period
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| user | No | Last.fm username; defaults to MCP_LASTFM_USERNAME when set, so it can be omitted for your own account | |
| limit | No | Results per page | |
| period | No | Time range for aggregated stats | overall |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states 'most-played tracks over a time period' without explaining return format (e.g., list of tracks with playcounts), pagination behavior, aggregation details, or authentication needs. The agent lacks critical context for safe invocation.
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?
A single sentence with no redundancy or extraneous information. It is front-loaded with the core action and resource.
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?
Given the tool has 4 parameters, no output schema, and no annotations, the description is too brief. It fails to explain the return values, pagination mechanics, or how the 'most-played' metric is computed. More detail is needed for a tool in a domain with many similar siblings.
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 coverage is 100% with descriptions for all 4 parameters. The description adds marginal value by confirming the 'period' parameter corresponds to 'time period', but does not provide additional syntax or format hints beyond the schema. Baseline 3 is appropriate.
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 clearly states the verb 'get', the resource 'user's most-played tracks', and the context 'over a time period'. It effectively differentiates from sibling tools like get_user_recent_tracks (recent, not most-played) and get_user_top_artists/albums (different resource type).
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?
No explicit guidance on when to use this tool versus alternatives. While the description implies it's for most-played tracks over a period, it doesn't mention exclusions (e.g., not for recent tracks or weekly charts) or suggest when to prefer siblings like get_user_recent_tracks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a user's album chart for a given week (or the latest)
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Unix timestamp — chart range end | |
| from | No | Unix timestamp — chart range start | |
| user | No | Last.fm username; defaults to MCP_LASTFM_USERNAME when set, so it can be omitted for your own account |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies optional timestamps but does not disclose authentication needs, privacy restrictions, or output format. Minimal behavioral context beyond the basic purpose.
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?
Single sentence, front-loaded key information, no wasted words. Efficient and to the point.
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?
Adequate for a simple chart retrieval tool, but lacks details on what the chart contains, timestamp handling, and account prerequisites. With no output schema, more context would be helpful.
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 covers 100% of parameters with descriptions. The description adds no extra 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('a user's album chart'), and the temporal scope ('for a given week (or the latest)'). It distinguishes from sibling tools like get_user_weekly_artist_chart by specifying 'album'.
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?
No guidance on when to use this tool versus alternatives. Does not explain when 'or the latest' applies, or how it differs from other weekly chart tools (e.g., get_user_weekly_chart_list).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a user's artist chart for a given week (or the latest)
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Unix timestamp — chart range end | |
| from | No | Unix timestamp — chart range start | |
| user | No | Last.fm username; defaults to MCP_LASTFM_USERNAME when set, so it can be omitted for your own account |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full behavioral burden. It only discloses that omitting from/to yields the latest chart, but fails to mention ordering, limits, error conditions, or return format. The schema descriptions for from/to already cover their meaning, so the description adds minimal value.
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, front-loaded sentence of 14 words with no unnecessary words. It efficiently conveys the core purpose and the default behavior. Could be slightly more structured, but it is appropriately concise for a simple tool.
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?
Given no output schema, the description should at least mention the return type (e.g., list of artists with play counts). It does not explain what constitutes an 'artist chart' or any pagination. For a chart tool, this missing information reduces completeness.
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 coverage is 100%, so baseline is 3. The description adds 'for a given week (or the latest)', which complements the from/to parameters but does not add significant new meaning beyond what the schema descriptions already provide. No additional usage details are given.
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 clearly states the verb 'Get' and resource 'user's artist chart', and adds nuance with 'for a given week (or the latest)'. It clearly differentiates from sibling tools like get_user_weekly_album_chart by specifying 'artist chart', though it does not explicitly contrast them.
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 (e.g., get_user_weekly_album_chart, get_user_weekly_track_chart). There is no mention of prerequisites or when not to use it, leaving the agent to infer from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the list of available weekly chart date ranges for a user
| Name | Required | Description | Default |
|---|---|---|---|
| user | No | Last.fm username; defaults to MCP_LASTFM_USERNAME when set, so it can be omitted for your own account |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It omits behavioral traits such as authentication requirements, rate limits, or that it is a read operation. For a simple tool, this is a minimal disclosure.
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?
A single sentence that directly states the tool's purpose with no extraneous words. Perfectly concise and front-loaded.
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?
Given the tool's simplicity (1 optional param, no output schema) and the context of sibling tools, the description is adequate. It hints at output structure ('list of available weekly chart date ranges'), which is sufficient for the agent to understand its role.
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 coverage is 100%, with the 'user' parameter described in the schema. The description adds no further value beyond the schema's description, so the baseline score of 3 is appropriate.
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 clearly states the action 'Get' and the resource 'list of available weekly chart date ranges for a user'. It effectively distinguishes this tool from siblings like get_user_weekly_album_chart, which retrieve actual chart data, by focusing on listing date ranges.
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?
While the description implies usage before fetching weekly charts, it lacks explicit guidance on when to use this tool versus alternatives (e.g., get_tag_weekly_chart_list). No when-not-to-use or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a user's track chart for a given week (or the latest)
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Unix timestamp — chart range end | |
| from | No | Unix timestamp — chart range start | |
| user | No | Last.fm username; defaults to MCP_LASTFM_USERNAME when set, so it can be omitted for your own account |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It only says 'Get a user's track chart', which is too vague. It does not mention whether the tool is read-only, if it requires authentication, how the chart is sorted, what the maximum number of tracks is, or how the week is defined. This lack of detail misleads the agent about potential side effects or constraints.
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 very concise with a single sentence that states the core functionality. There is no wasted wording. However, it is too brief to contain necessary behavioral or usage information, which slightly reduces its effectiveness.
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?
Given the tool's moderate complexity (three parameters, no output schema, no annotations), the description is incomplete. It fails to explain what the chart output looks like, whether pagination is supported, what the default week is, or any limits. Without these details, an AI agent may generate incorrect calls.
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?
The schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description adds no additional context to the parameters; it does not explain how the timestamps relate to the week or how the 'user' parameter defaults. Since the schema already handles parameter documentation, a score of 3 is appropriate.
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 clearly states the verb 'get' and the resource 'user's track chart for a given week'. It specifies the time scope ('for a given week (or the latest)'). However, it does not differentiate from sibling tools like get_user_weekly_album_chart or get_user_weekly_artist_chart, which perform similar functions for different chart types.
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?
No guidance is provided on when to use this tool versus its siblings or other tools. There is no discussion of prerequisites, such as requiring the user to exist or the need for authentication. The description solely states what it does, not when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for albums by name
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| album | Yes | Album name to search for | |
| limit | No | Results per page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only states the basic function. It does not mention pagination behavior, case sensitivity, wildcard support, or any side effects. The schema parameters hint at pagination, but the description adds no clarity.
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 concise sentence, front-loading the core purpose. It is appropriately sized but could include slightly more detail without becoming verbose.
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?
Given the 3 parameters and no output schema, the description is incomplete. It does not explain how search results are returned, pagination behavior, or any limitations. For a search tool, this is insufficient.
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%, so the baseline is 3. The description adds no additional meaning beyond the schema for the 'album' parameter; it only restates that search is by name. The 'page' and 'limit' parameters are not mentioned in the description.
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 clearly states the action ('Search') and the resource ('albums') with a specific filter condition ('by name'). This distinguishes it from sibling tools like search_artists and search_tracks.
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 or search_artists. No exclusions, prerequisites, or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for artists by name
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| limit | No | Results per page | |
| artist | Yes | Artist name to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavioral traits like pagination behavior, rate limits, or that it returns a list. Only the parameter names hint at pagination but no explicit statement.
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 concise sentence, but it is too minimal. It could include key details without being verbose, e.g., mention that results are paginated.
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?
No output schema and no description of return format. For a search tool, the return structure (e.g., list of artists with metadata) is important context not provided.
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 coverage is 100% and parameters are well-described in the schema. The description adds no extra meaning beyond what the schema already provides.
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 clearly states the verb 'Search' and the resource 'artists by name', differentiating it from sibling tools like get_artist and search_albums.
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?
No guidance on when to use this tool versus alternatives such as get_artist (specific artist) or search_albums. Misses opportunity to clarify scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for tracks by name, optionally narrowed by artist
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| limit | No | Results per page | |
| track | Yes | Track name to search for | |
| artist | No | Narrow results to this artist |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the search action but does not mention whether the operation is read-only, any side effects, or pagination behavior beyond what the schema already provides. This is insufficient for a search tool.
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 efficient sentence of 10 words, achieving maximal conciseness. However, it could be slightly more structured by front-loading the key action and including a brief note on pagination without adding clutter. Still, no wasted words.
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?
Given the tool has 4 parameters, no output schema, and no annotations, the description is incomplete. It fails to mention pagination behavior, default values, or the return format (e.g., a list of matching tracks). This lack of context could hamper correct usage, especially for an agent.
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%, so the baseline is 3. The description adds value by linking 'by name' to the track parameter and 'narrowed by artist' to the artist parameter. However, it does not explain the page and limit parameters beyond the schema, so it does not exceed the baseline.
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 uses the specific verb 'Search' with resource 'tracks' and clarifies the optional narrowing by artist. It clearly distinguishes from sibling tools like search_albums and search_artists by specifying 'tracks', making the tool's purpose unambiguous.
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 does not provide any usage context, such as when to use this tool versus alternatives like get_track or get_artist_top_tracks. No explicit when/when-not guidance is given, leaving the agent to infer the appropriate scenario from the brief statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0correct_artistcorrect_trackget_albumget_album_top_tagsget_artistget_artist_top_albumsget_artist_top_tagsget_artist_top_tracksget_chart_top_artistsget_chart_top_tagsget_chart_top_tracksget_geo_top_artistsget_geo_top_tracksget_library_artistsget_similar_artistsget_similar_tagsget_similar_tracksget_tag_infoget_tag_top_albumsget_tag_top_artistsget_tag_top_tracksget_tag_weekly_chart_listget_top_tagsget_trackget_track_top_tagsget_user_friendsget_user_infoget_user_loved_tracksget_user_personal_tagsget_user_recent_tracksget_user_top_albumsget_user_top_artistsget_user_top_tagsget_user_top_tracksget_user_weekly_album_chartget_user_weekly_artist_chartget_user_weekly_chart_listget_user_weekly_track_chartsearch_albumssearch_artistssearch_tracksScored across 41 tools
Each tool targets a distinct resource and action (e.g., get_artist vs get_artist_top_albums). Even tools that seem similar like get_tag_top_albums and get_album_top_tags are clearly inverses with different inputs and outputs, leaving no ambiguity.
All tool names follow a verb_noun pattern using snake_case (correct_, get_, search_). The naming is predictable, making it easy for an agent to infer functionality from the name.
41 tools is high but justified by the broad Last.fm API domain (artists, albums, tracks, tags, users, charts, geo). The count is within the upper bound of a well-scoped set; it covers essential endpoints without being excessive.
The tool set provides thorough read coverage of Last.fm data: artists, albums, tracks, tags, users, charts, and search. Minor gaps like missing artist events or user library management are acceptable for a read-only server, and core workflows are complete.
Last.fm artist/album/track metadata (free API key required)
Search MusicBrainz artists, releases, works, labels; resolve ISRC/ISWC/barcode; fetch cover art.
Full Spotify Web API coverage - albums, artists, playlists, player controls, and more.
Deezer public music catalog (search/tracks/albums/artists/charts)