Skip to main content
Glama

cw_edit_help

Explains Cakewalk editing commands, their preconditions and dialogs, and diagnoses why a probe reports nothing happened using a three-cause taxonomy.

Instructions

The editing layer: the commands, their preconditions, the dialogs behind them, and the three-cause taxonomy for "a probe reported nothing happened".

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations at all, the description carries the full burden and does not disclose that the call is a side-effect-free documentation read, that it returns prose rather than state, or how large the payload is. It hints at internal structure (three-cause taxonomy) which is useful, but the safety/return profile is entirely unstated.

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 compact sentence with no filler. However it opens with an abstract nominal phrase ('The editing layer:') rather than a front-loaded statement of what the tool does, so the most useful information arrives somewhat indirectly.

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 low-complexity shape (no params, no output schema) limits what is required, and enumerating the topics covered is a real contribution. Still missing are the two facts an agent most needs: that this returns documentation and is safe to call, and how it relates to cw_edit and cw_no_effect_causes.

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?

Zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate. No parameter text is needed or expected here.

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

Purpose3/5

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

The description names the subject matter (the editing layer, its commands, preconditions, dialogs, and a failure taxonomy) but never uses a verb or states that this is a documentation/help endpoint that returns reference material rather than performing edits. It contrasts implicitly with the sibling cw_edit (which does the editing), but the 'three-cause taxonomy' overlap with cw_no_effect_causes is not addressed. An agent can guess the topic but not the action.

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?

There is no statement of when to call this versus cw_edit, cw_note_edit_help, cw_cal_help, or cw_no_effect_causes, and no prerequisite or sequencing guidance. The reader must infer that this is a 'read the manual first' tool from the name alone.

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