Lists words flagged for review—suppressed, low-audibility, or bleed—so podcast producers can inspect and resolve transcript issues by speaker, track, or project.
List words flagged for review (suppressed, low-audibility, or bleed).
| 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?
With no annotations, the description must disclose behavioral traits, but it only states the listing action. It does not mention read-only nature, side effects, permissions, or whether the output is filtered or paginated. The categories hint at content, but no operational behavior is described.
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 wasted words. It directly states the action and content without unnecessary elaboration.
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 list tool with three undocumented parameters and no annotations, the description is incomplete. While an output schema exists to cover return values, the description omits any parameter guidance, usage context, or behavioral details needed for correct invocation.
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%, and the description makes no mention of the three optional parameters (speaker, track_id, project_path). It fails to compensate for the missing schema documentation, leaving parameter usage completely unexplained.
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?
States a specific verb ('List') and resource ('words flagged for review'), and enumerates the categories (suppressed, low-audibility, bleed). It is clear what the tool does, but it does not differentiate itself from sibling tools like low_audibility_words_tool or bleed_words_tool, which appear to be 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?
Offers no guidance on when to use this tool versus alternatives. An agent must infer that this is an aggregate list covering multiple flag types, but the description does not state when to prefer it over the specialized sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.