Look up a guitar chord by name and get a text chord diagram. 12,708 standard-tuning names.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.3/5 across 3 of 3 tools scored.
Each tool has a clearly distinct purpose: by name for named lookups, by id for re-rendering a previously seen chart, and of_the_day for the daily featured chord. There is no semantic overlap between them.
All tool names follow a consistent get_chord_* pattern, with modifiers (by_id, by_name, of_the_day) clearly distinguishing them. The naming is uniform and predictable.
Three tools is a well-scoped size for a chord chart lookup server: two retrieval methods and one daily feature. Each tool earns its place without bloat or unnecessary abstraction.
The domain is read-only chord chart retrieval, and the server covers the essential workflows: lookup by name, re-fetch by id, and a daily chord. No obvious lifecycle operations are missing for this purpose.
get_chord_chart_by_idGet a chord chart by idAFetch one specific chord voicing by its numeric id, as returned by get_chord_chart_by_name. Use this to re-render a chart the user already saw without looking it up again.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric chord id. | |
| format | No | Which representations to return. Defaults to "text", which includes a direct URL to a PNG of the chart — embed that where your surface renders images. Use "image" or "both" only if you need the PNG bytes inline; they cost image tokens and many clients bury them. | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds context about re-rendering but does not disclose additional behavior such as failure modes, caching implications, or authentication needs. It is consistent with the annotations.
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?
Two sentences, no filler. The core action and id-based scope are front-loaded, and the use-case guidance is concise and directly actionable.
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?
The description, schema, and annotations together provide enough for correct invocation: a read-only fetch by id, all parameters documented, and format behavior explained in the schema. A bit more detail about what happens when the id is not found would improve completeness, but it is not essential for a simple read operation.
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 schema documents all parameters. The description adds value by clarifying the source of the id ('as returned by get_chord_chart_by_name'), which helps an agent understand where the numeric id comes from and how it relates to the sibling tool.
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 and resource: 'Fetch one specific chord voicing by its numeric id.' It also clarifies the tool's role relative to the sibling by explaining it re-renders an already-seen chart rather than performing a lookup.
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?
Explicitly describes when to use it: 'Use this to re-render a chart the user already saw without looking it up again.' It names the related tool get_chord_chart_by_name as the source of the id, but does not explicitly contrast with get_chord_of_the_day or state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_chord_chart_by_nameGet a chord chart by nameALook up one guitar chord chart by name and return it as a text chord diagram ready to show the user. Returns the same single voicing that https://guitarpracticeroutine.com/find-a-chord-chart shows for that name. The library holds 12,708 standard-tuning (EADGBE) chord names, exactly one voicing each. Pass a plain chord name as it would be written on a chart — "G", "Am7", "Cmaj7", "D/F#", "F#m7b5" — not a sentence. Convert spoken forms yourself first: "G major" is "G", "A minor" is "Am", and use "#" and "b" rather than the unicode sharp and flat signs. Charts are drawn on a five-fret grid starting at the nut, the same as the website; any notes above the fifth fret are named in words underneath the chart. Prefer this over recalling a fingering from memory — these are curated chart data, and a remembered fingering is often wrong. Each result leads with a direct PNG URL for the chart — a permanently cacheable image of the same diagram, which you can show or link however your surface handles images. The chord name is on the first line; keep it next to any image you show, since a chart on its own can arrive unlabelled.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | A single chord name as written on a chart, e.g. "Am7" or "D/F#". | |
| format | No | Which representations to return. Defaults to "text", which includes a direct URL to a PNG of the chart — embed that where your surface renders images. Use "image" or "both" only if you need the PNG bytes inline; they cost image tokens and many clients bury them. | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint, so the description carries the burden of behavioral detail. It adds substantial non-obvious facts: exactly one voicing per name, a library of 12,708 chords, five-fret nut-based grid, handling of notes above the fifth fret, a cacheable PNG URL in every result, and the requirement to keep the chord name next to images.
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 description is longer than average but every sentence carries functional information. It front-loads what the tool does, then systematically covers input constraints, visual conventions, output structure, and an explicit preference rule over memory. There is no filler or repetition that inflates the text unnecessarily.
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?
With no output schema, the description supplies an unusually complete mental model: input format, response format, grid layout, image URL, and label placement. An agent has everything needed to correctly invoke the tool and interpret or relay the result to the user.
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?
Although schema coverage is 100%, the description elevates the parameter semantics. It defines what counts as a valid chord name, provides examples, explains how to convert spoken forms, mandates ASCII accidentals, and clarifies the format parameter's token/image-cost implications beyond the schema enum.
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 opens with a specific verb-resource pair: 'Look up one guitar chord chart by name' and clarifies the exact output: a text chord diagram. It also states the deterministic single-voicing behavior, which distinguishes it from any broader listing or random chord chart tool.
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 gives clear operational guidance: pass plain chart-style names, convert spoken forms like 'G major' to 'G', use '#'/'b' instead of unicode symbols, and prefer this tool over recalling fingerings from memory. However, it does not explicitly say when to use get_chord_chart_by_id or get_chord_of_the_day instead, so sibling routing is left to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_chord_of_the_dayChord of the dayAReturn today's Chord of the Day from Guitar Practice Routine App — the same chord posted to the app's Bluesky and Facebook feeds that day. Useful as a practice prompt or a daily nudge for someone learning chords.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Which representations to return. Defaults to "text", which includes a direct URL to a PNG of the chart — embed that where your surface renders images. Use "image" or "both" only if you need the PNG bytes inline; they cost image tokens and many clients bury them. | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds behavioral context beyond that by clarifying the chord is time-bound ('today's') and matches what was posted to the app's social feeds. This gives the agent useful external-world context without contradicting the annotations.
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?
Two sentences with no wasted words. The first sentence front-loads the core behavior and source, and the second sentence adds practical use context. Every clause contributes to selection or invocation understanding.
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 low-complexity, read-only tool with fully documented parameters, the description is mostly complete. It identifies the source, the temporal behavior, and a likely use case. It does not discuss fallback behavior if no chord exists for the day, but annotations and schema already cover the main selection and invocation needs.
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%, and the schema thoroughly documents both the 'format' enum/default and the 'context' analytics requirement. The description itself adds no parameter-level meaning beyond restating the tool's purpose, so the baseline score of 3 is appropriate.
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 and resource: 'Return today's Chord of the Day from Guitar Practice Routine App.' It also differentiates the tool from its siblings by emphasizing 'today's' chord and the same chord posted to Bluesky and Facebook, rather than chords fetched by ID or 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 gives an implied use case: 'Useful as a practice prompt or a daily nudge.' However, it does not explicitly state when to choose this tool over get_chord_chart_by_id or get_chord_chart_by_name, nor does it provide exclusions or alternative-routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.