Make a guitar chord chart printable in seconds: send a list of chords or paste a song with chords.
Score is being calculated.
Use this when the user asks how to play a chord on guitar, ukulele or piano ("how do I play F#m7b5 on ukulele", "easier way to play F"). Pass the chord names in chords. Returns up to 4 positions per chord (default 3), lowest on the neck first, with the frets, finger numbers and the note on each string, checked note by note, plus a PDF of the diagrams. For a whole song sheet use generate_chord_chart. Does not do alternate tunings or bass.
| Name | Required | Description | Default |
|---|---|---|---|
| capo | No | Guitar or ukulele capo fret 0-9, or "auto" for the easiest open shapes. Default 0. | |
| paper | No | letter (US Letter, default) or a4. | |
| title | No | Heading printed on the sheet, e.g. the song name "Wonderwall" or "Beginner chords". Default "Chord chart". | |
| chords | No | Chord names, one per item, e.g. ["G", "Em", "C", "D7", "F#m7b5", "C/E"]. Convert a pasted song or a photo of a chord sheet into this list of the chords it uses. Repeats are drawn once. Up to 64 different chords. | |
| capo_mode | No | How chord names relate to the capo: "shapes" (default with a capo number) means the names are the shapes you finger, as chord sheets that say "Capo 2" write them; each diagram says which chord sounds. "sounding" means the names are the chords that should sound, and the tool finds the shapes to play with the capo (used for capo "auto"). | |
| instrument | No | guitar (standard tuning E A D G B E, default), ukulele (G C E A) or piano (keyboard diagrams). Several, e.g. "guitar and ukulele", give one PDF with each instrument on its own pages. | |
| left_handed | No | true for mirrored left-handed diagrams (low string on the right). Default false. | |
| shapes_per_chord | No | Positions per chord, 1 to 4 (default 3). |
| Name | Required | Description |
|---|---|---|
| capo | Yes | |
| notes | Yes | |
| pages | Yes | |
| paper | Yes | |
| title | Yes | |
| tuning | Yes | |
| skipped | Yes | |
| diagrams | Yes | |
| per_page | Yes | |
| downloads | Yes | |
| instrument | Yes | |
| chord_count | Yes | |
| left_handed | Yes | |
| diagram_count | Yes | |
| diagrams_shown | No | |
| transpose_semitones | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description goes beyond them by describing the result: up to 4 positions per chord (default 3), ordered lowest on the neck first, with frets, finger numbers and per-string notes, plus a PDF. It does not mention limits such as the 64-distinct-chord cap, but that is a minor gap against an otherwise rich behavioral picture.
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?
Three sentences, each earning its place: trigger, invocation and return shape, then the sibling and exclusions. Trigger guidance and the sibling routing are front-loaded rather than buried.
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 an eight-parameter tool with a full schema and an output schema, the description supplies everything the schema cannot: the user-intent trigger, ordering of results, the PDF artifact, the sibling boundary and the out-of-scope cases. Nothing an agent needs in order to call it correctly is missing.
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 100%, so the baseline is 3. The description only adds that chord names go in the 'chords' parameter and that shapes per chord defaults to 3; it says nothing about capo, capo_mode, instrument variants or left_handed, which the schema already covers in detail.
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 first sentence gives a specific verb and resource ('how to play a chord') and names the supported instruments (guitar, ukulele, piano). The sibling tool generate_chord_chart is named explicitly, so an agent can route between them without opening either schema.
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?
It states exactly when to use it, with two concrete example user phrasings, and names the alternative ('For a whole song sheet use generate_chord_chart'). It also states exclusions ('Does not do alternate tunings or bass'), which is rare and useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants a guitar chord chart printable, a ukulele chord chart, a piano chord chart, or chord diagrams for a song. Convert a pasted song or an uploaded photo of a chord sheet into the chords list (chord names like G, Em, F#m7, C/E); use chord_sheet only to pass raw pasted text. Draws one diagram per different chord as a print-ready PDF (US Letter or A4, 6, 12 or 24 per page) for guitar in standard tuning, ukulele (G C E A) or piano, with optional transpose, capo (or "auto"), and left-handed diagrams. Guitar and ukulele shapes are checked by their notes. Does not do alternate tunings, bass, tabs or notation.
| Name | Required | Description | Default |
|---|---|---|---|
| capo | No | Guitar or ukulele capo fret 0-9, or "auto" to pick the capo with the easiest open shapes. Default 0. A "Capo 2" line in chord_sheet is read too. | |
| paper | No | letter (US Letter, default) or a4. | |
| title | No | Heading printed on the sheet, e.g. the song name "Wonderwall" or "Beginner chords". Default "Chord chart". | |
| chords | No | Chord names, one per item, e.g. ["G", "Em", "C", "D7", "F#m7b5", "C/E"]. Convert a pasted song or a photo of a chord sheet into this list of the chords it uses. Repeats are drawn once. Up to 64 different chords. | |
| to_key | No | Transpose to this key instead of giving semitones, e.g. G or Bbm. The original key is from_key, a Key: line in the sheet, or the first chord. | |
| from_key | No | The song's current key when to_key is used, e.g. E. Optional. | |
| per_page | No | Diagrams per page: 6, 12 (default) or 24. | |
| capo_mode | No | How chord names relate to the capo: "shapes" (default with a capo number) means the names are the shapes you finger, as chord sheets that say "Capo 2" write them; each diagram says which chord sounds. "sounding" means the names are the chords that should sound, and the tool finds the shapes to play with the capo (used for capo "auto"). | |
| instrument | No | guitar (standard tuning E A D G B E, default), ukulele (G C E A) or piano (keyboard diagrams). Several, e.g. "guitar and ukulele", give one PDF with each instrument on its own pages. | |
| chord_sheet | No | Fallback: a pasted chord sheet (chords over lyrics, or inline [Am] chords). Every chord in it is drawn once, in order of first use. Example: "G Em\nHello my friend\nC D\nHow are you". | |
| left_handed | No | true for mirrored left-handed diagrams (low string on the right). Default false. | |
| shapes_per_chord | No | How many positions to draw per chord, 1 (default) to 4, lowest on the neck first. | |
| show_finger_numbers | No | Print finger numbers in the dots (default true). | |
| transpose_semitones | No | Shift every chord up (positive) or down (negative) by this many semitones before drawing, e.g. 2 or -3. Default 0. |
| Name | Required | Description |
|---|---|---|
| capo | Yes | |
| notes | Yes | |
| pages | Yes | |
| paper | Yes | |
| title | Yes | |
| tuning | Yes | |
| skipped | Yes | |
| diagrams | Yes | |
| per_page | Yes | |
| downloads | Yes | |
| instrument | Yes | |
| chord_count | Yes | |
| left_handed | Yes | |
| diagram_count | Yes | |
| diagrams_shown | No | |
| transpose_semitones | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a safe, idempotent, closed-world read, so the burden is low; the description still adds real behavior: output is a print-ready PDF, one diagram per distinct chord, repeats collapse, a 64-distinct-chord ceiling, and chord shapes are validated by their notes.
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?
Front-loaded with the use case, followed by input guidance and then capability limits, so an agent can stop reading early and still call correctly. The middle sentence is long and clause-heavy, packing paper sizes, per-page counts, instruments and transpose/capo options into one run-on, which costs a point.
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?
Complete for a 14-parameter generator: it covers supported instruments and tunings, output format and page sizes, transposition/capo semantics, input conversion paths, and enumerated exclusions. Return values need no explanation because an output schema exists.
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 coverage is 100%, so the baseline is 3; the description earns extra credit by clarifying the division of labor between 'chords' (converted song/photo) and 'chord_sheet' (raw pasted text only) and by calling out capo 'auto' and the standard-tuning/uke limitations that the schema alone does not convey.
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 verb (generate/draw) and resource (printable chord chart PDF) plus the instruments and card layouts it covers. An agent can easily separate this from find_chord_fingerings, which looks up individual shapes rather than rendering a chart document.
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?
Opens with an explicit trigger sentence ('Use this when the user wants a ... printed chord chart') and closes with clear exclusions ('Does not do alternate tunings, bass, tabs or notation'). It also routes input handling ('use chord_sheet only to pass raw pasted text') but never names the sibling find_chord_fingerings as the alternative for single-chord lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
find_chord_fingeringsgenerate_chord_chartGuitar chords from frets, chord shapes, transposing, capo, scales, song keys and practice plans.
Make a printable setlist for your band's next gig from a pasted song list, with set times and a CSV.
Look up a guitar chord by name and get a text chord diagram. 12,708 standard-tuning names.
Make printable recipe cards from your own recipes as a print-ready PDF.
Add one secure layer between your agents and this server.
