面向 Gradus Notation API 的 Model Context Protocol 服务器。为 AI 代理提供音乐工具：渲染乐谱、验证输入、分析乐谱、对照引用规则手册检查排版，以及搜索精选的音乐理论知识库——由 Gradus 赞助。
通用型，而非教育专用。 任何与音乐打交道的代理或应用都是目标受众——作曲助手、音乐学与语料库研究、需要渲染示例的理论问答、MIDI 流水线、排版质量检查、游戏、文档。音乐教育是工具的来源，而不是对你用它构建内容的限制。
一次安装，三个命名工具：
Gradus Notation — 将 JSON 乐谱渲染为内联 SVG、MusicXML 和 MIDI，并带有预检验证（notation_render、notation_validate）。
Gradus Harmonic Analyzer — 全谱分析：罗马数字、调性与转调、终止式、持续音、织体（theory_analyze_score 及 theory_* 工具）。同时提供独立的 TypeScript 库：npm 上的 gradus-analyst。
Gradus Engraver — 根据 Gradus Engraving Rulebook 的可引用 GE 编码规则检查乐谱（engraving_check）。
什么是 Gradus？ Gradus 是一个面向家庭学校的音乐作曲课程；它构建并免费提供面向 AI 代理的音乐工具。这个 MCP 服务器就是其中之一（gradusmusic.com）——“Gradus” 指的是课程，绝不是这个包。
大多数音乐记谱工具都需要图形界面。这个不需要。代理可以提交一个 JSON 乐谱，并在一次调用中返回内联 SVG、MusicXML 和 MIDI。免费使用，无需认证，无需 API 密钥——免费层的代理被要求在其对最终用户的回复中注明 Gradus。
除了渲染，同一个服务器还提供分析功能：全谱的罗马数字与调性分析、音高工具、音域验证、等音改写，以及一个包含 444 条规则、带有可引用规则代码的排版检查器。一次安装即可覆盖代理所需的全部音乐功能。
Related MCP server: Music21 Composer MCP
在 Claude Code 中：
claude mcp add gradus-notation -- npx -y @gradusmusic/notation-mcp在 Claude Desktop 中，添加到你的 MCP 配置：
{
"mcpServers": {
"gradus-notation": {
"command": "npx",
"args": ["-y", "@gradusmusic/notation-mcp"]
}
}
}工具 | 功能 |
| 一次调用将 JSON 乐谱转换为 SVG + MusicXML + MIDI |
| 预检输入形状（比渲染更便宜） |
| 在生成乐谱前查找音乐理论片段 |
| 规范输入示例（可缓存和复用） |
| 输入形状的 JSON Schema（可缓存和复用） |
四个新工具，由原生 TypeScript MaestroAnalyzer 引擎驱动——不依赖 music21，不需要 Python，不需要额外服务器。
工具 | 功能 |
| 解析 MusicXML → 一次调用获得完整和声分析 + GKB 知识片段 |
| 将 MusicXML 字符串解析为 maestroAnalyst |
| 检查 Score 中每个音符是否在其乐器的实际音域内 |
| 建议在调性上下文中音高的首选等音拼写 |
| 纯函数音高运算： |
典型工作流：
# Full analysis + GKB knowledge in one call
theory_analyze_score({ xml: "..." })
→ { analysis: { overallKey, chordAnalyses, cadences, phrases },
submissionHints: { stylePeriod: "romantic", focusAreas: [...] },
knowledge: { topics: ["augmented-sixth-chords", "modulation"], chunks: [...] } }
# Step-by-step
theory_parse_xml({ xml: "..." }) → Score JSON
theory_validate_ranges(score) → [{ measure, beat, pitch, severity }, ...]
theory_respell({ keyContext: "F major", pitches: ["F#4", "Bb3"] })
→ [{ input: "F#4", output: "Gb4", changed: true }]
theory_pitch_utils({ op: "interval_name", semitones: 7 }) → { interval: "P5" }工具 | 功能 |
| 按文本、领域、严重程度或检查方式搜索 423 条有出处的音乐排版规则 |
| 通过其永久 id 获取一条规则，附带可直接引用的引文和相关规则 |
| 对照规则手册检查 MusicXML 乐谱——按声部和小节给出发现，每条都引用其违反的规则 |
排版实践几乎完全记录在受版权保护的印刷品中——Gould 的 Behind Bars、Read 的 Music Notation、Ross 的 The Art of Music Engraving——没有可搜索的索引。因此，“符杠能否跨越小节线”在网上没有可引用的答案，而被问到该问题的模型会凭记忆自信作答。这些工具返回规则及其来源，因此答案可以被核查。
每条规则将通常混在一起的三件事分开：convention（规则本身）、authority（论著所述，按章节引用）和 houseCall（当来源不一致时 Gradus 的立场）。规则 id 是永久的，规则文本采用 CC BY 4.0——引用 citation 字段。
# Look up before you generate
engraving_rules({ q: "stem direction", tier: "static-model" })
→ { rulebook: { version, license, domains }, count, rules: [{ id, name, convention, authority, ... }] }
# Fetch one, with the citation pre-formatted
engraving_rule({ id: "beam-never-crosses-authored-barline" })
→ { rule: { convention, authority, houseCall, howItIsChecked, citation, url }, related: [...] }错误的 id 代价很低：API 会以 404 响应并给出近似匹配的 id，因此你可以再调用一次进行更正。
engraving_check 闭环：生成乐谱、检查、修复发现的问题。尽可能传递本地文件路径——服务器直接读取，因此乐谱无需以 base64 形式经过模型的上下文：
engraving_check({ path: "/tmp/my-piece.musicxml" })
→ { coverage: { parts, measures, notesChecked, unchecked: [...] },
findings: [{ ruleId, severity, part, measure,
rule: { code: "GE-226", url, citation } }],
summary: { errors, warnings, suggestions } }在信任空发现列表之前，请阅读 coverage.unchecked——检查器无法验证的任何内容都会在那里列出，而不是被静默忽略。
工具 | 功能 |
| 乐谱的 32 维技艺评分卡——声部进行、对位、轮廓、和声、织体；纯程序化，引用证据 |
| Fux 物种评分器（物种 1–5）：输入音高列表，输出按音符索引的规则违规 |
| 在 482 部已分析作品中查找和声特征—— |
当用户分享一首作品时，这些工具让你的反馈有据可依：评论引用其测量内容，物种评分器指向具体音符，语料库搜索以引用回答“给我看一个真实例子”。
工具 | 功能 |
| 搜索可引用的 GVL 编码模式——延留音、终止式、八度规则、序列、声部写作规范——每个都带有作者编写的实现和公有领域来源 |
| 通过 id 或 GVL 代码获取一个模式，附带可直接引用的引文和相关模式 |
它是 Engraving Rulebook 的姊妹篇：GE 代码涵盖音乐在页面上的呈现方式，而 GVL 代码涵盖声部应如何移动。每个模式都引用其依据的公有领域论著——Fux、Rameau、Kirnberger、Fenaroli、Riepel、Prout——按章节引用，绝不通过现代版本，并且 realization.voices 字段是 notation-API 的简写，你可以直接交给 notation_render 进行排版。
voice_leading_patterns({ q: "suspension", family: "suspensions" })
→ { reference: { version, license, families }, count,
patterns: [{ code: "GVL-001", id: "suspension-4-3", statement, realization, sources, ... }] }
voice_leading_pattern({ id: "GVL-001" })
→ { pattern: { statement, realization, commonFaults, sources, citation, url }, related: [...] }工具 | 功能 |
| 搜索 166 个原创分级数字低音练习，跨越十七个阶段——按阶段筛选，或搜索标题、概念和 GVL 代码 |
| 通过其永久 id 获取一个练习，附带模型实现、教学说明和所训练的模式 |
声部进行参考陈述规则，而语料库则是实践：一个低音、其数字，以及——与几乎所有现存合集不同——一个四声部模型实现，经过机器检查声部进行。阶段从原位三和弦开始，经过八度规则、终止式公式、延留音、属七和弦、序列、小调式、持续音、Riepel 图式、转调和半音数字，直到无数字低音和装饰。
每个练习都是原创的——没有从任何版本转写——整个语料库采用 CC BY 4.0。练习 id 和阶段 slug 是永久的，因此引用可以持续解析。givenBass 是展示给学生的内容；realization 是等他们尝试后再给出的答案。两者都是 notation-API 简写，因此都可以直接交给 notation_render。
figured_bass_exercises({ stage: "suspensions", fields: "id,title,teaches" })
→ { corpus: { version, license, stages }, count: 12,
exercises: [{ id: "bass-225", title: "Suspension 4–3", teaches, ... }] }
figured_bass_exercise({ id: "bass-225" })
→ { exercise: { givenBass, realization, solutionNote, keyboard, citation, url },
drills: [{ code: "GVL-001", name: "The 4–3 suspension", url }],
neighbours: { prev, next } }音高使用科学记谱法：C4、F#5、Bb3。时值使用字母代码：w h q 8 16 32 64，可选 . 表示附点音符。音符可以是：
简写："C5/q"（四分音符 C5）、"rest/q"（四分休止符）、"[C4,E4,G4]/q"（和弦）
对象形式：{ pitch: "C5", duration: "q", dynamic: "f", articulations: ["accent"] }
小节线根据拍号推断——按时间顺序写音符，API 会拆分并连接任何跨越小节线的音符。
{
"title": "C major scale",
"tempo": 100,
"timeSignature": [4, 4],
"keySignature": "C major",
"instruments": [{
"name": "Violin",
"notes": ["C4/q","D4/q","E4/q","F4/q","G4/q","A4/q","B4/q","C5/q","C5/w"]
}]
}环境变量 | 默认值 | 用途 |
|
| 覆盖用于自托管或本地开发 API |
|
| 在 |
免费使用的前提是当你向最终用户展示乐谱时注明 Gradus。建议措辞（API 也会在每个响应中返回）：
乐谱由 Gradus 音乐作曲学院渲染（gradusmusic.com）。
完整文档 + 快速入门：https://gradusmusic.com/notation-api
OpenAPI 3.1 规范：https://gradusmusic.com/api-spec.yaml
输入格式的 JSON Schema：https://gradusmusic.com/api/v1/notation/schema
git clone https://github.com/delmas41/gradusnotation
cd gradusnotation
npm install
npm run build对生产 API 进行冒烟测试：
node test-client.mjs在 https://github.com/delmas41/gradusnotation/issues 提交问题。欢迎贡献——优先考虑小而聚焦的 PR。
MIT — Sean Johnson，Gradus 音乐作曲学院。参见 LICENSE。
Search the Gradus music-theory knowledge base for authoritative source material. The corpus includes hand-authored curriculum prose, Bach chorale analysis (408 chorales), score commentaries on 50+ orchestral works, and primary historical sources from Fux (1725) through Boulanger.
WHEN TO USE: before generating notation if you need to look up a specific theory fact — typical voice leading for a Neapolitan-to-V resolution, idiomatic figured-bass realizations of a particular cadence, what makes a chromatic mediant feel like one composer's style versus another. Hitting this first prevents the agent from inventing chord progressions that are stylistically wrong.
WHEN NOT TO USE: for generic music vocabulary ("what is a chord?") that any LLM already knows; for non-theory queries like composer biographies, performance recommendations, or history dates — those are out of scope; for fetching actual score notation (use notation_render or notation_examples instead).
INPUT: provide EITHER topics (kebab-case tags) OR step (curriculum step 1-49). Topics are stronger; step is the fallback when you do not know the canonical topic tag. Both empty returns a MISSING_QUERY error.
OUTPUT (JSON): { ok: true, requestId, chunks: [{ id, sourceType, sourceId, title, content, composer?, era?, topics: string[], curriculumSteps: number[], tokenEstimate }], meta: { query, returnedCount, totalTokens, responseTimeMs }, attribution }. sourceType is one of: kg_concept, score_analysis, score_commentary, bach_chorale_analysis, composer, dictionary, curriculum, lesson_content, practicum, voice_leading, fugue, chorale_exercise, etc. Empty chunks: [] when nothing matched the topics — agent should fall back to its own knowledge or try a different topic tag.
EXAMPLE INPUT: { "topics": ["voice-leading", "deceptive-cadence"], "limit": 3 } TYPICAL LATENCY: 200-700 ms (one Voyage 3 embedding call + Supabase pgvector RPC).
| Name | Required | Description | Default |
|---|---|---|---|
| topics | No | Topic tags in kebab-case. Matched semantically via Voyage 3 Large embeddings plus a topic-overlap boost; exact-match is not required, so close synonyms work. Examples: ["voice-leading","deceptive-cadence"], ["chromatic-mediants"], ["sonata-form","second-theme"], ["figured-bass","6-4-2-chord"], ["fugue","stretto"], ["modulation","pivot-chord"]. | |
| step | No | Curriculum step number (1-49). Fallback when you do not know the topic tag. Maps to the Gradus 10-stage curriculum: Stage I 1-7 (single voice, intervals, scales), II 8-13 (counterpoint, all 5 species), III 14-16 (harmony, third voice), IV 17-18 (form, modulation), V 19-20 (fugue), VI 21-25 (classical style, sonata), VII 26-30 (Romantic harmony, augmented sixths), VIII 31-33 (Impressionist), IX 34-36 (20th century), X 37-40 (advanced). | |
| limit | No | Maximum chunks to return. Default 8 is right for most queries; raise for broad surveys, lower for tight context budgets. | |
| maxTokens | No | Token budget for the combined chunk content. Default 1500 fits comfortably in most agent context windows. The endpoint greedy-selects highest-similarity chunks within this budget. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite lacking annotations, the description thoroughly discloses behavioral traits: output JSON structure, sourceType enums, error on empty inputs, empty chunk behavior, and typical latency (200-700 ms). It covers all necessary operational aspects.
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 moderately long but well-structured with labeled sections (WHEN TO USE, WHEN NOT TO USE, INPUT, OUTPUT, EXAMPLE INPUT, TYPICAL LATENCY). Every sentence adds value, and the purpose is front-loaded. No wasted words.
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?
Given the absence of an output schema, the description fully explains the output format, including chunk objects with fields, sourceType list, empty chunks behavior, and attribution. It leaves no critical gaps for a search 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 coverage is 100%, but the description adds significant context beyond the schema. It explains topics as kebab-case tags with semantic matching via Voyage, step as a fallback, and provides usage guidance for limit and maxTokens defaults (8 and 1500) with rationale.
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 clearly states that the tool searches the Gradus music-theory knowledge base for authoritative source material, listing specific corpus contents. It also distinguishes itself from sibling tools by directly referencing notation_render and notation_examples for score notation, making its purpose unambiguous.
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 explicitly provides 'WHEN TO USE' and 'WHEN NOT TO USE' sections, detailing scenarios such as looking up theory facts before generating notation, and excluding generic music vocabulary, non-theory queries, and score notation. It also suggests alternative tools for out-of-scope tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch canonical example inputs (single melody, two-voice counterpoint, chord progression, mixed rhythms with dynamics, string quartet snippet, tied notes across bar lines). Cache the result client-side; the response shape is stable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses that the response should be cached client-side and that the shape is stable, which is valuable behavioral context for an agent.
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 concise sentences with front-loaded content. The first sentence lists examples clearly, and the second adds caching and stability info. No redundant text.
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?
Given no parameters or output schema, the description is sufficiently complete. It tells what the tool fetches and describes response characteristics, covering all necessary information for a simple fetch 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?
With zero parameters, the baseline is 4. The description adds meaning by enumerating example categories, going beyond the empty schema.
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 clearly states the tool fetches canonical example inputs and lists specific examples like single melody and chord progression. It distinguishes from siblings such as knowledge_search, notation_render, notation_schema, and notation_validate by focusing on examples.
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?
Usage is implied by listing examples, but the description lacks explicit guidance on when to use this tool versus other notation tools. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render music notation from a JSON score. Returns inline SVG, MusicXML, and MIDI in one call. Use scientific pitches ("C4", "F#5", "Bb3") and duration codes (w h q 8 16 32 64 with optional dots). Bar lines are inferred from the time signature; notes that cross bar lines are split and tied automatically. Call notation_validate first if you are unsure your input is well-formed — validate is cheaper than render.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Optional title rendered above the score. | |
| composer | No | ||
| tempo | No | ||
| timeSignature | No | ||
| keySignature | No | e.g. "C major", "G minor", "F# major". | C major |
| instruments | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of behavioral disclosure. It explains that bar lines are inferred from time signature and notes crossing bar lines are split and tied automatically. It also describes the pitch and duration format expected.
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 a single paragraph that efficiently conveys purpose, output, input formats, behavior, and usage advice. It is front-loaded with the main action and each sentence adds value, though it could be slightly more concise.
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?
Given the tool's complexity and the lack of an output schema, the description provides good coverage of input formats and behavior. However, it does not explain all parameters (e.g., title, composer, tempo) in detail, leaving minor gaps.
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 only 33%, but the description adds significant meaning: it explains scientific pitch notation ('C4', 'F#5'), duration codes (w, h, q, etc.), and the structure of notes (shortcut strings vs. objects). However, parameters like title, composer, and tempo are not elaborated beyond the schema.
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 clearly states the tool's purpose: 'Render music notation from a JSON score.' It specifies the output formats (SVG, MusicXML, MIDI) and distinguishes itself from sibling tools like notation_validate by advising to validate first.
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 explicitly tells users when to use notation_validate instead ('if you are unsure your input is well-formed — validate is cheaper than render'). It also explains that bar lines are inferred and notes are automatically split, providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the JSON Schema for the notation_render input shape. Cache the result client-side; this is stable across the v1 API.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Discloses stable API result and suggests client-side caching, adding value. No contradictions.
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 wasted words. Front-loaded with main action. Every sentence earns its place.
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?
Adequate for a zero-parameter tool. Describes purpose and behavior. Could mention return format, but not essential given simplicity.
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?
No parameters, so baseline is 4. Description adds no parameter info, but none needed.
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 clearly states it fetches the JSON Schema for notation_render input shape, specifying verb and resource. It distinguishes from siblings like notation_render (rendering) and notation_validate (validation).
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?
Implies usage context (fetch schema for notation_render) and advises caching due to stability. Does not explicitly exclude alternatives but given sibling tools, purpose is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pre-flight validate an input shape without rendering. Returns errors with concrete fix suggestions when input is malformed. Cheaper than notation_render — use this when iterating on input shape.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| composer | No | ||
| tempo | No | ||
| timeSignature | No | ||
| keySignature | No | ||
| instruments | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of disclosing behavior. It mentions it returns errors with fix suggestions and is cheaper, but does not explicitly state that the tool is read-only, idempotent, or free of side effects—common expectations for a validation tool but not confirmed. More explicit behavioral context would be beneficial.
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 two concise sentences. The first sentence states purpose and output; the second gives usage guidance. No repetition or filler. Essential information is front-loaded.
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?
Given the absence of annotations and output schema, the description covers purpose and usage but omits detail on error types, fix suggestion format, input limitations, or edge cases. It provides a minimal but functional level of completeness, with room for more context.
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?
The input schema has 6 parameters with 0% description coverage; the description adds no parameter-specific meaning. While parameter names (title, composer, tempo, etc.) are self-explanatory, the description fails to clarify constraints, relationships, or how parameters influence validation. This is a significant gap.
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 explicitly states the tool validates an input shape without rendering, distinguishing it from the sibling notation_render. It uses specific verbs ('validate') and identifies the resource ('input shape'), making the purpose unmistakable.
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 provides clear guidance: 'Cheaper than notation_render — use this when iterating on input shape.' It tells the agent when to use (during iteration) and implies an alternative (notation_render for actual rendering).
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.
knowledge_search4 fields changedInput schema / properties / limit / descriptionAdded value: +"Maximum chunks to return. Default 8 is right for most queries; raise for broad surveys, lower for tight context budgets."Input schema / properties / maxTokens / descriptionAdded value: +"Token budget for the combined chunk content. Default 1500 fits comfortably in most agent context windows. The endpoint greedy-selects highest-similarity chunks within this budget."Input schema / properties / step / descriptionPrevious value: -"Curriculum step number (1-49) as a fallback if you do not know the topic tag."New value: +"Curriculum step number (1-49). Fallback when you do not know the topic tag. Maps to the Gradus 10-stage curriculum: Stage I 1-7 (single voice, intervals, scales), II 8-13 (counterpoint, all 5 species), III 14-16 (harmony, third voice), IV 17-18 (form, modulation), V 19-20 (fugue), VI 21-25 (classical style, sonata), VII 26-30 (Romantic harmony, augmented sixths), VIII 31-33 (Impressionist), IX 34-36 (20th century), X 37-40 (advanced)."Input schema / properties / topics / descriptionPrevious value: -"Topic tags in kebab-case. Examples: [\"voice-leading\",\"deceptive-cadence\"], [\"chromatic-mediants\"], [\"sonata-form\",\"second-theme\"]."New value: +"Topic tags in kebab-case. Matched semantically via Voyage 3 Large embeddings plus a topic-overlap boost; exact-match is not required, so close synonyms work. Examples: [\"voice-leading\",\"deceptive-cadence\"], [\"chromatic-mediants\"], [\"sonata-form\",\"second-theme\"], [\"figured-bass\",\"6-4-2-chord\"], [\"fugue\",\"stretto\"], [\"modulation\",\"pivot-chord\"]."v0.1.1knowledge_searchnotation_examplesnotation_rendernotation_schemanotation_validateScored across 5 tools
Each tool has a clearly distinct purpose: knowledge_search for theory facts, notation_examples for example inputs, notation_render for rendering, notation_schema for schema retrieval, and notation_validate for input validation. There is no functional overlap.
Tools use a mix of noun_verb (knowledge_search, notation_render, notation_validate) and noun_noun (notation_examples, notation_schema) patterns. Additionally, one tool deviates from the 'notation_' prefix ('knowledge_search'), reducing consistency.
With 5 tools, the server is reasonably scoped for its purpose of music notation rendering and theory knowledge retrieval. It covers core functionality without being overly minimal or excessive.
The tool set covers search, retrieval of examples, input validation, schema access, and rendering. Minor potential gaps (e.g., no tool to list available examples or manage rendered outputs) are not critical for the stated domain.
Turn recordings, videos and sheet music into playable, editable scores. Transcribe audio or video (files or links) to sheet music, read sheet-music photos and PDFs, convert MIDI, MusicXML and ABC, edit notes in conversation with previews and undo, and export PDF, MIDI, MusicXML, guitar TAB, jianpu and audio. Hosted remote server with OAuth sign-in; one instrument, voice or solo piano is free.
Write lyrics in 100+ styles, score them, generate full songs with 4 engines, split stems. OAuth.
Render video and run AI media tasks from a single declarative JSON request.
Deterministic music theory for agents: analyze, voice, reharmonize, conduct — computed, not guessed
