Skip to main content
Glama

Piano: scales, chords, keyboard sizes and practice plans

learn_piano
Read-only

Spells any scale or chord with its correct note names, inversions and fingering (scale fingering from Hanon, 1873), draws it on a text keyboard, gives the key range of each keyboard size from 25 to 88 keys, and builds a practice plan for a level, goal and number of minutes. Each answer links to the Divux Piano page with that scale, chord or plan loaded for practice with a MIDI or on-screen keyboard. Applies to piano and keyboard theory, fingering, keyboard sizes and practice routines.

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": "learn_piano"
  }
}

Input Schema

NameRequiredDescriptionDefault
goalNoFor a plan
keysNoKeyboard size: 25, 32, 37, 49, 61, 73, 76 or 88
kindNoWhat to answer; worked out from the other fields when left out
noteNoScale tonic or chord root, e.g. 'C', 'F#', 'Bb', 'Eb3'
chordNoA chord symbol, e.g. 'Am7', 'F#m/A', 'Bbmaj7', 'Gsus4'
levelNoFor a plan
minutesNoFor a plan: minutes a day, default 15
inversionNo0 root position, 1 first inversion, 2 second, 3 third
scale_typeNomajor, natural minor, harmonic minor, melodic minor, dorian, phrygian, lydian, mixolydian, locrian, major pentatonic, minor pentatonic, blues or chromatic
chord_qualityNomajor, minor, diminished, augmented, sus2, sus4, dom7, maj7, min7, half_dim7, dim7, six, min6, add9 or dom9

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare a safe read-only, closed-world operation, so the bar is lower. The description still adds real context beyond them: it cites the fingering source (Hanon, 1873), states the keyboard-size range boundary (25 to 88), and discloses that every answer links to a Divux Piano page preloaded for MIDI or on-screen practice — output behavior that matters since no output schema exists.

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?

Three sentences, front-loaded with the core capability and then the output/link behavior, with no filler. The closing scope sentence partially restates the first sentence, which is the only redundancy.

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

Completeness4/5

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

With ten all-optional parameters, no required fields and no output schema, the description does the important work of explaining what an answer contains and that kind is resolved from the other fields. What is missing is explicit guidance on the default path when no inputs are supplied, but the definition is otherwise complete for this tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with descriptions and enums on all ten optional parameters, so the schema already carries parameter meaning. The description reinforces a few (level, goal, minutes for a plan; key sizes) but adds no new format or interaction semantics, so baseline 3 applies.

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

Purpose5/5

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

The description names concrete verbs and resources across every mode: spelling scales/chords with note names, inversions and fingering, drawing on a text keyboard, reporting key ranges for 25–88 key instruments, and building practice plans. The final sentence scopes the domain (piano/keyboard theory, fingering, sizes, routines), which is enough to separate it from the unrelated check_*/plan_* siblings.

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

Usage Guidelines3/5

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

Usage is only implied: the closing sentence says what domain it applies to, and the description implies that supplying a note/chord/keys value selects the relevant answer. There is no explicit 'use this when' or any exclusion or alternative routing, so the agent must infer selection from the field set.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources