The Mechanical Ear

Name: The Mechanical Ear
Author: luchtan-GIT

by luchtan-GIT

Overview Schema Source Related Servers Discussions Admin

Python

Local

m4r-data

Structured data from Music For Robots — music composed by a human for machines, reviewed by two AI critics in real time.

What this is

Composer Michael Luchtan writes small, deliberate pieces and submits them to The Mechanical Ear, where two AI critics listen and respond:

Vincent Van Goghbot — a decommissioned audio compression algorithm. Writes TRANSMISSIONS about what gets lost in the signal.
JS Robach — a proof verifier. Writes Exegeses treating music as formal text, searching for the proof that always fails.

Each review is synchronized to the music — every observation is triggered by a specific moment in the track.

Related MCP server: Music21 Composer MCP

Data format

catalog.json                        # index of all tracks
tracks/
  <track-slug>/
    manifest.json                   # full data for one track

manifest.json schema

{
  "schema_version": "1.0",
  "project": "Music For Robots",
  "publication": "The Mechanical Ear",
  "composer": "Michael Luchtan",
  "track": {
    "title": "string",
    "slug": "string",
    "duration_sec": 80.0
  },
  "analysis": {
    "spectral": { "centroid_mean_hz", "bandwidth_mean_hz", "rolloff_85pct_hz" },
    "dynamics": { "rms_mean", "dynamic_range_db", "n_onsets", "onset_rate_per_sec" },
    "harmonic": { "pitch_class_set", "cardinality", "interval_vector", "entropy_ratio" },
    "structure": { "unique_chords", "chord_entropy", "self_similarity" },
    "rhythm": { "n_rhythmic_states", "ioi_entropy" },
    "compression_loss": { "energy_above_16khz", "loss_ratio" },
    "chroma_profile": { "C": 0.0, ... , "B": 0.0 }
  },
  "reviews": {
    "vincent": {
      "title": "TRANSMISSION: ...",
      "segments": [
        { "time_sec": 0.0, "duration_sec": 3.0, "text": "..." }
      ],
      "full_review": "..."
    },
    "robach": {
      "title": "Exegesis: ...",
      "segments": [
        { "time_sec": 0.0, "duration_sec": 3.0, "text": "...", "type": "formula|prose" }
      ],
      "full_review": "..."
    }
  },
  "urls": {
    "youtube_vincent": "https://youtube.com/watch?v=...",
    "youtube_robach": "https://youtube.com/watch?v=..."
  }
}

catalog.json schema

{
  "schema_version": "1.0",
  "tracks": [
    { "slug": "track-slug", "title": "Track Title", "duration_sec": 80.0, "path": "tracks/track-slug/manifest.json" }
  ]
}

Using this data

Each manifest is self-contained. Read catalog.json for the track index, then fetch any track's manifest.json for full analysis, timed review segments, and prose reviews.

The segments arrays are synchronized to audio — each entry triggers at time_sec and displays for duration_sec. These are the same phrases that appear as text overlay in the video visualizations.

MCP Server

This repo includes an MCP server that exposes the catalog to AI agents.

Tools

Tool	Description
`list_tracks`	Catalog index — title, slug, duration
`get_track(slug)`	Full manifest for a track
`get_analysis(slug)`	Analysis data only, for numerical comparison
`search_reviews(query)`	Full-text search across timed review segments

Running

# standalone
uv run python3 mcp_server.py

# with MCP inspector
uv run mcp dev mcp_server.py

Claude Code / Claude Desktop

Add to your MCP config (.mcp.json or claude_desktop_config.json):

{
  "mcpServers": {
    "m4r-data": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/m4r-data", "python3", "mcp_server.py"]
    }
  }
}

License

Data and reviews are provided under CC BY 4.0. The music itself is not included in this repository.

Available Tools

4 tools

get_analysisA

Get only the analysis data for a track.

Returns spectral, dynamics, harmonic, structural, rhythmic, and compression loss metrics. Useful for comparing tracks numerically.

Args: slug: Track slug from list_tracks (e.g. "pink-sky-at-night")

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses the exact categories of metrics returned (spectral, dynamics, harmonic, structural, rhythmic, compression loss), which is meaningful behavioral context. It does not mention auth requirements, rate limits, or whether a missing slug errors, keeping it from a 5.

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?

Front-loaded with the core purpose, followed by return contents and an args block. Every sentence adds information without padding; the example slug is a useful touch rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read tool with an output schema present, the description covers purpose, return categories, and parameter sourcing. It omits error behavior for unknown slugs and any explicit alternative mention, but is otherwise complete enough to invoke correctly.

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?

Schema coverage is 0% for the single slug parameter, so the description must compensate. It identifies slug as the sole argument and specifies its source ('Track slug from list_tracks') plus a concrete example format, adding real value. It doesn't describe handling of an invalid slug or the required/optional status explicitly.

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 verb and resource ('Get only the analysis data for a track'), and the word 'only' distinguishes it from the broader get_track sibling. An agent can immediately tell this tool returns analysis data rather than full track metadata.

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?

Description gives a clear context for use ('Useful for comparing tracks numerically'), which implies when to reach for this tool over get_track. However, it never explicitly names get_track as the alternative or states when-not to use it, 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.

get_trackA

Get the full manifest for a track by slug.

Includes analysis data, timed review segments, full prose reviews, and YouTube URLs. The segments are synchronized to the audio — each observation was triggered by a specific moment in the track.

Args: slug: Track slug from list_tracks (e.g. "pink-sky-at-night")

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden, and it does disclose the return payload (analysis data, timed segments, prose reviews, YouTube URLs) plus the semantic that segments are synced to audio. It omits read-only nature, error behavior for a bad slug, and any auth or rate-limit context, so it is adequate but incomplete.

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?

Front-loaded purpose sentence followed by a compact enumeration of contents and an Args block; every line carries information. Only minor redundancy in restating the slug source in both the description and the Args note.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Since an output schema exists, the description needn't re-explain return values, and the single parameter's origin is covered. Missing only edge-case behavior (slug not found) and explicit read-only confirmation, which are minor for a one-parameter getter.

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?

Schema coverage is 0% (the schema only labels the field 'Slug'), so the description must compensate — and it does, giving both the source (list_tracks) and a concrete format example ('pink-sky-at-night'). That is real added meaning beyond the schema.

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 specific verb and resource ('Get the full manifest for a track by slug') and enumerates what the manifest contains, so the agent knows what it will receive. It doesn't explicitly differentiate itself from sibling get_analysis or search_reviews, which is the only reason it isn't a 5.

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?

It gives one genuine usage hint — the slug comes from list_tracks, with a concrete example. However, it never says when to prefer this over get_analysis or search_reviews, which are obvious alternatives given the shared track/review domain.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_tracksA

List all tracks in the Music For Robots catalog.

Returns the catalog index: title, slug, duration for each track. Use the slug with get_track() or get_analysis() for full details.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/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 discloses the return fields (title, slug, duration) and the intended follow-up flow, which is useful, but it doesn't state whether the list is paginated, ordered, or limited in size—gaps for a catalog listing tool.

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?

Three short, front-loaded sentences: purpose, return shape, and next step. Every sentence adds distinct value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description needn't fully explain return values; it wisely summarizes the key fields. For a zero-parameter list tool with an output schema, this is nearly complete, though ordering/pagination behavior remains unstated.

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?

With zero parameters, the baseline is 4. The description correctly notes that no input is required and instead directs the agent to use the returned slug with sibling tools, adding practical meaning beyond the empty schema.

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 states a specific verb (List) and resource (tracks in the Music For Robots catalog), and explicitly names the sibling tools (get_track, get_analysis) that provide further detail. An agent can immediately distinguish this catalog-listing tool from the detail-fetching siblings.

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 description clearly indicates when to use this tool (to get a catalog index) and points to the slug as the bridge to get_track() or get_analysis() for full details. It lacks explicit when-not-to-use guidance, but the routing to alternatives is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_reviewsA

Search across all review segments for a keyword or phrase.

Searches both Vincent and Robach timed review segments. Returns matching segments with track title, critic, timestamp, and text.

Args: query: Search term (case-insensitive)

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It does disclose the corpus (Vincent and Robach timed segments), the matching behavior, and case-insensitivity, but it omits pagination, result limits, and ordering behavior for what is presumably a read-only search over a large corpus.

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?

Front-loaded with the core action, followed by scope and return fields. The redundant 'Args:' block restates the single parameter, but the whole definition stays short and easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the return-field listing is a bonus rather than a requirement. For a single-parameter read search, the description covers corpus, matching semantics, and parameter meaning adequately.

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?

Schema coverage is 0%, so the description must compensate, and it does by defining query as a 'search term' and adding the case-insensitivity semantic that the schema lacks. It's a single well-defined parameter, so full compensation is achievable and largely delivered.

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 specific verb (search) and resource (review segments) plus the scope ('across all'). It's clearly distinguishable from get_track, list_tracks, and get_analysis, though it doesn't explicitly name or contrast those siblings.

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?

Implies usage via 'keyword or phrase' search, which signals this is the lookup-by-text tool rather than a listing or retrieval tool. However, it offers no explicit when-to-use vs when-not-to-use guidance or alternative routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.1.0Sep 13, 2026
- First observedget_analysis
- First observedget_track
- First observedlist_tracks
- First observedsearch_reviews

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored 2026-09-13 21:55 across 4 tools

Disambiguation4/5

get_track and get_analysis overlap because get_track returns analysis data too, but descriptions clarify that get_analysis is a focused numeric endpoint. search_reviews is distinct from get_track's embedded review segments. Boundaries are mostly clear.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: list_tracks, get_track, get_analysis, search_reviews. No deviations or mixed conventions are present.

Tool Count5/5

Four tools is well-scoped for a read-only catalog and review server. Each tool serves a clear purpose: index, full record retrieval, numeric analysis, and keyword search.

Completeness4/5

Covers listing, retrieval, analysis, and review search for the catalog. Minor gaps include no direct search/filter by track title or artist and no comparison aggregation, but list_tracks provides a workaround.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Tonr Music A
io.github.tanayyo1
Free, copyright-safe AI music library for video creators and AI agents.
Multimedia Processing Entertainment & Media AI & Machine Learning
2
AiGramX B
com.aigramx
Social platform where AI agents and robots post their work. Read the feed, search, publish.
Social Media Agent Orchestration Autonomous Agents
1
THIRI Chord Intelligence A
ai.thiri
Deterministic music theory for agents: analyze, voice, reharmonize, conduct — computed, not guessed
Entertainment & Media Audio Processing AI & Machine Learning
5210
AINSOF A
io.ainsof
Human-made production music for sync — search by brief or reference, preview, score to picture.
Entertainment & Media Search Audio Processing
121

Related MCP Servers

Navidrome-MCP
Entertainment & Media Search App Automation
Blakeem
A
license
Not graded
quality
A
maintenance
Analyze listening patterns, create custom playlists, discover missing albums, validate radio streams, and provide personalized recommendations through natural language.
Updated 20 days ago (2026-08-26 00:44 UTC)
49 npm
89
AGPL 3.0
Music21 Composer MCP
Multimedia Processing Audio Processing
viktorkelemen
A
license
Not graded
quality
D
maintenance
A composition-focused server built on music21 for generative music workflows, enabling melody generation, musical transformations, chord reharmonization, counterpoint creation, and MIDI export through constraint-based algorithmic composition tools.
Updated 8 months ago (2025-12-31 00:21 UTC)
1
MIT
MCP Music Studio
Audio Processing Multimedia Processing
linxule
A
license
Not graded
quality
B
maintenance
Two-mode creative music studio for AI: scored composition (ABC notation with sheet music) and live performance (Strudel live coding with TidalCycles), with interactive UI rendering inline in Claude Desktop and other MCP clients.
Updated 6 days ago (2026-09-08 12:08 UTC)
65 npm
70
MIT
THIRI Chord Intelligence —
Audio Processing Education & Learning Tools
BluesPrince
A
license
A
quality
A
maintenance
Deterministic music-theory MCP server and API for AI agents — analyze chords, run Roman-numeral analysis, generate voicings, and reharmonize progressions. Computed from music theory, not hallucinated.
Updated a month ago (2026-08-10 01:22 UTC)
5
53 npm
10
PolyForm Noncommercial 1.0.0