Lists every Insert command SONAR exposes with its ID so agents can find the right command for cw_run_command when track actions do not cover needs like a track template.
Every 插入 (Insert) command SONAR exposes, with its id. Reference for cw_run_command when you need something cw_add_track does not cover, e.g. a track template.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It implies a safe read-only lookup and that entries carry ids, but says nothing about the return shape beyond 'with its id' — no mention of how many commands, whether they are grouped, or what the id format looks like for passing to cw_run_command.
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?
Two sentences, front-loaded with what the tool returns, followed by the routing condition. Zero filler and no repetition of the tool name.
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?
There is no output schema and no annotations, and the description only loosely sketches the return value ('with its id'). For a zero-parameter reference-list tool this is close to sufficient, but it should say what a returned entry contains and how the id plugs into cw_run_command.
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 takes zero parameters and the schema has 100% coverage with an empty properties object, so there is nothing the description needs to disambiguate. Baseline 4 applies; no parameter-level guidance is required or missing.
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?
States a specific resource and scope: 'Every 插入 (Insert) command SONAR exposes, with its id' — a scoped command reference rather than a general list. It does not name the nearest ambiguous sibling (cw_list_commands), so an agent must infer that this is the Insert-filtered subset, but the scope wording makes the distinction reasonably clear.
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?
Explicitly routes usage: 'Reference for cw_run_command when you need something cw_add_track does not cover, e.g. a track template.' This names the downstream consumer and the fallback trigger, implying the negative case (if cw_add_track suffices, skip this). It omits any comparison to cw_list_commands / cw_view_commands, which is the one real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.