Convert a musical note name such as C4 or A#3 into its MIDI key number for precise note placement in music projects.
Convert a note name (e.g. 'C4') to its MIDI key number.
Args: name: Note name like 'C4', 'A#3', 'F#5', 'Bb2'
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the core conversion behavior and gives representative note-name formats, but it does not specify the octave convention (e.g., which MIDI number C4 maps to), invalid-input behavior, or case sensitivity. This is adequate for a pure conversion, but not rich.
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?
The definition is a single terse sentence plus an example line, with no filler. The core transformation is front-loaded, and the examples make the expected input format immediately usable.
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?
For a single-parameter conversion utility with an output schema available, the description covers the necessary input format and purpose. The main omissions are explicit routing to the inverse sibling and edge-case behavior, which keep it from being fully complete.
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?
Schema description coverage is 0%, and the description compensates by explaining the 'name' parameter and providing examples that include sharps and flats ('A#3', 'Bb2'). It adds significant meaning beyond the bare string type, though it stops short of a complete syntax or validation pattern.
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?
The description uses a specific verb, 'Convert,' and defines the exact transformation from a note name to a MIDI key number, with concrete examples such as 'C4' and 'A#3'. The directional wording clearly distinguishes it from the inverse sibling tool key_to_note_name.
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?
The description implies when to use the tool (when a note name must become a MIDI key number), but it does not explicitly mention alternatives or when to prefer other tools. There is no exclusion guidance such as 'use key_to_note_name for the reverse direction.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.