Zovo Chord Chart Maker

Find chord fingerings

find_chord_fingerings

Read-onlyIdempotent

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.

Input Schema

Name	Required	Description
`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).

Output Schema

Name	Required	Description	Default
`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

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.5/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/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. 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.

Purpose5/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 ('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.

Usage Guidelines5/5

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.

All Zovo Chord Chart Maker tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?