KIHACHI Brain

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools map cleanly to distinct pipeline stages: spec generation, review, audio generation, project planning, Ableton planning, and memory operations. The pairs execute_live_request/request_live_execution and create_ableton_plan/prepare_ableton_handoff create mild ambiguity, but their descriptions clarify intent. Overall, an agent can usually select the right tool without much trouble.
Naming Consistency4/5
All tools except hello follow a clear snake_case verb_noun pattern using domain-specific objects like songspec, project, plan, audio, and memory. hello is a minor exception, reading more like a interjection than a verb_noun action, but it is semantically a health check. This is very close to fully consistent naming.
Tool Count5/5
Twelve tools is well within the expected range for a focused domain and maps to a coherent music-generation lifecycle. Each tool serves a meaningful role whether that is orchestration, individual pipeline stages, or memory access. There is no obvious bloat or redundancy.
Completeness4/5
The surface covers the main workflow: generate, review, audio generation, project planning, Ableton planning, approval-gated execution, memory storage/retrieval, and orchestration. Gaps like direct retrieval/update/delete of remembered artifacts or editing existing plans would require workarounds but are not dead ends. Core user journeys are coherent and actionable.
Average 3/5 across 12 of 12 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 41 commits in the last 12 weeks
- Last stable release on September 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only names high-level phases. It does not explain ordering, side effects such as writing to memory or creating project files, failure handling, or what 'project preparation' actually does. The stop_on_review_failure parameter hints at review behavior, but the description never connects them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one non-redundant sentence, which is concise, but it is so terse that it under-specifies the tool. It reads more like a label than a usable definition and does not front-load any distinguishing or actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter orchestrator with no annotations, the description is severely incomplete. It omits workflow order, side effects, parameter semantics, and criteria for selecting this over sibling tools. The mention of 'memory' and 'project preparation' implies persistent changes, but those consequences are never described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so none of the six parameters are explained, and the description adds no parameter-level meaning. genre, key, mood, tempo, length_minutes, and stop_on_review_failure are left entirely to inference, with no compensation for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a verb ('Run') and lists concrete phases (generation, review, memory, project preparation), which signals this is a workflow orchestrator rather than a single-step tool. However, it does not name the specific resource being orchestrated or explicitly distinguish itself from siblings like generate_songspec, review_songspec, or prepare_ableton_handoff.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to call orchestrate_song versus any of the sibling tools. There are no conditions, prerequisites, exclusions, or mention that this tool is the high-level entry point that wraps the individual steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It gives no indication of whether this is a read-only review, whether it persists results, returns feedback, or blocks further workflow steps. The vague 'review boundary' phrase hints at a gate but does not explain its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, which is good, but the phrase 'Brain review boundary' adds obscurity rather than clarity. It is under-specified rather than elegantly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool is part of a larger song workflow and accepts a single complex open object. The description does not explain what input the SongSpec should contain, what 'review' entails, or how this step fits among the sibling tools. An agent would be guessing at the invocation contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and an open object type, the description must compensate by explaining what a SongSpec is or what fields matter, but it only reuses the name 'SongSpec'. The parameter remains effectively opaque to an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('review') and resource ('SongSpec'), which is more than a tautology. However, the phrase 'through the Brain review boundary' is unexplained jargon and the description does not clarify how this tool differs from related siblings like generate_songspec or create_project_from_songspec.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives, no workflow context, and no mention of prerequisites or follow-up steps. The single sentence states what it does but not when an agent should select it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Translate' implies a pure data transformation, but the description does not disclose whether the operation has side effects, requires prior state, or behaves differently on invalid input. This is minimal behavioral disclosure for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically clean sentence with no wasted words, which is structurally sound. However, it is too sparse for the tool's complexity—it omits useful context that could be added without bloating the description, so it is under-specification rather than ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists and covers return values, the description does not explain what an 'Ableton plan' is, how it relates to the ProjectPlan input, or how this tool fits in the workflow. This leaves an agent without the contextual knowledge needed to invoke it correctly, especially given related sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes project_plan only as an object with additionalProperties true, providing no structural detail. The description adds the domain term 'ProjectPlan JSON value,' which gives some semantic meaning, but it does not explain what fields or constraints the ProjectPlan must have. With 0% schema description coverage, this is insufficient compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Translate') and resource ('ProjectPlan JSON value' into 'Ableton plan'), clearly indicating the tool's purpose. It is not a tautology and provides enough specificity to distinguish it from unrelated siblings, though it does not explicitly differentiate from closely related Ableton-handoff tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives like prepare_ableton_handoff or execute_live_request. The description lacks any context about prerequisites, workflow position, or conditions that would direct an agent to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It only states that a ProjectPlan is built and may include an arrangement, with no disclosure of side effects, permissions, reversibility, or whether it is a persistent creation. 'Build' implies mutation but little else.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the core action and the optional flag, with no filler or redundancy. It is concise and easy to scan, though it sacrifices informativeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a nested input object and an output schema, the description lacks essential context: what a songspec is, what 'arrangement' means in this domain, and how this tool relates to similar siblings like create_ableton_plan. An agent would not have enough information to invoke it correctly with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It adds some meaning to include_arrangement ('optionally including its arrangement') but provides no explanation of songspec, which is the only required parameter, leaving its semantics to inference from the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Build') and resource ('ProjectPlan') and mentions the optional arrangement. It differentiates from sibling create_ableton_plan by the type of plan produced, though it relies on the tool name to convey the 'from songspec' input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. The sibling list includes create_ableton_plan, generate_songspec, and orchestrate_song, but the description does not mention any of them or provide conditions for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden, but it only says 'Attempt... through the configured adapter boundary.' It hints the operation may fail and involves some adapter boundary, but it does not disclose side effects, authentication needs, whether it mutates Ableton state, or what 'approved' means in behavioral terms.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff and the main action is front-loaded. It earns its place, though the brevity borderline under-specifies rather than being elegantly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% parameter coverage, a nested request object, and a sibling named request_live_execution, this description is far too sparse. An agent cannot reliably decide when to call this tool, what to pass in request, whether approved must be true, or what side effects to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented request and approved parameters. It does not explain the shape of request, how to set approved, or what values are valid; the word 'approved' is too thin to add meaningful semantics beyond the schema's boolean field name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: execute a Live request. The word 'approved' loosely separates it from the sibling request_live_execution, implying this runs a request that has already been approved, but it does not explicitly name or contrast the sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for already-approved Live requests, giving some context about when to use it. However, it gives no explicit exclusions, no guidance about the request_live_execution sibling, and no instruction about what happens if the request is not approved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only says 'generate one audio target', implying creation but not explaining side effects, whether output_path is written, cost, or reversibility. It also introduces the unexplained 'configured Google Lyria boundary' without clarifying what that entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy, making it concise. However, the phrase 'configured Google Lyria boundary' is vague jargon, and the brevity comes at the expense of essential context, so the structure is efficient but under-specifying.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, one nested object, and no annotations, this description is too thin. It does not explain the workflow context, the role of the required inputs, or when in the project lifecycle it should be invoked, despite an output schema being present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain project_plan, target_track, output_path, prompt, and negative_prompt. It does not reference any of these parameters or their meanings, leaving the agent to infer entirely from bare property names, which is especially problematic for the nested project_plan object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states the verb 'generate', the resource 'audio target', and the count 'one', which clearly identifies the operation. It distinguishes from sibling generate_songspec by specifying audio rather than a spec, even though it doesn't name the alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No information about when to choose this tool over siblings such as generate_songspec or create_ableton_plan. The description provides no prerequisites, ordering, or exclusionary conditions, so an agent cannot determine when this tool is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states that a SongSpec is remembered. It does not explain whether this persists data, overwrites existing entries, requires prior context, or has side effects, which is a significant gap for a storage operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It is concise and easy to parse, though it sacrifices useful behavioral and usage context for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nested open-object parameters and no annotations, the description is too thin to give an agent full confidence in when and how to invoke it. The output schema may cover return values, but the description still lacks context about the role of this tool in the broader song workflow and the meaning of 'remember' in this domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It identifies 'songspec' as the required value and 'review' as optional, which adds marginal meaning, but it does not describe the shape, purpose, or constraints of the nested objects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Remember') and a clear resource ('a SongSpec and optional ReviewResult'), which conveys the tool's storage purpose. It is distinguishable from siblings like generate_songspec, review_songspec, and search_memory, though it does not explicitly name its relationship to them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as search_memory or create_project_from_songspec. There are no stated conditions, prerequisites, or exclusions, leaving the agent to infer usage solely from the verb 'remember'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Search', which implies a read operation, but it does not explain what memory records look like, whether results are paginated, whether all stored memories are included by default, or how quality filters affect results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise, front-loaded sentence with no wasted words. It is efficient but slightly too sparse to be highly informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six parameters, no annotations, and no schema descriptions, this one-sentence description is not enough. It never states the default behavior when all optional filters are omitted, what 'review quality' means, or which sort options are supported.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for six undocumented parameters. It only adds meaning for genre and loosely groups min_score/approved_only under 'review quality filters', while query, limit, sort_by, and their interactions remain unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Search'), resource ('memory'), and mentions the main axes of filtering ('genre' and 'optional review quality filters'). It is clear enough to identify this as the retrieval counterpart to remember_song, though it never defines what 'memory' contains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, when not to use it, or how it relates to sibling tools like review_songspec or remember_song. The description implies it is for searching saved memories but does not state a decision rule for selecting it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It does disclose that the tool invokes 'Brain' and fills omitted fields, which is the core behavior. However, it does not state whether the operation is read-only, whether it persists anything, or what to expect beyond the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It sacrifices a small amount of helpful detail, but as pure content density it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter tool with no annotations, 0% schema description coverage, and an output schema, the description covers the basic generation behavior but leaves usage context and parameter semantics to inference. It is minimally viable but not enough for an agent to understand the full flow relative to siblings like create_project_from_songspec or orchestrate_song.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for documenting the five parameters. The only parameter-related signal is the general statement that omitted values are filled from knowledge; individual parameters like key, mood, tempo, and length_minutes are not explained (e.g., key is ambiguous and tempo units are unstated).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete action ('Generate a SongSpec') and adds method scope ('via Brain, filling omitted values from knowledge'). It distinguishes from obvious siblings like generate_audio or review_songspec by targeting the SongSpec artifact, but it never names an alternative or clarifies what a SongSpec is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'filling omitted values' implies this tool is for completing partial song specifications, giving the agent a rough trigger condition. No explicit when-to-use / when-not-to-use guidance or alternative routing is provided, so this is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Validate' implies a non-destructive check, but the description does not state whether the tool modifies the plan, produces intermediate artifacts, or has side effects. It also does not explain what happens on validation failure, leaving key behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to conveying the tool's purpose and timing. The word 'future' is mildly redundant but does not detract from the clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter validation tool, the description conveys the core purpose and position in the pipeline. However, it lacks behavior on invalid plans, whether it is safely repeatable, and what the output schema contains. The presence of an output schema reduces the need to document return values, but the failure semantics remain a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the sole parameter project_plan is an undocumented object. The description only implies that project_plan should be the Ableton plan, but gives no detail about its required fields, nesting, or validation criteria. The description provides minimal compensation for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Validate' with the resource 'Ableton plan' and the temporal context 'before a future Live handoff.' This clearly distinguishes the tool from siblings like create_ableton_plan (creation) and execute_live_request (execution). An agent can identify the tool's role in the pipeline without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before a future Live handoff' gives clear contextual guidance on when this tool should be used: after a plan is created and before execution. However, it does not explicitly name alternatives or state when not to use it, falling just short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly discloses that the tool does not execute the mutation and that the request is approval-gated, which are the key behavioral traits. It does not detail the approval workflow or side effects of preparing the request, but the core non-execution behavior is explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and boundary. Every word earns its place, and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with an output schema, the high-level purpose is clear, but the description omits guidance on what project_plan should contain and the relationship to execute_live_request. The output schema likely covers return values, but parameter construction and workflow context are left to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions project_plan by name or structure. 'Live mutation request' weakly implies that project_plan is the content of the request, but with a single required object parameter and no schema documentation, the agent is left to infer the expected shape. This does not compensate for the missing schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Prepare'), a singular object ('one approval-gated Live mutation request'), and an explicit boundary ('without executing it'). This clearly distinguishes it from the sibling tool execute_live_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'approval-gated' signals when this tool is appropriate, and 'without executing it' separates it from execution tools. However, it does not explicitly name an alternative or give when-not-to-use conditions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool returns a greeting, which implies a read-only, side-effect-free operation, but it does not describe response format, error behavior, or any access requirements. For a trivial health-check tool this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is appropriately sized for the tool's trivial complexity and front-loads the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter health-check tool, the description is entirely complete. An agent knows exactly what to expect and how to invoke it; no further information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so there is nothing for the description to explain. Per the rubric, a baseline of 4 applies when there are no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and a clear resource ('simple health-check greeting'), which unambiguously states what the tool does. It is clearly distinct from the sibling music-production tools, so an agent can easily understand this is a health-check endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance about when to use this tool versus alternatives, nor does it mention exclusions. However, the purpose of a health-check greeting is self-evident and implies usage for verifying service availability, so the usage context is implicitly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

KIHACHI Brain MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![KIHACHI Brain MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/Hirohito-Homma/kihachi-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Hirohito-Homma/kihachi-mcp)

Score Badge

Copy to your README.md:

[![KIHACHI Brain MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/Hirohito-Homma/kihachi-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Hirohito-Homma/kihachi-mcp)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![KIHACHI Brain MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2FHirohito-Homma%2Fkihachi-mcp%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/Hirohito-Homma/kihachi-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Hirohito-Homma/kihachi-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server