这是一款基于 Tone.js 和 @tonejs/midi 库的 MIDI 文件解析和操作工具，通过 MCP（模型上下文协议）服务提供功能。此工具可让您轻松读取、分析和修改 MIDI 文件，而无需深入研究 MIDI 文件格式的复杂性。
Related MCP server: able-mcp
读取 MIDI 文件信息
获取并修改音轨、音符、控制变化和弯音信息
设置 MIDI 文件速度 (BPM)
向特定音轨添加新音符、控制变化和弯音
添加新曲目
全面的错误处理
安装Node.js ：确保 npx 命令可以正常运行，建议从Node.js 官网安装最新稳定版本
与 MCP 客户端一起使用，支持的客户端包括但不限于：
在 Cursor 中配置 midi-file-mcp：
"midi-file-mcp": {
"command": "npx",
"args": [
"-y",
"midi-file-mcp"
]
}MIDI Parser MCP 中的所有操作都需要 MIDI 文件的绝对路径。这确保了无论当前工作目录如何，该工具都能正确定位和操作您的 MIDI 文件。
以下是一些您可以与 AI 助手一起使用的示例提示：
获取 MIDI 文件信息：
Can you show me information about the MIDI file at D:\path\to\your\file.mid?分析曲目：
Please analyze all tracks in D:\path\to\your\file.mid and tell me how many notes are in each track.设置节奏：
Change the tempo of D:\path\to\your\file.mid to 120 BPM.使用注释：
Show me all notes in track 1 of D:\path\to\your\file.mid.添加注释：
Add a C4 note at position 0 with a duration of 1 beat to track 0 in D:\path\to\your\file.mid.手术 | 描述 | 参数 |
获取midi信息 | 获取常规 MIDI 文件信息 | 文件路径 |
设置节奏 | 设置 MIDI 文件的节奏 (BPM) | 文件路径，bpm |
获取轨迹信息 | 获取有关所有曲目的信息 | 文件路径 |
通过索引获取轨迹信息 | 获取有关特定曲目的信息 | 文件路径、轨道索引 |
通过索引获取笔记 | 获取特定曲目的所有音符 | 文件路径、轨道索引 |
通过索引获取弯音 | 获取特定音轨的所有弯音 | 文件路径、轨道索引 |
通过索引获取控制更改 | 获取特定轨道的所有控制变化 | 文件路径、轨道索引 |
按索引添加注释 | 向特定轨道添加注释 | 文件路径、曲目索引、注释 |
通过索引添加控制更改 | 将控制更改添加到特定轨道 | 文件路径、轨道索引、控制变化 |
按索引添加弯音 | 为特定音轨添加弯音 | 文件路径、音轨索引、弯音 |
添加轨道 | 向 MIDI 文件添加新音轨 | 文件路径 |
注意：使用 Windows 路径时，请始终在文件路径中使用双反斜杠 ( \\ ) 或正斜杠 ( / )，以避免出现错误。
本项目遵循 MIT 许可证。详情请参阅 LICENSE 文件。
感谢以下项目和库，如果没有它们，这个工具就不可能实现：
Tone.js - Web 音频框架
@tonejs/midi - MIDI 文件解析和操作库
MCP（模型上下文协议） ——使工具集成到人工智能助手中成为可能
Add controlchanges to midi file by track index
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absoulate File Path to midi file | |
| trackIndex | Yes | Track index number | |
| controlchanges | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'Add controlchanges'. It fails to disclose that this likely modifies the file (destructive), whether changes are reversible, or any permission or error behavior. The tool's safety profile is completely opaque.
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, concise sentence without wasted words. However, it lacks structure (e.g., bullet points) that could improve readability for complex parameters.
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 tool with three required parameters and no output schema or annotations, the description is very incomplete. It does not explain return values, error conditions, file requirements, or behavior on existing data. The agent is left with significant ambiguity.
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 67%, but the description adds no meaning beyond the schema. It does not explain 'controlchanges' structure (e.g., time vs ticks, number/value ranges). The description leaves the agent to infer entirely from schema, which is insufficient for correct invocation.
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 'Add controlchanges to midi file by track index', specifying the action (add), resource (controlchanges), target (midi file), and identifier (track index). This distinguishes it from sibling tools like 'add_notes_by_index' or 'get_controlchanges_by_index'.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., whether it appends or replaces, or if one should first retrieve existing control changes). The description lacks any context about prerequisites or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add notes to midi file by track index
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absoulate File Path to midi file | |
| trackIndex | Yes | Track index number | |
| notes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral details such as whether notes are appended, overwritten, or if the file is modified in place. Important side effects remain undocumented.
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 short sentence, which is concise. However, it could include more useful information without becoming overly long.
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 and no annotations, the description lacks completeness. It should clarify behavior (e.g., file modification vs new file) and error conditions for a mutating 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 description coverage is 67%, with filePath and trackIndex described. The complex notes schema is well-defined in the schema itself, so the description adds little beyond stating the operation. It does not compensate for missing parameter descriptions.
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 action (add notes) and the target (midi file by track index). It effectively distinguishes from sibling tools like add_controlchanges_by_index.
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?
No information on when to use this tool versus alternatives such as add_controlchanges_by_index. No context about prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add pitchbends to midi file by track index
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absoulate File Path to midi file | |
| trackIndex | Yes | Track index number | |
| pitchbends | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description fails to disclose behavioral traits such as whether existing pitchbends are overwritten, error handling for invalid track indices, or file modification side effects. The description only states the basic action without any behavioral context.
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 sentence, making it concise but overly sparse. It front-loads the action but sacrifices informativeness. A slightly longer description could better explain the parameter structure without losing conciseness.
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 complexity of the pitchbends parameter (nested array with value and either time or ticks), the description is incomplete. It does not mention return values (no output schema), error cases, or file-level considerations. Sibling tools and the parameter count suggest more detail is needed.
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 description adds no meaning beyond the input schema. The schema provides descriptions for filePath and trackIndex but not for the pitchbends array. The tool description does not explain how to structure pitchbends (value and time/ticks), leaving ambiguity for the agent.
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 action (add pitchbends) and resource (midi file by track index). It distinguishes from siblings like add_notes_by_index and add_controlchanges_by_index through specificity. However, it simply restates the tool name without additional context.
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?
No guidance on when to use this tool versus alternatives like add_notes_by_index or add_controlchanges_by_index. It does not mention any prerequisites, limitations, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a new track to midi file and return the new track info
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absoulate File Path to midi file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. While it states that a track is added and info is returned, it omits critical details: whether the file is mutated, what happens if the file does not exist or is read-only, and how the new track is initialized (e.g., empty?). The minimal description leaves significant ambiguity about side effects.
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 sentence with no unnecessary words, making it concise. However, it lacks structure (e.g., separating action from return) and front-loading key constraints. While efficient, it could be slightly more organized.
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 mutation tool with no annotations and no output schema, the description is incomplete. It does not explain error conditions, file modification behavior, or the format of the returned info. An agent would need additional context to use the tool correctly in all scenarios.
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 covers the single parameter (filePath) with 100% description coverage, stating 'Absoulate File Path to midi file'. The tool description adds no additional meaning beyond the schema, so it meets the baseline expectation but does not enhance understanding.
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 action ('Add') and the resource ('a new track to midi file'), and specifies that it returns the new track info. This distinguishes it from sibling tools that add notes, control changes, or pitch bends, 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 provides no guidance on when to use this tool versus alternatives, such as when the file must exist, whether the file is modified in-place, or any prerequisites. An agent gets no context for selecting this over other add-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get controlchanges from midi file by track index
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absoulate File Path to midi file | |
| trackIndex | Yes | Track index number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. However, it only says 'Get controlchanges' without explaining side effects (likely none), whether it's read-only, or what happens on errors. Important details like file existence requirements or return format are omitted.
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, well-structured sentence that is immediately clear. There is no extraneous information. It front-loads the key action and resource.
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 output schema, the description should provide more context about return values, but it does not. It also lacks error handling information, file format expectations, or behavior when the track or file is invalid. For a simple tool, some completeness 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% with descriptions for both filePath and trackIndex. The description adds no additional meaning beyond what the schema already provides. Thus, it meets the baseline of 3.
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 retrieves controlchanges from a MIDI file by track index. It uses a specific verb (Get) and resource (controlchanges). While it doesn't explicitly differentiate from siblings like get_notes_by_index, the resource name is distinct enough for an agent to infer the purpose.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., get_notes_by_index). There is no mention of prerequisites, context, or exclusions. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get midi file info
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absoulate File Path to midi file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Unlikely to be destructive, but no annotations provided. The description doesn't confirm read-only behavior, expected return structure, or side effects. Leaves too much unknown.
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 extremely concise (4 words) but lacks necessary detail. It's not verbose, but the brevity sacrifices usefulness.
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 output schema and simple input, the description should elaborate on what 'info' means (e.g., metadata, structure). As is, it's incomplete for reliable agent use.
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% for the single parameter filePath, but the description only restates 'Absoulate File Path' without adding formatting constraints or examples. It meets the baseline but adds no extra value.
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 'Get midi file info' states a general purpose but doesn't specify what aspects of the MIDI file are retrieved (e.g., track count, tempo, key). It is ambiguous compared to siblings like 'get_track_info_by_index' which are more specific.
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?
No guidance on when to use this tool vs. siblings like 'get_tracks_info' or 'get_track_info_by_index'. An agent would lack context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get notes from midi file by track index
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absoulate File Path to midi file | |
| trackIndex | Yes | Track index number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only states what the tool does (get notes) but does not mention that it is read-only, any file access requirements, or potential side effects.
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, concise sentence with no extraneous words. While it could include more detail, it is efficient and 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?
The tool has no output schema, but the description does not hint at the structure of returned notes (e.g., pitch, velocity, timing). For a tool of moderate complexity with several siblings, this omission leaves the agent with incomplete information.
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?
Input schema has 100% coverage and clearly describes each parameter. The description adds no additional meaning beyond what the schema provides, so a 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 clearly states the verb 'Get', the resource 'notes from midi file', and the parameter 'by track index', which distinguishes it from sibling tools like 'add_notes_by_index' and 'get_controlchanges_by_index'.
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 does not explicitly specify when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. However, the tool's name and sibling context provide some implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get pitchbends from midi file by track index
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absoulate File Path to midi file | |
| trackIndex | Yes | Track index number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation ('Get'), but with no annotations, it does not explicitly state safety or side effects. It lacks details on error handling or behavior for invalid inputs (e.g., non-existent file or out-of-range track index).
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 sentence with no fluff. It is concise, though slightly under-specified; could be improved without adding much length.
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?
No output schema is provided, and the description does not hint at the return format or structure. For a tool that retrieves data, this omission is significant and leaves the agent guessing about the output.
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?
Both parameters have descriptions in the schema (100% coverage). The description does not add additional meaning beyond what the schema provides, so baseline score of 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?
The description clearly states the action (get) and resource (pitchbends from midi file by track index). It distinguishes from sibling tools like get_notes_by_index by specifying pitchbends, but lacks detail on what exactly is returned (e.g., list of events).
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?
No guidance on when to use this tool versus alternatives (e.g., add_pitchbends_by_index or get_controlchanges_by_index). No prerequisites, exclusions, or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get track info from midi file by track index. name, instrument, channel, endOfTrackTicks, duration, durationTicks, noteCount
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absoulate File Path to midi file | |
| trackIndex | Yes | Track index number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since annotations are absent, the description bears full burden. It discloses only the returned fields, not side effects, error conditions, permissions, or state changes. For a read tool, more transparency is 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?
Description is two sentences: first states purpose, second lists output fields. No fluff, front-loaded, 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?
Given no output schema, the description lists output fields, which is helpful. It lacks error handling or prerequisite context. For a simple getter, it is adequate but not fully comprehensive.
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?
Input schema has 100% description coverage with adequate parameter descriptions. The description adds no extra parameter semantics (e.g., format or constraints) but usefully lists output fields, compensating slightly for lack of output 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 verb 'get', the resource 'track info', and the method 'by track index'. It distinguishes from siblings like 'get_tracks_info' (all tracks) and specialized 'get_*_by_index' tools.
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 no guidance on when to use this tool versus alternatives, such as 'get_tracks_info' for all tracks or 'get_notes_by_index' for specific details. No when-not-to-use or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get tracks info from midi file
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absoulate File Path to midi file eg: D:programmingProjectmy-projectmidi-parser-mcp est.mid |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should explain behavioral aspects. It does not mention that the file must exist, whether it only reads (no side effects), or what 'tracks info' includes (e.g., track names, numbers). The behavior is underspecified.
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 very concise (one sentence) but lacks structure or detail that could aid the agent. It is front-loaded but could be improved with more information without being verbose.
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 that there is no output schema, the description should explain what the tool returns (e.g., an array of track objects). It does not, leaving the agent uninformed about the return format. This is a significant 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?
The input schema covers 100% of parameters with a description for filePath. The tool description adds no further meaning beyond the schema's description, so baseline 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 'Get tracks info from midi file' clearly states the action and resource. It implicitly refers to all tracks, distinguishing it from sibling 'get_track_info_by_index' which gets info for a single track, but this differentiation is not explicit.
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?
No guidance on when to use this tool versus siblings like 'get_track_info_by_index' or 'get_midi_info'. No context about prerequisites or alternatives is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set tempo for midi file
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Absoulate File Path to midi file | |
| bpm | Yes | BPM |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It does not state whether the file is modified in place, whether the tempo is added or overwritten, or any side effects. This is a significant gap.
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 extremely concise at one sentence with no wasted words. However, it lacks structure and additional context, so it is efficient but not fully shaped.
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 has two required parameters and no output schema, the description is insufficient. It does not explain what happens to the MIDI file, whether it returns a result, or any constraints on bpm values.
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 adds no additional meaning beyond the schema's parameter descriptions, which are minimal (e.g., 'BPM').
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 sets the tempo for a MIDI file, with a specific verb and resource. It is distinguishable from sibling tools that deal with notes, tracks, or control changes, but doesn't elaborate on the exact scope.
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?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or context. The description only states the basic action.
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.
add_controlchanges_by_indexadd_notes_by_indexadd_pitchbends_by_indexadd_trackget_controlchanges_by_indexget_midi_infoget_notes_by_indexget_pitchbends_by_indexget_track_info_by_indexget_tracks_infoset_tempoScored across 11 tools
Each tool targets a distinct resource (notes, controlchanges, pitchbends, tracks, tempo, info) with clear operations (get, add, set), making them easily distinguishable.
All tool names follow a consistent verb_noun pattern with snake_case, e.g., add_notes_by_index, get_midi_info, set_tempo. No mixed conventions.
11 tools is well-scoped for MIDI file manipulation, covering essential read and write operations without being excessive or thin.
The tool set covers adding and getting notes, control changes, and pitch bends, but lacks update and delete operations for those events, as well as removing tracks or clearing data.
Create, co-edit, analyze, publish, and export collaborative step-sequencer sessions through MCP.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
MCP registry & directory: search, find & install 31k+ MCP servers & tools. Catalog and marketplace.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
