crates-music-mcp

Overview Schema Source Related Servers Discussions Admin

recent_played

Fetches your recently played songs from NetEase Cloud Music or Kugou to seed a new playlist; returns song names, artists, and play details.

Instructions

某个平台你自己最近听过的歌（听歌排行），不是我们推荐过的歌。

service: qq_music | netease | kugou（QQ 暂不支持，会返回 supported=false） limit: 取多少首（默认 50） Returns {"ok","service","count","songs":[{"name","artist"}],"details", "diagnostics"}；details 里带 play_count（网易云）/ played_at（酷狗）。用途：拿它当"种子"——先看用户最近在听什么，再据此建一张新歌单。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "service": "<service>"
    },
    "name": "recent_played"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No
`service`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.1Nov 9, 2026

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations, the description carries the full burden and does add real detail: QQ is unsupported and returns supported=false, and per-platform details fields (play_count for NetEase, played_at for Kugou) are named. It omits credential/auth prerequisites and any error or empty-result behavior, which matters for a cross-platform read tool.

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

Conciseness5/5

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

Front-loads the key distinction in the first line, then uses tight labeled lines for service/limit, return shape, and purpose. No filler sentences; the one repeated element (return fields) is compensated by the platform-specific details annotation.

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

Completeness4/5

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

An output schema exists, so the return-value description is optional extra rather than a gap-filler. Combined with the platform caveat and default, the definition is sufficient to call correctly; only auth/error behavior is unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate — and it does: it enumerates service values, flags the qq_music caveat, and states the limit default of 50. It adds meaning beyond the raw schema by explaining that QQ will report supported=false rather than fail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource — the user's own recently played tracks (listening ranking) for a given platform — and explicitly excludes recommendation history ("不是我们推荐过的歌"). That contrast makes it distinguishable from the recommended-tracks family without opening any schema.

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

Usage Guidelines4/5

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

It gives an explicit intended use ("拿它当种子" — inspect recent listening, then build a new playlist) and rules out the recommendation tools. It stops short of stating when-not to call it (e.g. when the user has no history, or prefer recent_tracks/qq_recent for other platforms).

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