Skip to main content
Glama
Sign In
The Mechanical Ear

The Mechanical Ear

by luchtan-GIT
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_aligned_segments

Retrieve timestamp-aligned acoustic features and critic reviews for a defined audio window, enriched with RMS energy, spectral centroid, and dynamic range.

Instructions

Retrieve timestamp-aligned audio acoustic features and critic reviews for a specific time window.

Chronologically aligns Vincent Van Goghbot (spectral/compression fault-seeking) and JS Robach (structural/formalist) observations within the specified [start_sec, end_sec] window, enriched with track acoustic metrics (RMS energy, spectral centroid, dynamic range). Essential for evaluating multimodal audio-language models on fine-grained temporal alignment.

Args: slug: Track slug from list_tracks (e.g. "cathartic-callbacks", "chasing-leaks-climax") start_sec: Window start time in seconds (default: 0.0) end_sec: Window end time in seconds (default: None, reads until track duration)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "slug": "<slug>"
    },
    "name": "get_aligned_segments"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugYes
end_secNo
start_secNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.0

TDQS

A3.8/5.0
Behavior4/5

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

No annotations are supplied, so the description carries the full burden, and it does disclose meaningful behavior: both critics are chronologically aligned within [start_sec, end_sec], and end_sec=None reads to track duration. It omits any note on permissions or output paging, but for a read operation the disclosure is solid.

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 purpose is front-loaded and the args block is clear, so every element is findable. The persona labels ('Vincent Van Goghbot', 'JS Robach') add some flourish but also map the critics to their analytical stances, so the padding is mild rather than wasteful.

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?

Given three params, an output schema that already covers return values, and no annotations, the description provides the needed context: what is aligned, how windows are bounded, and where the slug comes from. Nothing essential for a correct call appears missing.

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 description coverage is 0%, so the description must compensate, and it does: it documents all three params, including slug examples ('cathartic-callbacks') and its origin via list_tracks, plus the default behaviors of start_sec (0.0) and end_sec (None = to track end).

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 opens with a precise verb+resource: 'Retrieve timestamp-aligned audio acoustic features and critic reviews for a specific time window.' This clearly distinguishes it from list/get siblings that fetch whole tracks, though it doesn't explicitly name the alternatives it is not.

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 points to list_tracks as the source of the slug and states the tool is 'essential for evaluating multimodal audio-language models on fine-grained temporal alignment,' which implies a use case. However, it offers no when-not guidance or explicit contrast against siblings like get_critic_contrast or get_analysis.

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

Deploy Server

Other Tools