Skip to main content
Glama
wushiray

cakewalkmcp

by wushiray
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

cw_verify_commands

Probes a running SONAR build to re-measure which command IDs are active versus inert, refreshing the working command split after a SONAR update. Splits results into probed and notProbed.

Instructions

Re-measure which command ids do something on the running SONAR, by posting each and watching the window list. Use after a SONAR update to refresh the working/inert split. Defaults to the two safe view commands when a project is open; nothing without a project. Only a fixed view/dialog allowlist is probed, even for explicit ids. A modal stops the survey and is left open. No insert, recording, mute, solo or document lifecycle probes. Cost, measured: each probe takes about 15s (two bridge round trips plus a settle delay), so the full 21-command survey is roughly five minutes and NO budget makes it quick — a short budget buys one or two probes, which is a much weaker claim than a complete survey. probed says how many were actually measured; give it time if you want the measurement.

Input Schema

NameRequiredDescriptionDefault
cmdIdsNoIds from the safe view/dialog allowlist; other ids are reported as notProbed
budgetMsNoCap the survey. At ~15s per probe this buys about one probe; the default is a bound for a caller who wants a sample, not a useful survey. Allow ~300000 for all 21.
backgroundNoReturn a job id immediately and run the survey in the background; poll cw_job

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.3/5.0
Behavior5/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 so well: it discloses that commands are posted, a modal stops the survey and is left open, only a fixed view/dialog allowlist is probed, and no insert/record/mute/solo/document-lifecycle probes occur. It also explains the measured cost per probe, the effect of a short budget, and that `probed` reports how many commands were actually measured.

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 front-loaded with purpose, then proceeds to usage, safety constraints, and cost. It is somewhat long and repeats the budget/cost warning, but the repetition serves an important caveat rather than adding empty prose.

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

Completeness5/5

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

This is a complex, multi-step probing tool with no output schema, yet the description covers purpose, when to use it, safety boundaries, side effects, cost, budget behavior, and how to interpret `probed`. An agent has enough context to call it correctly and understand the trade-offs.

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 description coverage is 100%, so the baseline is 3, but the description adds meaningful semantics: explicit `cmdIds` are still limited to the safe allowlist, and `budgetMs` is framed against the ~15s-per-probe cost and the weakness of a short sample. It does not add detail on `background`, but the schema already documents that well.

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?

The first sentence gives a specific verb and resource: re-measuring which command ids do something on the running SONAR by posting each and watching the window list. It clearly explains the working/inert split, but it does not explicitly distinguish itself from nearby siblings such as cw_command_support or cw_command_evidence.

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 states a clear triggering context: use after a SONAR update to refresh the working/inert split. It also sets boundary conditions such as defaulting to two safe view commands only when a project is open, and doing nothing otherwise, but it does not name alternative tools for related needs.

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