Returns per-word audibility scores for a podcast track or speaker to identify unclear speech and guide targeted audio cleanup or edits.
Return per-word audibility scores for a track or speaker.
| Name | Required | Description | Default |
|---|---|---|---|
| speaker | No | ||
| track_id | No | ||
| project_path | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.1.1Input schema / properties / project_path / anyOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / project_path / defaultAdded value: +nullInput schema / properties / project_path / typeRemoved value: -"string"Input schema / requiredRemoved value: -[
- "project_path"
-]v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. 'Return' implies a read operation, but the description does not state whether it is read-only, whether it requires a loaded session, how large the output may be, or any other operational constraints.
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?
A single, front-loaded sentence with no filler. It states the resource and scope immediately and does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists and covers return values, the input side is severely under-specified: three optional parameters have zero schema descriptions and no annotation support, and there is no guidance on choosing between track_id, speaker, or project_path. The description is too thin for an agent to invoke this tool confidently.
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 0% for all three parameters. The description gestures at 'track or speaker' which maps to track_id and speaker, but gives no format, default behavior, or interaction between them, and completely omits project_path, leaving an agent unable to choose correctly.
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 states a specific verb and resource: 'Return per-word audibility scores' and scopes it to 'a track or speaker.' This clearly identifies the tool's function, though it does not explicitly differentiate from related siblings like low_audibility_words_tool, which may also surface audibility information.
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?
There is no guidance about when to use this tool versus alternatives such as low_audibility_words_tool or audio_diagnostics_tool. The description only says what is returned, leaving the agent to infer context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.