Skip to main content
Glama
netease-music-mcp
by xinyu68

netease_launch

Prepare the standalone playback engine to enable NetEase Music playback and control without launching the desktop client.

Instructions

准备独立播放引擎,不启动网易云桌面客户端

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "netease_launch"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

B3.2/5.0
Behavior3/5

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

Annotations declare readOnlyHint=false and openWorldHint=true, so the agent already knows this mutates/affects external state; the description usefully adds that the desktop client is not launched, clarifying the side-effect boundary. However, it says nothing about idempotency, whether the engine stays running after preparation, or what happens if it is called again — relevant for a non-read-only setup call.

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?

A single short clause carrying the positive action first and the exclusion second — no filler. It is arguably under-sized rather than verbose, but structure and ordering are sound.

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

Completeness2/5

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

For a zero-param, non-read-only initialization tool with no output schema, the description should say what state the system is in afterward and whether callers must invoke it before other playback tools. Neither is covered, leaving the agent unsure how this fits into the playback lifecycle.

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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate and it correctly avoids inventing argument detail.

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

Purpose4/5

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

States a specific action (准备/prepare) on a specific resource (独立播放引擎/standalone playback engine) and adds a scope negation: it does not start the desktop client. That distinguishes it from 'launching an app', but it does not distinguish it from siblings like netease_play or netease_status, which an agent could easily confuse it with.

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

Usage Guidelines2/5

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

No indication of when this should be called — is it a mandatory prerequisite before netease_play, a one-time setup, or optional? The only guidance offered is the negative statement that it does not start the desktop client, which is a scope note rather than usage direction.

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