Skip to main content
Glama
Sign In
netease-music-mcp

netease-music-mcp

by xinyu68
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

netease_volume

Set the music player volume from 0 to 100 and persist it for restart or upgrade recovery without changing the system master volume; save failures return explicit errors.

Instructions

按用户明确目标设置播放器音量0到100，成功后保存供重启或升级恢复；不改变系统主音量，保存失败会明确报错

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": {
      "volume": "<volume>",
      "requestId": "<requestId>"
    },
    "name": "netease_volume"
  }
}

Input Schema

NameRequiredDescriptionDefault
volumeYes
requestIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the annotations, the description discloses key behavior: the setting is persisted for restore after restart or upgrade, system master volume is unaffected, and save failure raises an explicit error. These are concrete side effects and failure semantics that the annotations do not provide.

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

Conciseness4/5

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

The description is a single front-loaded sentence with semicolon-delimited clauses, each adding useful information about action, persistence, system-volume boundary, and failure behavior. It is dense but not wasteful.

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

Completeness3/5

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

The description covers the main behavioral traits well, but for a two-parameter mutation tool it leaves the required requestId semantics completely undefined. Since there is no output schema, return values need not be explained, but the parameter gap keeps it at adequate rather than complete.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It repeats the volume range already given in the schema and says nothing about the required requestId parameter, leaving half of the parameters unexplained.

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: set the player volume from 0 to 100. It also explicitly distinguishes this from system master volume, so an agent can tell exactly what this tool affects.

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?

The phrase '按用户明确目标' signals that this should be used only when the user explicitly wants a volume change, which is a clear usage cue. The boundary '不改变系统主音量' also tells the agent what this tool is not for, though it does not name sibling alternatives (none exist for volume).

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

Deploy Server

Other Tools