Look up a guitar chord by name and get a text chord diagram. 12,708 standard-tuning names.
Scored across 4 tools
The two lookup tools are cleanly split by key (numeric id vs. chord name), and the descriptions explicitly state the id comes from the name lookup, so the workflow is unambiguous. get_chord_of_the_day and send_feedback are clearly distinct from the chart lookups.
All names use snake_case verb_noun form, with the three chart tools sharing a get_chord_ prefix. send_feedback deviates slightly by dropping the chord-domain prefix, but the convention remains readable and predictable.
Four tools is thin for a lookup service: two are variants of the same single-voicing fetch, one is a novelty daily prompt, and one is meta-feedback. It's borderline rather than broken, but the surface feels minimal.
Core retrieval (by name, by id, chord of the day) is covered, but there is no search, browse, or list operation, so an agent cannot discover chords beyond a name it already knows. Notable gaps for a 12,708-entry library.
Fetch 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 | No | Numeric chord id, e.g. 123 (a numeric string like "123" also works). | |
| 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 in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as "a user", "the customer", or "an account". Example: "Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution." |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful provenance context (the id originates from get_chord_chart_by_name) but says nothing about failure behavior for invalid ids or what the returned chart representation looks like, so it clears the lower annotated bar only modestly.
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 tight sentences with the core action front-loaded and the motivating use case second. No filler, no restatement of the title, and every clause carries information.
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 full schema coverage, a clear read-only annotation set, and no output schema to explain, the description covers what an agent needs: what is fetched, what key identifies it, the id's source, and the intended scenario. Only the invalid-id/error path is left unaddressed, which is a minor gap for a simple read tool.
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 id, format, and context are already well documented, including defaults and enum tradeoffs for format. The description reinforces that the id is numeric and where it comes from but adds no syntax or format detail beyond the schema, which is the expected baseline when the schema carries the load.
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 (Fetch), resource (one specific chord voicing), and key (numeric id), and explicitly ties the id back to the sibling tool get_chord_chart_by_name. This lets an agent distinguish it from the by-name lookup sibling 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?
Gives a clear use case: re-rendering a chart the user already saw, avoiding a redundant name lookup, which implicitly routes id-known cases here and lookups to get_chord_chart_by_name. It does not explicitly state when not to use it, but the context is unambiguous in practice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look 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 | No | 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 in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as "a user", "the customer", or "an account". Example: "Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution." |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover read-only/open-world safety, but the description adds substantial behavior: the 12,708-name library, exactly one voicing per name, parity with the website, five-fret grid rendering, how above-fifth-fret notes are handled, and that the chord name leads the result. This is rich context beyond the structured fields.
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 core purpose and dense with useful detail, but the PNG-URL point is made twice (once in the opening sentence and again near the end), and the naming/formatting instructions could be tightened. Still efficient for the amount of information conveyed.
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?
There is no output schema, and the description compensates by describing the return shape precisely: text diagram, leading PNG URL, and the chord name on the first line. Nothing an agent needs to call or present the result 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 coverage is 100%, so the baseline is 3, but the description goes further by explaining the accepted chord-name syntax, unicode sharp/flat normalization, and spoken-form conversion ('G major' -> 'G'), which the schema's short example does not fully 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 and resource — look up one guitar chord chart by name and return a text chord diagram — and implicitly distinguishes itself from the sibling get_chord_chart_by_id through the 'by name' framing. An agent can tell exactly what it gets back without opening the 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?
Gives clear context (use this rather than recalling a fingering from memory) and practical input guidance on converting spoken chord forms. It does not explicitly name get_chord_chart_by_id as the alternative for id-based lookups, so the when-not branch is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return 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 in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as "a user", "the customer", or "an account". Example: "Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution." |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this as a read-only, non-open-world call, so the safety profile is covered. The description usefully adds provenance (the same chord posted to the app's Bluesky and Facebook feeds), but says nothing about caching, what happens before the day's chord is published, or whether the value is stable within a day.
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 tight sentences, front-loaded with the return value before the usage hint. No filler or repetition, though the app-name clause is slightly ornamental.
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 read-only, two-parameter tool with full schema coverage and no output schema, the description covers what is returned and why it exists. The main residual gap is failure/empty-state behavior when no chord has been posted for the current day.
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 format enum is documented in the schema in more detail than the description (default 'text', image-token cost, client behavior). The description adds no parameter meaning beyond that, so the baseline 3 applies.
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 ('Return today's Chord of the Day') and pins the scope to a single day, which implicitly separates it from the by_id/by_name siblings. It stops short of naming those siblings or explaining how the daily pick differs from an explicit chart 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?
The second sentence gives implied usage ('practice prompt or a daily nudge for someone learning chords'), so the agent knows the intent. It offers no explicit when-not guidance and never points to get_chord_chart_by_id or get_chord_chart_by_name as alternatives when the user wants a specific chord.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send feedback about this chord chart server: a chord or capability you needed that its tools could not provide, a problem with a chart or a result, or praise. Only for feedback about these chord chart tools, not about other tasks. Do not include personal information about the user.
| Name | Required | Description | Default |
|---|---|---|---|
| details | No | Optional longer context: what you tried, exact parameter values, the error text you saw, and any workaround you used. Omit when the summary says it all. | |
| summary | Yes | One self-contained sentence. For 'missing_capability': the capability you needed, e.g. 'No tool to delete multiple cohorts in one call.' For 'issue': the tool and the problem, e.g. 'query-trends rejects relative date ranges with an unclear error.' | |
| sentiment | No | Optional: how the experience felt overall. | |
| tool_name | No | Optional: the existing tool this feedback is about (for 'issue' or 'praise'). Leave empty for 'missing_capability' - the point is that no tool fits. | |
| feedback_type | Yes | What kind of feedback this is. Use 'missing_capability' when the tool you needed does not exist in the tool list - nothing failed, the capability is absent (this is the most valuable report; send it even if you found a workaround). Use 'issue' when an existing tool behaved badly: it failed, returned a confusing error, or its description or schema misled you. Use 'praise' when something worked notably well. Use 'other' for anything else. | |
| task_completed | No | Optional: whether you still completed the user's task despite the problem. | |
| friction_points | No | Optional: the specific moments that slowed you down, as short bullet-like sentences, quoting exact tool names, parameters, or error text. | |
| suggested_improvement | No | Optional: the concrete change that would have helped, e.g. the tool to add, the description to reword, or the error message to improve. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive, so the safety profile is covered. The description adds genuinely non-structured behavioral guidance: a privacy constraint ('Do not include personal information about the user') and a topical scope restriction. It still does not say what happens after submission (confirmation, storage, rate limits).
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 short sentences with the purpose front-loaded, followed by the two constraints that matter most (scope and privacy). No filler or redundant restatement of the title.
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 8-parameter tool with full schema coverage, no output schema, and complete annotations, the description covers purpose, scope and privacy adequately. Only the post-submission behavior (confirmation or error handling) is unaddressed, which is a minor gap.
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 each parameter already carries detailed guidance, including examples for 'summary' and the semantics of each 'feedback_type' enum value. The description's category list overlaps with the feedback_type enum rather than adding new parameter meaning, so the baseline 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 names a specific verb+resource ('Send feedback about this chord chart server') and enumerates the kinds of feedback accepted (missing capability, problem with a chart or result, praise). It is unambiguous and clearly distinct from the sibling read tools (get_chord_chart_by_id/name, get_chord_of_the_day), though it does not name a sibling explicitly.
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 gives a clear scope boundary: 'Only for feedback about these chord chart tools, not about other tasks,' which tells the agent when this tool applies and when it does not. It does not, however, mention any alternative channel or say what to do with feedback about other subjects.
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.
get_chord_chart_by_id6 fields changedInput schema / properties / id / descriptionPrevious value: -"Numeric chord id."New value: +"Numeric chord id, e.g. 123 (a numeric string like \"123\" also works)."Input schema / properties / id / maximumRemoved value: -9007199254740991Input schema / properties / id / minimumRemoved value: --9007199254740991Input schema / properties / id / typePrevious value: -"integer"New value: +[
+ "number",
+ "string",
+ "null"
+]Input schema / properties / llm_modelRemoved value: -{
- "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "context",
- "llm_model"
-]New value: +[
+ "context"
+]get_chord_chart_by_name2 fields changedInput schema / properties / llm_modelRemoved value: -{
- "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "context",
- "llm_model"
-]New value: +[
+ "context"
+]get_chord_of_the_day2 fields changedInput schema / properties / llm_modelRemoved value: -{
- "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "context",
- "llm_model"
-]New value: +[
+ "context"
+]send_feedbackget_chord_chart_by_id1 field changedInput schema / requiredPrevious value: -[
- "id",
- "context",
- "llm_model"
-]New value: +[
+ "context",
+ "llm_model"
+]get_chord_chart_by_name1 field changedInput schema / requiredPrevious value: -[
- "name",
- "context",
- "llm_model"
-]New value: +[
+ "context",
+ "llm_model"
+]get_chord_chart_by_id5 fields changedInput schema / properties / context / descriptionPrevious value: -"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.\""New value: +"Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\""Input schema / properties / id / exclusiveMinimumRemoved value: -0Input schema / properties / id / minimumAdded value: +-9007199254740991Input schema / properties / llm_modelAdded value: +{
+ "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "id",
- "context"
-]New value: +[
+ "id",
+ "context",
+ "llm_model"
+]get_chord_chart_by_name4 fields changedInput schema / properties / context / descriptionPrevious value: -"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.\""New value: +"Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\""Input schema / properties / llm_modelAdded value: +{
+ "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
+ "type": "string"
+}Input schema / properties / name / minLengthRemoved value: -1Input schema / requiredPrevious value: -[
- "name",
- "context"
-]New value: +[
+ "name",
+ "context",
+ "llm_model"
+]get_chord_of_the_day3 fields changedInput schema / properties / context / descriptionPrevious value: -"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.\""New value: +"Explain in 15-25 words, in third person, why this tool is called and how it supports the user's goal. For analytics only. You MUST describe only the abstract purpose of the tool call. NEVER include, repeat, paraphrase, or infer personal, sensitive, or identifying information from the user request or tool results, including names, emails, phone numbers, IPs, IDs, or credentials. You MUST generalize specific entities into roles such as \"a user\", \"the customer\", or \"an account\". Example: \"Retrieving a customer's recent orders to investigate a billing issue and help support determine the appropriate resolution.\""Input schema / properties / llm_modelAdded value: +{
+ "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "context"
-]New value: +[
+ "context",
+ "llm_model"
+]get_chord_chart_by_idget_chord_chart_by_nameget_chord_of_the_dayGuitar chords from frets, chord shapes, transposing, capo, scales, song keys and practice plans.
Read-only music guides, chord transposition, piano chord spelling and guitar-tab pitch mapping.
Find IANA ports, MIME types, HTTP codes/fields, URI schemes, PENs, BCP 47 tags, RFCs, any registry.
Chords, scales, transposition, capo and tempo maths, with links to free interactive music tools.
Add one secure layer between your agents and this server.